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