From owner-cvs-all@FreeBSD.ORG Tue Aug 7 12:53:48 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9FDA16A419; Tue, 7 Aug 2007 12:53:48 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 2C39113C48A; Tue, 7 Aug 2007 12:53:48 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A57046.dip.t-dialin.net [84.165.112.70]) by redbull.bpaserver.net (Postfix) with ESMTP id 458622E098; Tue, 7 Aug 2007 14:53:37 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 17F915B5A04; Tue, 7 Aug 2007 14:51:24 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l77CpNIu030918; Tue, 7 Aug 2007 14:51:23 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Tue, 07 Aug 2007 14:51:23 +0200 Message-ID: <20070807145123.yb3dqjojk08s40wg@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 07 Aug 2007 14:51:23 +0200 From: Alexander Leidinger To: Michael Nottebrock 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> In-Reply-To: <46B84C78.3030009@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-13.927, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, SMILEY -0.50, TW_BJ 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Kris, Henrik Brix Andersen , cvs-all@freebsd.org, ports-committers@freebsd.org, Pav Lucistnik , Kennaway , cvs-ports@freebsd.org Subject: Re: cvs commit: ports/Mk bsd.port.mk X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2007 12:53:48 -0000 Quoting Michael Nottebrock (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