<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#c4">Comment # 4</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-23 04:34, <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> > > --- <a href="show_bug.cgi?id=92406#c3">Comment #3</a> from Akira TAGOH<<a href="mailto:akira@tagoh.org">akira@tagoh.org</a>> --- > (In reply to Michael Felt from <a href="show_bug.cgi?id=92406#c2">comment #2</a>) >> 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 > <a href="https://www.gnu.org/software/automake/manual/html_node/DESTDIR.html">https://www.gnu.org/software/automake/manual/html_node/DESTDIR.html</a> > > 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 ></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>