cvs commit: ports/Mk bsd.port.mk

[Alexander Leidinger]

Quoting Michael Nottebrock <lofi at freebsd.org> (from Tue, 07 Aug 2007  
12:42:00 +0200):

> Alexander Leidinger schrieb:

>>> Explicit dependencies that need to be determined and maintained manually
>>> by port maintainers are useless, since they'll be almost guaranteed to
>>> be wrong most of the time for those ports that would profit the most
>>> (shave off the most implicit dependencies) from having them.
>>
>> I don't think so.
> Well, I do. What now? :P

You can activate the explicit dependencies without any problems. What  
you get is a smaller INDEX (anyone willing to measure how much?) and  
maybe a little bit less computing time for the index. Maybe it also  
speed up a little bit pkg_* when handling the dependencies (this is  
maybe far fetched). What you not get immediately is the additional  
features for some ports. But for some ports you can get the benefit  
immediately. I hope you are not too biased regarding KDE. Yes, KDE and  
such would benefit by a huge amount by this, more than smaller ports,  
but even for the "small" dependency trees this can result in nice  
improvements.

We don't break anything by going explicit, but we can gain new  
features when we do it. Having some automatic thing is very beneficial  
for large dependency trees, but not a hard requirement for the entire  
ports collection.

>> I think it will be the same as currently. Things which are not catched
>> by pointyhat will be reported by users.
> Yes. Over and over again. Getting explicit library dependencies right

You will not see different errors from pointyhat as soon as you  
switch. Everything will be served by the implicit dependencies which  
are installed even when you go explicit. It would be an extreme edge  
case when pointyhat reports a problem when switching to explicit. So  
theres no difference in work to get a port to the same quality level  
as now.

> for all of KDE (and Qt) for instance means explicitly depending on
> single xorg library ports in each of the KDE and Qt ports. With every

You only need to link to the xorg libs in KDE if they link them in  
directly. If the xorg libs are a second level dependency (because they  
are needed by Qt), then you don't need to specify them in the KDE  
ports. I think most KDE/GNOME/... apps don't use any X lib directly at  
all. Only some special features like the composing extension, session  
handling stuff and custom widgets may need to depend upon them  
directly. All the rest should be satisfied with the Qt/GTK/...  
dependency.

> update, these dependencies are likely to change and thus need review
> (and if the review isn't done (properly), will cause fallout for people
> trying to save time on updates and thus waste even more time - a very
> frustrating user experience). Moreover, the dependencies are likely to
> change depending on the user's installation for a certain number of
> ports, i.e. in some circumstances, a library/binary might contain
> references to libXrender, in others it might not. Catching all these

ldd may show a dependency to libXYZ, but this does not mean it has to  
be an explicit dependency. AFAIK the libtool (libltdl) is fixed now to  
only record the explicit dependencies. This means if you only use Qt  
widgets and only link to Qt, it doesn't add a reference to libX11 too,  
as this is already recorded in the Qt libs. So the port only needs an  
explicit dependency to Qt. The Qt port is then responsible to install  
the needed X11 libs.

There is an exception to this: for example pkg_config stuff may  
contain references to other needed libs to feed the compiler with the  
necessary linker flags for them. In some circumstances this may be  
necessary, but unfortunately not in all cases where this is the case  
ATM. For every other build middleware which behaves the same this is  
the case too. So there may be some ports which would also need a  
direct dependency to ports they don't really depend upon directly.

> cases will need very careful review and again, they are likely to change
> from release to release. I maintain that it is futile to try and do this
> without some sort of automatic dependency generation (or at least checking).

Quick shot:

A list of libs for the given binaries:
---snip---
#!/bin/sh

for i in "$@"; do
         objdump -x "$i" | grep NEEDED | awk '{print $2}'
         shift
done | sort -u
---snip---

Call it like "neededlibs.sh /space/porttest/bin/*  
/space/porttest/libs/*" to get a listing of all referenced libs.

The following gives LIB_DEPENDS ready output...
---snip---
#!/bin/sh

# this needs portupgrade installed

base="$1"
shift

for i in "$@"; do
         if [ -e /lib/$i -o -e /usr/lib/$i ]; then
                 # base system lib
                 shift
                 continue
         fi

         lib="$(echo $i | sed -e 's:^lib:: ; s:\.so.*::')"
         port=$(pkg_which "${base}/lib/$i")

         if [ -f /var/db/pkg/$port/+CONTENTS ]; then
                 origin=$(grep "@comment ORIGIN:"  
/var/db/pkg/$port/+CONTENTS | s
ed -e 's/@comment ORIGIN://')
         else
                 origin=unknown
         fi

         echo ${lib}:${origin}
         shift
done | sort -u
---snip---

Call it like "resolveportsfromlibs.sh /usr/local $(neededlibs.sh  
/space/porttest/bin/*)".

Does someone wants this in ports/Tools/scripts/?

> That said, let me stress again that I'd *like* correct explicit library
> dependencies. I actually already tried once to explicity depend on
> single X libraries for the Qt4 ports and all the ports further down in
> their dependency tree, but gave up because USE_XORG/bsd.xorg.mk at the
> moment cannot be used after bsd.port.pre.mk and I didn't have enough
> time to try and fix that as well. :)

Putting the XORG problem aside, I think you assume there is more work  
required than will be necessary. I think there will be a lot work  
required in the beginning (if a maintainer wants to improve  
immediately on his own, but then he is responsible for his own time  
management), but then it is not that much work.

I repeat: I don't think is is necessary to have all at once. We can  
switch and after that we can ask maintainers to DTRT for small ports,  
and we can ask for testing and beating and helping for the mega ports.  
If 90% of the ports collection is expanded to have all explicit  
dependencies, we can officially require that new ports have to have  
them. But I don't assume this will happen in the next 12-18 months  
after switching to explicit dependencies.

Bye,
Alexander.

-- 
Conway's Law:
	In any organization there will always be one person who knows
	what is going on.

	This person must be fired.

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