Summary: | /opt/bin/make install DESTDIR=/xxx/yyy does not work solely in DESTDIR but also references ${prefix} without ${DESTDIR} | ||
---|---|---|---|
Product: | fontconfig | Reporter: | Michael Felt <aixtools> |
Component: | conf | Assignee: | fontconfig-bugs |
Status: | RESOLVED NOTABUG | QA Contact: | Behdad Esfahbod <freedesktop> |
Severity: | normal | ||
Priority: | medium | CC: | akira |
Version: | 2.11 | ||
Hardware: | PowerPC | ||
OS: | AIX | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Michael Felt
2015-10-10 16:46:15 UTC
You can't validate symlinks at the build time because DESTDIR isn't supposed to be. and DESTDIR is used as a prefix path how it looks at the installation time for packaging. the point is DESTDIR is dropped from the real installed path. so checking that at the build time in the sense of packaging really makes no sense. So the answer for your question is, because we use a symlink to enable/disable a configuration file easily for system-wide and user-specific, and keep consistency on changes. if you copy some of them and it is changed in upstream, you'll miss it then. or if doubt, you'll need to copy them every time on upgrading. fontconfig follows the general use of DESTDIR in autotools and no concerns on packaging at this moment. On 2015-10-20 03:47, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=92406 > > Akira TAGOH<akira@tagoh.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > CC| |akira@tagoh.org > Resolution|--- |NOTABUG You can call it "not a bug", but then you may want to document that make DESTDIR=/something/else will never work because the make process cannot deal with the symbolic links auto(anything) makes. Probably "not a bug", at least not of fontconfig - but of one of the tools you use to automate builds of fontconfig. As I commented - the workaround (for fontconfig) is to run 'make install' without DESTDIR, and then repeat make with DESTDIR. If you could help me better understand why a symbolic link is generated I might be able to work on a patch for auto-something. Unfortunately, I do not know the auto-something tools well enough to see easily where, or why the symbolic is generated. Most projects do not generate them or they generate them relative to DESTDIR rather than hard on /. I cannot recall the first project I had this problem - something I also resolved via the workaround above - as far as my packaging goes. But the issue seems to come up roughly 1 every 70 to 80 projects. FYI. Thanks for looking at fontconfig. If you have a hint on where/why the symbolic is being generated I will research further in the 'auto-something' area. Sincerely, Michael > --- Comment #1 from Akira TAGOH<akira@tagoh.org> --- > You can't validate symlinks at the build time because DESTDIR isn't supposed to > be. and DESTDIR is used as a prefix path how it looks at the installation time > for packaging. the point is DESTDIR is dropped from the real installed path. re: DESTDIR - that is where the files are 'installed' to make a clean install point. The symbolic link points to something that exists $DESTDIR/something/to/symlink/to. From the point of cd $DESTDIR symbolic link ./this/is/a/link -> ../../../something/to/symlink/to so it looks something like: michael@x071:[/var/DESTDIR]ls -lR .: total 0 drwx------ 3 root system 256 Oct 22 18:14 something drwx------ 3 root system 256 Oct 22 18:15 this ./something: total 0 drwx------ 3 root system 256 Oct 22 18:14 to ./something/to: total 0 drwx------ 2 root system 256 Oct 22 18:15 symlink ./something/to/symlink: total 4 -rw------- 1 root system 29 Oct 22 18:16 to ./this: total 0 drwx------ 3 root system 256 Oct 22 18:15 is ./this/is: total 0 drwx------ 2 root system 256 Oct 22 18:17 a ./this/is/a: total 0 lrwxrwxrwx 1 root system 32 Oct 22 18:17 link -> ../../../something/to/symlink/to rather than, at the end ./this/is/a: total 0 lrwxrwxrwx 1 root system 32 Oct 22 18:17 link -> /something/to/symlink/to IMHO - this is something that auto-thingy should be able to do so that make DESTDIR=/var/DESTDIR would work. Remember, it not my followup command that "packages" /var/DESTDIR (stripping $DESTDIR from the full filepathname - but the make command itself that fails! > so > checking that at the build time in the sense of packaging really makes no > sense. > > So the answer for your question is, because we use a symlink to enable/disable > a configuration file easily for system-wide and user-specific, and keep > consistency on changes. if you copy some of them and it is changed in upstream, > you'll miss it then. or if doubt, you'll need to copy them every time on > upgrading. > > fontconfig follows the general use of DESTDIR in autotools and no concerns on > packaging at this moment. > (In reply to Michael Felt from comment #2) > You can call it "not a bug", but then you may want to document that make > DESTDIR=/something/else will never work because the make process cannot > deal with the symbolic links auto(anything) makes. > Probably "not a bug", at least not of fontconfig - but of one of the > tools you use to automate builds of fontconfig. It looks like you are misunderstanding about DESTDIR. see https://www.gnu.org/software/automake/manual/html_node/DESTDIR.html If you want to install them permernently under $DESTDIR, you should do that with --prefix and other options for configure script that determine the install path, instead of using $DESTDIR. I don't know what kind of problems you are facing at this moment though, it works fine with many packaging systems so that I've never ever heard any complaints about it. > IMHO - this is something that auto-thingy should be able to do so that > make DESTDIR=/var/DESTDIR would work. Wrong. you should better understand how packaging systems works to build a package. > (stripping $DESTDIR from the full filepathname That's why symlinks works at the end on packaging system enabled environments. symlinks points to the proper files when installing the package then. Doing both of validating symlinks and creating a package isn't feasible, particularly it contains a symlink. if you are fixing that anyway to work a symlink validation, you'll see a problem after installing that package because symlinks points to $DESTDIR/path/to/file where isn't available. so you eventually need to re-link them. > - but the make command > itself that fails! It's not our fault. no fails with "make" itself on what we shipped. On 2015-10-23 04:34, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=92406 > > --- Comment #3 from Akira TAGOH<akira@tagoh.org> --- > (In reply to Michael Felt from comment #2) >> You can call it "not a bug", but then you may want to document that make >> DESTDIR=/something/else will never work because the make process cannot >> deal with the symbolic links auto(anything) makes. >> Probably "not a bug", at least not of fontconfig - but of one of the >> tools you use to automate builds of fontconfig. > It looks like you are misunderstanding about DESTDIR. see > https://www.gnu.org/software/automake/manual/html_node/DESTDIR.html > > If you want to install them permernently under $DESTDIR, you should do that > with --prefix and other options for configure script that determine the install > path, instead of using $DESTDIR. I guess my problem is that I do not know how to explain my problem in text. I think of $DESTDIR as / would look as ./ after chroot() to $DESTDIR - so that I can package that and install that directory tree onto '/' as './'. I do think we agree on the intent of $DESTDIR as far as make DESTDIR=xxx is concerned. My apologies for any uncertainity or confusion on this point - both previous, and for any forth coming. However, if the confusion continues I shall simply admit my failing and stop commenting as clearly I will have shown myself incapable of showing that we agree on this point. > I don't know what kind of problems you are facing at this moment though, it > works fine with many packaging systems so that I've never ever heard any > complaints about it. Yes, the autotools work fine with other environments I am sure. And, this is not a 'complaint' - it is information for you to use, or not use. As it is unusual - also for me -I had hoped it would also be interesting for this project. >> IMHO - this is something that auto-thingy should be able to do so that >> make DESTDIR=/var/DESTDIR would work. > Wrong. you should better understand how packaging systems works to build a > package. > >> (stripping $DESTDIR from the full filepathname > That's why symlinks works at the end on packaging system enabled environments. > symlinks points to the proper files when installing the package then. > Doing both of validating symlinks and creating a package isn't feasible, > particularly it contains a symlink. if you are fixing that anyway to work a > symlink validation, you'll see a problem after installing that package because > symlinks points to $DESTDIR/path/to/file where isn't available. so you > eventually need to re-link them. > >> - but the make command >> itself that fails! "make DESTDIR=/var/DESTDIR install" fails, "make install" works fine, but that is not what I call a package - and since we seem to define package differently - not worthy of further discussion. > It's not our fault. no fails with "make" itself on what we shipped. There is no fault. There is a cause - and it is probably not in your project but somewhere in the 'autotools'. And there are often workarounds that a project can apply so that an autotool 'cause' does not affect a project. Thank you for your consideration. When I know more about the inner workings of the autotools - when and why they use symbolic links - I may come back. But if I am successful in the autotool area - I will not need to. Sincerely, Michael > |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.