Date: Tue, 07 Aug 2007 11:15:09 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Michael Nottebrock <lofi@freebsd.org> Cc: Kris, Henrik Brix Andersen <henrik@brixandersen.dk>, cvs-all@freebsd.org, ports-committers@freebsd.org, Pav Lucistnik <pav@freebsd.org>, Kennaway <kris@obsecurity.org>, cvs-ports@freebsd.org Subject: Re: cvs commit: ports/Mk bsd.port.mk Message-ID: <20070807111509.ojm8nc4ao0g080ck@webmail.leidinger.net> In-Reply-To: <46B7072E.8070307@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Michael Nottebrock <lofi@freebsd.org> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070807111509.ojm8nc4ao0g080ck>