[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] DEP-6: Meta-Package debian/control field

Steve Langasek wrote:
> From what I can tell, the only difference between the two implementations is
> compatibility with disabling installation of Recommends by default.
> 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.

Without this metapackage thing, the only option we have is to have so
many many metapackages, so we can choose one of them. This is not very
nice, because that means that maintainers have to have the will to do it
(which wont ever be the case for all of them). Which is why a real
system to manage this would be nice.

Another point would be that a meta-package could add a new
meta-dependency in a new release.

> Try to change your POV from the uber-user, who knows how to install
> packages and let others be pulled in, to the low-level users, which want
> "gnome" installed, but don't want "rhythmbox" nor "banshee" installed.
> 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.

EXACTLY! This is not only because of requests, this has annoyed everyone
for a long long time.

>   Then I suggest you just help converting the gnome metapackage to a
> task, since this'll work with no intrusive changes in our tools.

Well, the issue is not ONLY with gnome, there are many many more. For
example the X system installing all drivers, then you want to remove few
of them that you don't care and identify as not for you, but keep all
the rest of "just in case". I see few other examples in packages that I
maintain myself where removing 1 or 2 package could be nice, still
keeping new packages that would come with the metapackage in case of an
upgrade, and giving freedom to users to do what they want.

Andreas Metzler wrote:
> The current proposal is not backwards compatible since it fundamentally
> changes the meaning of Depends. Depends is transitive. If A depends on
> B, and B depends on C. A can rely on functionality proveided by C.
> Your proposal breaks that, since it allows removal of C (assuming B is
> a meta package), keeping it installed in a broken state.
> I am not convinced that the gain (easily install KDE without kmail, or
> something like that) is worth this price. It changes a clear relation
> to something that most of the times works as expected, except for some
> special cases.

I do agree that the proposed implementation is bad, and that Depends
should not change meaning. I do like more the Meta-Depends: instead of
Depends: if we want to keep the original idea. How about having a
differentiation about the idea and the implementation in this discussion? :P

Also, I think having a Metapackage: yes field IS a good idea anyway,
even if there's absolutely NOTHING ELSE implemented with it but search
functionalities, which would be very convenient (unless there's also
Meta-Depends, but we could imagine a package that would like the
functionality of Meta-Depends and still not being a Meta-Package and
installing useful files...). Does the majority agree with me on that
point here?

Just my 2 cents, as I wont be the one implementing anything... :)


Reply to: