Subject: Re: pkg_alternatives as a dependency, again
To: None <>
From: None <>
List: tech-pkg
Date: 02/11/2005 16:44:56
On Fri, Feb 11, 2005 at 09:59:56AM -0500, Todd Vierling wrote:
> On Fri, 11 Feb 2005, Greg A. Woods wrote:
> > The whole idea of trying to give a common name to some alternative
> > package with a scheme like pkg_alternatives is totally bogus from the
> > get go.
> Maybe to you, but not to a lot of users.  It helps system maintenance tasks
> that otherwise would require...

Since I'm not doing any work on or for pkgsrc (except when the GIS
KerGIS will be ready for public to provide directly a pkgsrc package)
my opinion here is simply for what is worth.

With this kind of features, pkgsrc will reach some behavior that quantum
mechanics has made well-known.

The true level of a package system is... the system as a whole. Here you
are trying to accommodate for elements that are sub-elements i.e. users.
But users are linked variables (they share this system), and the
alternatives will try to accommodate one user, his very desires, and in
the same time dis-accommodate the others (that have other desires), just
like in quantum mechanics if you want to have a fine value for some
property, you can not have the finest values for the other
related/linked ones.

alternatives are too much fine grained and they will become a nightmare.

IIRC, the origin on Debian for the alternatives was too provide some way
to call a program _for a package_ that could have different values.
Example, since the concept of a well defined system is unknown, the MTA
may vary and packages could call a well known name (symlink) pointing to
whatever MTA was there. If I'm not mistaken, this had, at the beginning,
a justification on the package system (due to what I now consider a
flaw: not having a core well defined, well tested, limited system), not
on the user side.

Just my 2 cents.
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>  |
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C