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

Re: Recommends for metapackages

Tomasz Rybak <tomasz.rybak@post.pl> writes:

> At first I thought it was a joke. But no, you really suggest that
> everyone who wants to have up-to-date desktop environment
> but without few packages (e.g. N-M or GDM) needs to create own package,
> own local repository, and looks into it every time there is upgrade
> to keep it current? And this is supposed to be simple?

Please read the rest of the mail, and the rest of the thread, where I
explain that Recommends gets you into the same manual bookeeping
situation anyway.

Unless, of course, you treat Recommends specially for meta
packages... and that is supposed to be simple how exactly?

> Do you really think that forcing many people to maintain their
> own repositories and metapackages is better  than just moving
> e.g. N-M or GDM3 from Depends to Recommends?

Forcing? No.

But it seems, I have to reiterate the solutions that are all superior to
downgrading stuff to Recommends:

0) Cherry pick packages by hand

Advantage is obviously that this is the most flexible way. Period.

Disadvantage: no easy way to remove everything in one go, and it's a bit
of a burden to follow the platform.

However, lets consider the average user using stable: how often does the
platform change? Zero times during a stable release. Zero. You might
have to follow changes during a dist-upgrade, but that, I believe, is

If you're not using stable, well, tough luck, but you made that choice
consciously, and should've been aware of the downsides, which may
include a bit of extra work on your part.

Still, even in that case, how often does or did the list of Dependencies
of the gnome meta-package change since squeeze? I don't expect it'd
changed much, save for the gnome2->gnome3 transition, and most of the
changes most probably wouldn't need followups anyway. If I'm mistaken,
please do correct me, however.

1) Use a custom meta package

The advantage here is that it's easy to do, easy to automate, and you
can easily follow the upstream meta-package, excluding only a few of its

The downside is obviously that you (or a script) has to maintain a local
repo. Personally, I couldn't care less what the tool that automates this
for me accomplishes that, as long as it can be fully automated (it can
be), but some may disagree.

And it's certainly not the most elegant solution.

2) Use dummy equivs packages

Instead of replacing the meta, you'd replace the dependencies you don't
want installed.

The advantage is that you don't have to maintain a local repo, and you
get to use the upstream meta as-is.

The downside is that you'll have a bunch of local dummy packages, and
you have to make them. Again, that can be scripted, and completely
hidden from the user.

Nevertheless, this is still not the most elegant solution.

3) Upload a gnome-minimal package or somesuch

The advantage is that it will have whatever you want. The downside is
that the maintainer must keep it up to date, and whoever disagrees what
constutites minimal, whill continue shouting.

Yet, this is straighforward, and places the burden on one person instead
of everyone who might want such a package.

X) Downgrade stuff to recommends

I do not consider this a solution, for reasons explained elsewhere,
where my main concern is that it breaks the assumption that installing a
platform (in this case, gnome) will install the whole thing, and it will
be available for my use at any time.

With recommends, there's a fair chance that a distinctly related package
forces part of the platform off, and the package manager will happily
remove them. Once the breakage is fixed, it will not reinstall them.

This can be worked around by removing the auto-installed flag from those
parts of the platform that I want to keep at all times, but then what is
the use of Recommends, when I have to cherry pick anyway? I could just
skip installing the meta, the net effect is the same (except, that
without the meta, there are no expectations to break).

> Think about all those hours wasted, times however many people who
> want to customise their desktops.

I still don't see the problem with installing a subset by hand. Advanced
users can script it, novices will only need to hand pick once. Done. 10
minutes job.

Compare that to the hours wasted trying to figure out what forced part
of the platform off my system and when, during an unattended
upgrade.. Yes, I do those, because I want to trust the system doing the
right thing, and keeping stuff I installed intact and complete.

If I have to double-guess the package manager, then there is something
seriously wrong. Recommends would force me to do that.


Reply to: