Date: Sat, 10 Mar 2007 01:22:31 -0800 From: Ade Lovett <ade@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org> Cc: freebsd ports <freebsd-ports@freebsd.org>, Ade Lovett <ade@FreeBSD.org> Subject: Re: Ports 104877 causing big problems Message-ID: <A2A83649-B19D-46FE-BDCD-441A764AC1AC@FreeBSD.org> In-Reply-To: <45F272E6.9070501@FreeBSD.org> References: <45F1DDE2.5030404@FreeBSD.org> <BE66AB56-E0B4-420A-910D-9C10DB9AF24D@FreeBSD.org> <45F1EA6A.6070904@FreeBSD.org> <FB399CF7-11E2-4CC9-8C91-7D6850B7B2D8@FreeBSD.org> <20070310023034.c5939c48.jylefort@FreeBSD.org> <7CF1749C-3254-46AC-ABDD-BAB0D84ED7A1@FreeBSD.org> <45F2546F.60401@FreeBSD.org> <45808CB8-07C8-4680-A11D-8982BD8A6B52@FreeBSD.org> <45F272E6.9070501@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 10, 2007, at 00:57 , Doug Barton wrote: > Ade Lovett wrote: >> it's not related to +REQUIRED_BY, as already pointed out. Braino >> on my part, this is compile and run-time issues, not a ports >> dependency issue. My apologies. > > I think it's both, since there is absolutely no reason that mtr, > xscreensaver, or 3/4 of the other ports that I currently have in / > var/db/pkg/libgpg-error/+REQUIRED_BY should have registered a > dependency on that library, since they don't need or use it. There are two fundamentally different issues here, which are being confused. Note that apart from explicit BUILD, RUN and LIB dependencies on autotools themselves, there is *nothing* within bsd.autotools.mk that would add the phantom dependencies that you're seeing. This is an entirely different issue. I believe that someone (adamw@ ?) had some code that would parse /var/ db/pkg/*/+REQUIRED_BY and turn it into a format that could be thrown at graphviz for a graphical representation of the dependency chains of ports installed on a system. I can't for the life of me find this code at the moment, but I'm pretty sure it's out there. Certainly, on my system: [root@foo:~] 25# !grep grep mtr /var/db/pkg/libgpg-error-1.4_1/+REQUIRED_BY [root@foo:~] 26# There's no such dependency registered. However, I believe that in certain circumstances, mtr can be compiled against gtk-2.x, which in turn can have CUPS support enabled, which further can have gnutls support, and so on down the chain to libgpg-error. This is an artifact of the pkg_* tools, and nothing to do with the libtool issue at hand. That specific issue is that, apparently, there is an alleged performance decrease in having the .la file explicitly reference all other libraries on which it depends. ie: if library 'A' depends on 'B', which in turn depends on 'C', the relevant RT_DEPENDS in the .a/.so files are ignored, and 'A.la' will actually contain references to both 'B.la' *and* 'C.la', even though, strictly speaking 'C.la' is not required. > I think you're getting extremely reactionary and defensive here, > and there is no reason for either. No one is attacking you, or your > work. What we are saying is that there _is_ a problem. The exact > cause(s) and solution(s) of the problem may not be known at this > time, but it would be a big help if you could recognize that there > is in fact a problem, and start working with us on a reasonable > solution. There are two fundamentally different issues here, and they are being confused. One relates to the way in which pkg_* registers dependencies, the other is an alleged performance decrease as a result of explicitly labeling (within the .la files, *not* package dependencies) every single dependent library rather than optimizing out the A => B => C so A.la only need B.la, and not B.la + C.la. The PR in question does nothing with regards to the first issue -- it cannot, bsd.autotools.mk simply does not do anything like this in terms of munging *_DEPENDS other than for its own uses for the autotools a port may or may not use. That is a topic for another thread. As for the second issue, I am still waiting for positive empirical evidence that the remedy is not in fact worse than the cure. To date, unlike the gnucash/libltdl issue, where it was obviously documentable that the previous method of doing things was broken, I have seen no evidence to support 'fixing' things. -aDe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A2A83649-B19D-46FE-BDCD-441A764AC1AC>