I agree with Eugene: the spec as presented is flawed. All package
management tools (you forgot to list dpkg) treat Depends-satisfaction
as an invariant, and there isn't really a compelling reason for this
to change. The wording you present is a little confusing, but once
you work through it, it's clear that it says "treat Depends on this
package like Recommends". Except that there may be an "unless you
don't" tagged on.
I actually would prefer a Meta-Depends sort of solution. The
"dependencies" we're talking about are really not package dependencies
in the normal sense at all, and we shouldn't be confusing them with
normal dependencies. IMO, that basic conflation, while a convenient
and expedient hack when it was introduced years ago, is the cause of
our troubles.
Arguably, your Meta-Package proposal really says "change all Depends
to Meta-Depends if Meta-Package is true". However, I don't like
making the meaning of Depends dependent (hah) on another package field,
or overloading the meaning of such a basic part of the package system.
For instance, dpkg shouldn't care about metapackages at all (IMO), any
more than it cares about Recommends; this is a high-level concept that
doesn't have to do with guaranteed relationships among installed
packages.
I also don't like the definition of Meta-Depends as "like Depends,
except <foo>"; I think that the behavior and intention of Meta-Depends
are different enough that they should be described explicitly.
To summarize: if we're going to introduce a new package relationship,
I'd like to see us do it right and up-front rather than "on the cheap"
with a hack we'll have to live with for years.
(I apologize for not including my own proposal in this mail, due to it
suffering from an acute case of non-existence; if I have time I will
write one, but please don't count on that what with holidays and real
life and all)
Cheers,
Daniel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
