Quoting Kris Kennaway <[EMAIL PROTECTED]> (from Mon, 6 Aug 2007
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
dependencies? We don't need to list the implicit ones, they are
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
dependencies and so on in a package. I call this implicit dependency
recording.
With explicit dependency recording I associate to only record the
dependencies in the package, which are listed in LIB_ or RUN_DEPENDS
of the corresponding port for the package.
What I propose and what is implemented with the feature switch which
triggered this discussion is: to do the explicit dependency recording
instead of the implicit dependency recording. The ports collection
resolves the dependencies recursively so we don't need to record the
implicit dependencies. They are superflous in +CONTENTS (similar for
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
talked about in a previous post. To get those nice properties, we have
to extend the LIB_ and RUN_DEPENDS of our ports with all those
dependencies, which the binaries of the port in question reference but
have not listed already in the Makefile. Not all ports in the ports
collection fail to have all dependencies, but those which fail them
are most of the time not easy (gnome/kde/... are a huge number of
ports and are the prominent ports which would need such a treatment).
When we switch to explicit dependency recording without adding the
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
to explicit dependency recording? If not, are there strong technical
reasons to not record all the required dependencies in the ports which
are missing them after switching to explicit dependency recording
(note: please see my other mail where I inlined scripts to
automatically find suitable LIB_DEPENDS lines for the common case)?
Kris, if you are concerned about the impact on the ports collection,
please make a exp-build run with this feature and compare it to a
normal run.
With my "linux ports which are handled by emulation@"-maintainer-hat
on I want to point out my cleanup long ago in the linux ports. A lot
of ports had no dependency to the linux_base port or linux-x11 port
then. It was tedious to find and clean up all linux ports. Now all (I
hope) linux ports contain explicit dependencies to their requirements.
It makes it very easy to test infrastructure changes for the linux
ports now because of the explicit dependencies. It's a huge
difference. The amount of work in the beginning was much (we hat a lot
of exp-build runs, Kris and me spend a lot of time around Christmas to
get it into a good shape), but it amortizes as time passes by (the
testing for the update from linux_base-8 to fc4 -- with fc3 in between
but not being an official linux_base port for the masses -- was much
much much faster and needed less exp-build runs).
Bye,
Alexander.
--
Signals don't kill programs. Programs kill programs.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
