From owner-cvs-all@FreeBSD.ORG Tue Aug 7 09:17:35 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 E4BCD16A419; Tue, 7 Aug 2007 09:17:34 +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 82CFC13C48D; Tue, 7 Aug 2007 09:17:34 +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 6D9712E270; Tue, 7 Aug 2007 11:17:23 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 3E4465B5A04; Tue, 7 Aug 2007 11:15:10 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l779F9qf094973; Tue, 7 Aug 2007 11:15:09 +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 11:15:09 +0200 Message-ID: <20070807111509.ojm8nc4ao0g080ck@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 07 Aug 2007 11:15:09 +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> In-Reply-To: <46B7072E.8070307@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=-14.606, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10, SARE_LWSHORTT 0.79, SMILEY -0.50) 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 09:17:35 -0000 Quoting Michael Nottebrock (from Mon, 06 Aug 2007 =20 13:34:06 +0200): > Alexander Leidinger schrieb: >> Kris, what technical reasons are against explicit dependencies, in >> your opinion? Just to make sure we talk about the same: we don't want to disable the =20 recursive dependency resolution. We just don't want to record the =20 implicit dependencies in the package or installed port. So =20 +REQUIRED_BY of the installed package/port will be different, and =20 @pkgdep in +CONTENTS will be different, but the end result (the =20 installed ports/packages) will be the same even if we would change the =20 default _now_ (this is not a suggestion to do this), except that =20 pkg_add would not moan about old installed packages if they are an =20 implicit dependency. > Explicit dependencies would be great, if they can be guaranteed to be > correct, which basically means we need a way auto-generate them. Maybe Auto generation would be nice, but it doesn't need to be a hard =20 requirement. See below. > 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 ... I think this is a little bit over-engineered. Looking into the =20 binaries (maybe with objdump, ldd is not really suitable for this task =20 I think) for the references to libraries would be enough. How do you want to calculate the RUN_DEPENDS? > 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. I think it will be the same as currently. Things =20 which are not catched by pointyhat will be reported by users. I =20 repeat, even switching now would not change the dependency tree or the =20 installed port/packages, just what is recorded in the package =20 (+CONTENTS) and in +REQUIRED_BY (in the depedencies). As this =20 information is not complete ATM, it would not be possible to get some =20 benefits from this ATM. So there would be some work required to get =20 most of the ports up to the new feature level, but it would not break =20 the current feature set of the ports collection. I also think a lot of server ports already have all explicit =20 dependencies. The ports which require a lot of work are maybe =20 GNOME/KDE/..., so such a change would be a big impact for you (or =20 someone who is willing to track down) and the other maintainers of =20 those DEs (if you/they want to let users use this new feature for =20 those ports). As a maintainer you could decide to work as before =20 (which would maybe lead to some mails from sat@ or interested users =20 pointing out some missing dependencies ;-) ), or you can decide to =20 take care about the explicit dependencies (this can even be done step =20 by step). With an automation tool you would be able to catch some =20 LIB_DEPENDS very easy, so it would be not that much work for those. Personally I see this more of a mid-term to long term project where =20 users help the maintainers by reporting missing stuff, than a short =20 term project where a lot of work has to be done by a small amount of =20 people (maybe a little bit of initial work if an exp-build shows some =20 differences... but ATM I can not come up with a scenario where a lot =20 of ports break when we enable this feature). I would also expect that =20 after one or two major updates of GNOME or KDE the explicit =20 dependencies are in a very good shape automatically. Bye, Alexander. --=20 PLATONIC FRIENDSHIP: =09What develops when two people get =09tired of making love to each other. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137