Re: libcroco and xz

[David Holland <dholland-pkgusers%netbsd.org@localhost>]

On Fri, Jun 15, 2012 at 09:09:16PM +0200, Joerg Sonnenberger wrote:
 > > > > >>I see...
 > > > > >>
 > > > > >>using *.xz archive, so marked as build depend on archive/xz,
 > > > > >>but check-shlib claims using shlibs from build depends.
 > > > > >>It's false alarm.
 > > > > >
 > > > > >I can reproduce it now. It is *not* a false alarm. libxml2 should be
 > > > > >pulling in a full xz dependency, since libxml2.so depends on it now, 
 > > > > >but
 > > > > >it only gets counted as build dependency.
 > > > > 
 > > > > No, not only directly build dependency, but also indirectly full
 > > > > dependency.
 > > > > In other words, directly build dependency on `xzcat' command from
 > > > > archive/xz,
 > > > > and indirect full dependency on `liblzma' from archive/xz.
 > > > 
 > > > Right, there is no such thing as an indirect full dependency...
 > > 
 > > Sure. Call it whatever you want. But libcroco does not directly depend
 > > on xz or liblzma. Grepping the entire libcroco distribution for 'lzma'
 > > matches only some makefile goop for creating .tar.lzma files.
 > > 
 > > We should not be adding a bogus xz runtime dependency to libcroco (and
 > > everything else that uses libxml2) and the checks done by pkgsrc
 > > should not demand one or encourage people to add one incorrectly.
 > 
 > The problem I have with the commit is that it also hides the reverse
 > case. A dependency is declared as build time only, used by a dependency
 > as full dependency, but explicitly linked against. I'm more inclined to
 > care about that case than the reverse.

I think that's less important. If it's an indirect dependency, it'll
always be present; the only way it'll fail at runtime is if an update
to libxml2 changes it to longer bring in xz. However, this will result
(if handled correctly) in xz being removed from xz's bl3.mk and
libcroco being revbumped and rebuilt, and then the liblzma NEEDED
entry will go away in the new build. IOW, it won't fail, so there's no
point worrying about it.

We could also try fixing libxml2's antisocial behavior, but that's (1)
probably a can of worms and (2) likely to need to be repeated in other
packages.

-- 
David A. Holland
dholland%netbsd.org@localhost