Date: Tue, 07 Aug 2007 14:51:23 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Michael Nottebrock <lofi@freebsd.org> Cc: Kris, Henrik Brix Andersen <henrik@brixandersen.dk>, cvs-all@freebsd.org, ports-committers@freebsd.org, Pav Lucistnik <pav@freebsd.org>, Kennaway <kris@obsecurity.org>, cvs-ports@freebsd.org Subject: Re: cvs commit: ports/Mk bsd.port.mk Message-ID: <20070807145123.yb3dqjojk08s40wg@webmail.leidinger.net> In-Reply-To: <46B84C78.3030009@freebsd.org> References: <200706281553.l5SFr56i099807@repoman.freebsd.org> <20070802181715.46yikycm8gc8g8kk@webmail.leidinger.net> <20070803125410.GB1062@tirith.brixandersen.dk> <200708032144.57558.lofi@freebsd.org> <20070803204215.GA68620@rot26.obsecurity.org> <20070806074318.q9mw6ulngg00gwsw@webmail.leidinger.net> <20070806065634.GA31676@rot26.obsecurity.org> <20070806113855.0fcq213io0www04k@webmail.leidinger.net> <46B7072E.8070307@freebsd.org> <20070807111509.ojm8nc4ao0g080ck@webmail.leidinger.net> <46B84C78.3030009@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Michael Nottebrock <lofi@freebsd.org> (from Tue, 07 Aug 2007 =20
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 =20
you get is a smaller INDEX (anyone willing to measure how much?) and =20
maybe a little bit less computing time for the index. Maybe it also =20
speed up a little bit pkg_* when handling the dependencies (this is =20
maybe far fetched). What you not get immediately is the additional =20
features for some ports. But for some ports you can get the benefit =20
immediately. I hope you are not too biased regarding KDE. Yes, KDE and =20
such would benefit by a huge amount by this, more than smaller ports, =20
but even for the "small" dependency trees this can result in nice =20
improvements.
We don't break anything by going explicit, but we can gain new =20
features when we do it. Having some automatic thing is very beneficial =20
for large dependency trees, but not a hard requirement for the entire =20
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 =20
switch. Everything will be served by the implicit dependencies which =20
are installed even when you go explicit. It would be an extreme edge =20
case when pointyhat reports a problem when switching to explicit. So =20
theres no difference in work to get a port to the same quality level =20
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 =20
directly. If the xorg libs are a second level dependency (because they =20
are needed by Qt), then you don't need to specify them in the KDE =20
ports. I think most KDE/GNOME/... apps don't use any X lib directly at =20
all. Only some special features like the composing extension, session =20
handling stuff and custom widgets may need to depend upon them =20
directly. All the rest should be satisfied with the Qt/GTK/... =20
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 =20
be an explicit dependency. AFAIK the libtool (libltdl) is fixed now to =20
only record the explicit dependencies. This means if you only use Qt =20
widgets and only link to Qt, it doesn't add a reference to libX11 too, =20
as this is already recorded in the Qt libs. So the port only needs an =20
explicit dependency to Qt. The Qt port is then responsible to install =20
the needed X11 libs.
There is an exception to this: for example pkg_config stuff may =20
contain references to other needed libs to feed the compiler with the =20
necessary linker flags for them. In some circumstances this may be =20
necessary, but unfortunately not in all cases where this is the case =20
ATM. For every other build middleware which behaves the same this is =20
the case too. So there may be some ports which would also need a =20
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/* =20
/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=3D"$1"
shift
for i in "$@"; do
if [ -e /lib/$i -o -e /usr/lib/$i ]; then
# base system lib
shift
continue
fi
lib=3D"$(echo $i | sed -e 's:^lib:: ; s:\.so.*::')"
port=3D$(pkg_which "${base}/lib/$i")
if [ -f /var/db/pkg/$port/+CONTENTS ]; then
origin=3D$(grep "@comment ORIGIN:" =20
/var/db/pkg/$port/+CONTENTS | s
ed -e 's/@comment ORIGIN://')
else
origin=3Dunknown
fi
echo ${lib}:${origin}
shift
done | sort -u
---snip---
Call it like "resolveportsfromlibs.sh /usr/local $(neededlibs.sh =20
/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 =20
required than will be necessary. I think there will be a lot work =20
required in the beginning (if a maintainer wants to improve =20
immediately on his own, but then he is responsible for his own time =20
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 =20
switch and after that we can ask maintainers to DTRT for small ports, =20
and we can ask for testing and beating and helping for the mega ports. =20
If 90% of the ports collection is expanded to have all explicit =20
dependencies, we can officially require that new ports have to have =20
them. But I don't assume this will happen in the next 12-18 months =20
after switching to explicit dependencies.
Bye,
Alexander.
--=20
Conway's Law:
=09In any organization there will always be one person who knows
=09what is going on.
=09This person must be fired.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070807145123.yb3dqjojk08s40wg>