[Fontconfig-bugs] [Bug 92406] /opt/bin/make install DESTDIR=/xxx/yyy does not work solely in DESTDIR but also references ${prefix} without ${DESTDIR}

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92406

--- Comment #4 from Michael Felt <aixtools at gmail.com> ---
On 2015-10-23 04:34, bugzilla-daemon at freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=92406
>
> --- Comment #3 from Akira TAGOH<akira at 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
>

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20151023/b2cf6bd0/attachment.html>