From owner-cvs-all@FreeBSD.ORG Mon Aug 6 09:41:20 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 406DF16A419; Mon, 6 Aug 2007 09:41:20 +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 ADD8D13C45A; Mon, 6 Aug 2007 09:41:19 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55A8D.dip.t-dialin.net [84.165.90.141]) by redbull.bpaserver.net (Postfix) with ESMTP id BE7532E06A; Mon, 6 Aug 2007 11:41:08 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id AA4FB5B5A04; Mon, 6 Aug 2007 11:38:55 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l769ctw5054431; Mon, 6 Aug 2007 11:38:55 +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; Mon, 06 Aug 2007 11:38:55 +0200 Message-ID: <20070806113855.0fcq213io0www04k@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 06 Aug 2007 11:38:55 +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> In-Reply-To: <20070806065634.GA31676@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=-15.246, required 8, autolearn=not spam, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10, SMILEY -0.50, TW_GT 0.08, TW_IB 0.08) 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: Mon, 06 Aug 2007 09:41:20 -0000 Quoting Kris Kennaway (from Mon, 6 Aug 2007 =20 02:56:34 -0400): > On Mon, Aug 06, 2007 at 07:43:18AM +0200, Alexander Leidinger wrote: > >> >>Not sure this can work reliably enough to be usefule at present, at >> >> least for >> >>the specific scenario of avoiding unnecessary recompilations. I think >> >>there >> >>are just too many ports with implicit dependencies, especially in the >> >>KDE/GNOME domain. >> >> That's a bug in those ports IMHO. And that's the reason why this >> feature is not enabled by default. >> >> >Yes. I'm not even convinced this feature is a good idea. >> >> "Not a good idea" as in "is not usable yet" or as in "it should never >> be the goal to be usable"? If it is the former, I agree (see above). >> If it is the later please elaborate (having correct dependency >> information should always be a good idea, I think the benefits are >> obvious, aren't they?). > > Both: we're not there yet, and I don't see why this implementation is > the best way to get there :) Did I miss your discussion of the > proposal? No, I thought it is obvious that a correct dependency information is a =20 "Good Thing"(tm). - When you do sweeping changes or changes with a large impact (number of ports), it is beneficial to have the real list of dependencies to be able to know the correct dependency list. You don't want to waste your time with ports which are listed as a implicit dependency but are not really referenced in source/object files (the feature in question is supposed to allow this). You also want to know about all ports which depend directly upon it (this is where we are not ready yet as not all ports list all explicit dependencies, an exp-build run would tell about the critical ones, user reports after switching the default would tell about edge-cases, some missing explicit dependencies may perhaps not get reported at all if there's a strong implicit relationship via an explicit dependency). - Users which don't want packages but have to rebuild a lot of ports (update of middleware ports) would not need as long to rebuild the ports, as only the explicit dependencies need to be rebuild. Imagine an update of libx11 which should be accompanied with an update of everything which depends upon it. You don't really need to rebuild all GNOME/KDE ports. In the current scheme one would request a "portupgrade -rf libx11" or something to this effect and it would rebuild a lot of ports which don't include any X11 includes or link to X11 libs directly (you don't need to rebuild your python or perl application which uses GNOME, you just need to update gtk and some other middleware/critical ports). - It may also motivate some people to work on some middleware ports when they see that the explicit dependency list to a particular port is relatively small (a huge number of ports which depend upon a specific port may afraid people which would be willing to maintain the port if there is a manageable amount of ports which depend upon it). I was tempted to say it also decreases the amount of time for =20 incremental package builds, but as the package dependencies change =20 (meta data for the portversion or portrevision) all packages which =20 have a changed port in their implicit dependency list will change and =20 have to be rebuild. So it doesn't cut down the official builds, but at =20 least the development und "user-update" time. Those are the most prominent benefits, maybe there are some more in =20 the meta-info department (maybe portsmon can use some of this info, =20 ...). Regarding the negative aspects I can only come up with the opinion =20 that it makes it harder / is more work to create a port (it came up =20 some months/years before when explicit dependencies where discussed). I question this opinion, as most of the time the dependencies are =20 listed somewhere for this software (readme/homepage/...). I also think =20 a good maintainer lists the explicit dependencies anyway (to not get =20 annoyed by pointyhat mails; and while you are at it, it is easier to =20 list all documented dependencies than to hunt down implicit =20 dependencies). Exceptions to this are very large "ports" like =20 GNOME/KDE (I take my hat off to the corresponding maintainers, you are =20 doing a great work in my opinion) where the dependency tree is huge =20 and the goal was to get it up and running completely (as of the =20 current way of registering implicit dependencies this is perfectly ok, =20 as it is not needed to do a cleanup of the dependency tree). But they =20 trade in work for the explicit dependency tree for testing work before =20 the next release of the mega-port to get a (more or less) smooth =20 update-experience for users. With an explicit dependency tree you can =20 let some automation tools like portupgrade/portmaster/exp-build/... do =20 the tedious work -> faster testing -> less total development time -> =20 faster turn-around time for updates. Have I missed something? Kris, what technical reasons are against =20 explicit dependencies, in your opinion? Bye, Alexander. --=20 Love is sentimental measles. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137