<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - /opt/bin/make install DESTDIR=/xxx/yyy does not work solely in DESTDIR but also references ${prefix} without ${DESTDIR}" href="https://bugs.freedesktop.org/show_bug.cgi?id=92406#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - /opt/bin/make install DESTDIR=/xxx/yyy does not work solely in DESTDIR but also references ${prefix} without ${DESTDIR}" href="https://bugs.freedesktop.org/show_bug.cgi?id=92406">bug 92406</a> from <a class="email" href="mailto:aixtools@gmail.com" title="Michael Felt <aixtools@gmail.com>"> Michael Felt</a> <pre>On 2015-10-20 03:47, <a href="mailto:bugzilla-daemon@freedesktop.org">bugzilla-daemon@freedesktop.org</a> wrote: > <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - /opt/bin/make install DESTDIR=/xxx/yyy does not work solely in DESTDIR but also references ${prefix} without ${DESTDIR}" href="show_bug.cgi?id=92406">https://bugs.freedesktop.org/show_bug.cgi?id=92406</a> > > Akira TAGOH<<a href="mailto:akira@tagoh.org">akira@tagoh.org</a>> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > CC| |<a href="mailto:akira@tagoh.org">akira@tagoh.org</a> > 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 > --- <a href="show_bug.cgi?id=92406#c1">Comment #1</a> from Akira TAGOH<<a href="mailto:akira@tagoh.org">akira@tagoh.org</a>> --- > 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. ></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>