Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 May 2010 13:51:45 +0200
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Doug Barton <dougb@FreeBSD.org>
Cc:        gnome@FreeBSD.org, Koop Mast <kwm@FreeBSD.org>, Joe Marcus Clarke <marcus@FreeBSD.org>, freebsd-ports@FreeBSD.org
Subject:   Re: Grandfather dependencies completely out of control
Message-ID:  <20100503135145.785968lw62popj40@webmail.leidinger.net>
In-Reply-To: <4BDE2225.30805@FreeBSD.org>
References:  <4BDD1728.8080903@FreeBSD.org> <1272795699.58527.26.camel@headache.rainbow-runner.nl> <4BDDEC67.7090808@FreeBSD.org> <4BDDFC70.1040609@freebsd.org> <4BDE2225.30805@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Doug Barton <dougb@FreeBSD.org> (from Sun, 02 May 2010  
18:08:53 -0700):

> On 05/02/10 15:28, Joe Marcus Clarke wrote:
>> On 5/2/10 5:19 PM, Doug Barton wrote:
>>> On 05/02/10 03:21, Koop Mast wrote:
>>>> One of the scripts provided by devel/glib20 is a perl script.  
>>>> That is the reason why
>>>> we need perl.
>>>
>>> Thanks for the response, couple things come to mind. First, how  many
>>> things actually make use of those perl/python scripts? If the number is
>>> small they should probably be OPTIONS that default to off, or slave
>>> ports as Thomas suggested.
>>
>> The script (glib-mkenums) is actually very important to almost all ports
>> which depend on glib.  Yes, what Thomas suggested could be done with
>> some considerable work.  What might be better is to have someone versed
>> in shell scripting translate this script to sh.  I think the GNOME guys
>> would be fine to accept that.
>
> Please note that I'm not overwhelmingly interested in this particular
> case. I'm more concerned about the general problem of grandfather
> dependencies.

Put
EXPLICIT_PACKAGE_DEPENDS=yes
in make.conf. This will get rid of the grandparent-deps.

The problem with this is, that a lot of ports hardcode  
grandparent-libs. This is not a FreeBSD problem, this is a libtool (at  
least 1.x) problem and a pkg-config problem (adding grandparent-libs  
even if they are not necessary). So with this switch, you can not  
lookup potential candidates for an upgrade, by looking at the  
+REQUIRED_BY file.

Because of the libtool/pkg-config problem all childs of a  
"problematic" lib will contain a reference to the lib, even if the  
particular lib is just a dependency of a lib which the current port  
uses. To make this description more explicit: if your port uses  
libGRAPH (I made upt this name) and libGRAPH is linked to libjpeg and  
libpng via libtool (at least 1.x), but your port is not directly using  
symbols from libjpeg or libpng, the binaries of your port will have  
libpng *and* libjpeg hardcoded.

See /usr/ports/Tools/scripts/explicit_lib_depends.sh for a script  
which tells you which libs are hardcoded in the files (if they are in  
bin/ or lib/) of your (installed) port. Feel free to improve the  
script, I didn't touch it since 3 years because the software in the  
ports tree was not in a state where it made sense to finish the "NOT  
YET" part or extend the scope of files to analyze.

Bye,
Alexander.

-- 
A baby is an alimentary canal with a loud voice
at one end and no responsibility at the other.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100503135145.785968lw62popj40>