Re: [RFC] DEP-6: Meta-Package debian/control field
Steve Langasek wrote:
> On Sun, Dec 20, 2009 at 09:30:04PM +0100, David Paleino wrote:
>> > Ubuntu defines a special archive section, 'metapackages', which results
>> > in special tagging/handling of the Depends and Recommends of the
>> > package so
>> > that they're not autoremoved if the metapackage is removed. This is
>> > implemented in the high-level package management tools.
>
>> Well, our proposal prospects something different: the metapackage is not
>> removed (thus everything else is not autoremoved) if one of its Meta-
>> Depends/Depends is removed.
>
> From what I can tell, the only difference between the two implementations
> is compatibility with disabling installation of Recommends by default.
And, how do you achieve that?
I mean, meta-packages should *always* have their Recommends installed,
otherwise they have no point in existing.
If we use Recommends instead of Depends, that becomes configurable with
APT::Install-Recommends (or similar), and we totally miss the point of this
DEP (and of meta-packages).
> I don't think this is a good rationale for adding yet another package
> relationship field. The Recommends field is *already* defined in Policy
> to have the behavior you're looking for (installed by default but not a
> hard requirement), and I don't see any reason that metapackages should
> need the added complexity of a different field.
Then, how do you differentiate between "genuine" Recommends and "meta-
package" Recommends?
I only see two ways: Meta-Package: yes (but, like Daniel pointed out,
changing the behaviour of a field basing on another doesn't seem so clean),
or Meta-Depends (or whatever you want to call that).
>> > In this scenario, with Recommends installed by default (the only sane
>> > model),
>
>> On my host, Recommends are not installed by default, and this is
>> configurable. A similar configuration, and meta-packages using Recommends
>> instead of Depends/Meta-Depends, would render them pretty useless.
>
> There are good reasons for it to be configurable:
>
> - it's useful for debugging purposes
In what ways? But this is getting OT now :)
> - in cases of specific packages, disabling recommends-by-default and then
> hand-selecting the ones you want may be more efficient than installing
> all recommends and selecting those to remove afterwards
This should be on a per-package basis, don't you believe?
# apt-get --no-install-recommends install metapackage
But then again, I don't see a point here either.
What's the use of a metapackage if you only choose 2-3 from, say, 20-30
"dependencies"?
You'd better go with selecting those 2-3 directly. At least IMHO :)
Try to change your POV from the uber-user, who knows how to install "base"
packages and let others be pulled in, to the low-level users, which want
"gnome" installed, but don't want "rhythmbox" nor "banshee" installed. This
is what they do (writing the CLI version, but they're likely to use
something like Synaptic):
# aptitude install gnome
# aptitude remove rhythmbox
OOPS! Since aptitude does "autoremove" by default, the users suddenly get
asked to remove all their desktop environments. How many requests of this
type have you seen on IRC, mailing lists, Usenet? I've seen *TOO MANY*, and
that's why I drafted this DEP in the first place.
Definitely no, I don't think this is a marginal situation not worth doing
some implementation work. (and I could help making patches, where I can)
> - it's how we want buildds and developer build chroots to be configured,
> so
> that build-dependencies aren't overlooked because they're usually
> installed as recommends
Uh?
Could you explain a bit more?
> But that doesn't mean it makes sense for users to set this setting
> globally on their systems, or to design further complexity into our
> package manager to accomodate such configurations.
How would this be any "complex"?
I mean, maybe handling a "blacklist" might be, but we're already having the
"auto-installed" vs. "manually-installed" lists, so adding a new one
shouldn't be too hard.
Also, since Meta-Depends would act as Recommends, with the only difference
that it's not configurable, I can't see any complexity in changing the code
from (pseudo-code):
if field == "Recommends":
# do something, and handle APT::Install-Recommends
to:
if field in ["Recommends", "Meta-Depends"]:
# do something
if field == "Recommends":
# handle APT::Install-Recommends
?
This might be a bit simplistic, I agree, but I hope this clears my point.
>> > the vast majority of metapackage dependencies are moved from
>> > Depends to Recommends, so you can remove those Recommends manually
>> > without forcing removal of the metapackage;
>
>> This already happens now, or did I miss something?
>
> The difference is that the packages that are now listed as Depends would
> be moved to Recommends.
And they could be not installed at all, depending on the user's
configuration, which we do not want to happen.
Kindly,
David
--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Reply to: