[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 #2 from Michael Felt <aixtools at gmail.com> ---
On 2015-10-20 03:47, bugzilla-daemon at freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=92406
>
> Akira TAGOH<akira at tagoh.org>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|NEW                         |RESOLVED
>                   CC|                            |akira at 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 at 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 at 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.
>

-- 
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/20151022/d3568438/attachment.html>