From owner-cvs-all@FreeBSD.ORG Tue Aug 7 13:40:12 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 AA2A416A469; Tue, 7 Aug 2007 13:40:12 +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 A2CBB13C478; Tue, 7 Aug 2007 13:40:11 +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 B264C2E1A2; Tue, 7 Aug 2007 15:39:57 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 895585B5A04; Tue, 7 Aug 2007 15:37:44 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l77DbiSI038605; Tue, 7 Aug 2007 15:37:44 +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 15:37:44 +0200 Message-ID: <20070807153744.rxsoo6p0ogoowsw4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 07 Aug 2007 15:37:44 +0200 From: Alexander Leidinger To: Kris Kennaway 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> <20070806173808.GA39444@rot26.obsecurity.org> In-Reply-To: <20070806173808.GA39444@rot26.obsecurity.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=-14.9, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Henrik Brix Andersen , Michael Nottebrock , cvs-all@freebsd.org, ports-committers@freebsd.org, Pav Lucistnik , 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 13:40:12 -0000 Quoting Kris Kennaway (from Mon, 6 Aug 2007 =20 13:38:08 -0400): > On Mon, Aug 06, 2007 at 01:34:06PM +0200, Michael Nottebrock wrote: >> Alexander Leidinger schrieb: >> > Kris, what technical reasons are against explicit dependencies, in >> > your opinion? >> Explicit dependencies would be great, if they can be guaranteed to be >> correct, which basically means we need a way auto-generate them. Maybe >> this could be done in a similar way to the security check target - run >> ldd/objdump over installed executables and libraries, record symbol >> names somewhere, determine dependencies by comparing records ... >> >> 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. > > Yes, this is the most serious problem. Also there is no need to > introduce a new variable to handle it: if you want to record explicit I fail to see where a new variable comes into play... > dependencies a better way is to use LIB_ or RUN_DEPENDS and track the > direct vs inherited dependencies differently in the package database. Why do you want to differentiate between implicit and explicit =20 dependencies? We don't need to list the implicit ones, they are =20 resolved implicitly already even without listing them in the package. Let's step back for a moment... ATM we record the dependencies and the dependencies of the =20 dependencies and so on in a package. I call this implicit dependency =20 recording. With explicit dependency recording I associate to only record the =20 dependencies in the package, which are listed in LIB_ or RUN_DEPENDS =20 of the corresponding port for the package. What I propose and what is implemented with the feature switch which =20 triggered this discussion is: to do the explicit dependency recording =20 instead of the implicit dependency recording. The ports collection =20 resolves the dependencies recursively so we don't need to record the =20 implicit dependencies. They are superflous in +CONTENTS (similar for =20 the corresponding entries in +REQUIRED_BY). This changes - the amount (less) of packages listed in INDEX for a given port. - the amount (less) of dependencies listed in +CONTENTS for a given port/package. - the amount (less) of ports listed in +REQUIRED_BY. When we _would_ switch _now_ it does _not_ change - the dependency tree for a port. - the amount of installed ports when installing x11/gnome2 or x11/kde or whatever (as they will still be resolved and installed implicitly). It allows to have those nice development/update/build properties I =20 talked about in a previous post. To get those nice properties, we have =20 to extend the LIB_ and RUN_DEPENDS of our ports with all those =20 dependencies, which the binaries of the port in question reference but =20 have not listed already in the Makefile. Not all ports in the ports =20 collection fail to have all dependencies, but those which fail them =20 are most of the time not easy (gnome/kde/... are a huge number of =20 ports and are the prominent ports which would need such a treatment). When we switch to explicit dependency recording without adding the =20 explicit LIB_ and RUN_DEPENDS - we gain the benefit of using less space (on disk/CD, via network transfer). - we will not break existing ports. - we don't gain the build/update/development benefits. Can someone please point me to a strong technical reason not to switch =20 to explicit dependency recording? If not, are there strong technical =20 reasons to not record all the required dependencies in the ports which =20 are missing them after switching to explicit dependency recording =20 (note: please see my other mail where I inlined scripts to =20 automatically find suitable LIB_DEPENDS lines for the common case)? Kris, if you are concerned about the impact on the ports collection, =20 please make a exp-build run with this feature and compare it to a =20 normal run. With my "linux ports which are handled by emulation@"-maintainer-hat =20 on I want to point out my cleanup long ago in the linux ports. A lot =20 of ports had no dependency to the linux_base port or linux-x11 port =20 then. It was tedious to find and clean up all linux ports. Now all (I =20 hope) linux ports contain explicit dependencies to their requirements. =20 It makes it very easy to test infrastructure changes for the linux =20 ports now because of the explicit dependencies. It's a huge =20 difference. The amount of work in the beginning was much (we hat a lot =20 of exp-build runs, Kris and me spend a lot of time around Christmas to =20 get it into a good shape), but it amortizes as time passes by (the =20 testing for the update from linux_base-8 to fc4 -- with fc3 in between =20 but not being an official linux_base port for the masses -- was much =20 much much faster and needed less exp-build runs). Bye, Alexander. --=20 Signals don't kill programs. Programs kill programs. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137