Quoting Michael Nottebrock <[EMAIL PROTECTED]> (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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
