Re: Recommends for metapackages
Andrei POPESCU <email@example.com> writes:
> On Jo, 12 iul 12, 17:44:52, Gergely Nagy wrote:
>> > Then some time later during upgrade it'll upgrade all packages
>> > but will not install N-M; at the same time it'll install
>> > new package that was added to Recommends in that new version.
>> As far as I remember, it will not install new recommends.
Hmm, right. dist-upgrade will pull new recommends in, indeed. Well,
there goes one argument against Recommends. The rest still stands,
>> But, the problem I'm talking about is not related to this. The problem I
>> see is when I have a gnome meta-package, that recommends, say,
>> totem. Now, lets suppose I'm also running unstable, for one reason or
>> the other, and a transition comes along, and something has a breaks on
>> stuff totem depends on, and the package manager decides to remove totem.
>> Weeks later, when I want to watch a movie, at the end of the world, with
>> no network connectivify, I realize that something pulled my movie player
>> out of me.
>> I would be very, very sad.
>> Of course, silly me, why do I run unstable? And why don't I pay
>> attention to what my upgrades do? Well, I run unstable because I work
>> with it, and it has up-to-date stuff I have to work with. And running
>> unstable is far easier than running testing and cherry-picking (did I
>> mention I hate manual bookkeeping?). I do unattended upgrades, because I
>> trust the system to keep everything I installed, installed. I installed
>> the gnome meta-package because I want the full thing, bells, whistles
>> and crap included.
> Sorry, but IMNSHO running sid with unattended upgrades just asks for
> trouble. But then again IANADD, if Debian wants to optimize for this use
> case who am I to disagree? :)
Similar issues can happen in stable, less often, and for different
reasons, but the possibility still exists.
Also - and this easily happens in stable too -, there's the problem of
trying to remove a dependency of a recommended package.
That will happily remove the recommended package, and keep the meta. A
user may or may not know what those strangely named packages that get
removed are, and making him look it up, and watch every upgrade like a
hawk isn't exactly friendly.
>> I could, of course, mark totem manually installed, but then I'm back to
>> manual bookkeeping, could've installed the whole stuff by cherry-picking
>> each component, and that makes the meta-package useless for me, and
>> destroys the argument that recommends would result in less bookkeeping.
>> Thus, here's an example where Recommends *will break* an existing
>> Oh, and since apt won't install new recommends on upgrade, to the best
>> of my knowledge, I won't get totem back once the
>> transition/breakage/whatever is fixed, either. While if it would be a
>> dependency, the upgrade would abort, because it'd try to remove a
>> package marked as manually installed.
>> But similarly, if I ran stable, and one of the meta packages I installed
>> had a recommends on a piece of software, and I try to install something
>> that conflicts with it (either directly, or indirectly, via another meta
>> package, for example), then this piece of software gets removed. I may
>> or may not notice that - I might not even know wtf totem is, a novice
>> user who first sees Linux certainly won't - so it gets removed.
> Well, if the purpose of the Depends are to protect a novice from
> removing packages by mistake that surely a package manager offering to
> remove 100+ packages should definitely sound an alarm.
Yep, and it sounds an alarm: "do you want to remove all this stuff,
*including* the meta?"
Vs "do you want to remove 1/10 of that stuff, most of which you never
heard of so who cares?"
> But with apt-get you will get only two packages uninstalled (the package
> with the conflict and the metapackage depending on it). The big surprise
> will come only later, when apt-get suddenly suggest you should run
> 'autoremove' to get rid of some 100+ packages that look like not needed
Yes. But it's easier to notice the removal of gnome (and stop it), than
the removal of one of the components of the platform, of which one
possibly never even heard of before, just uses, as it's part of the
On one hand, you have, in the depends case:
# apt-get remove gstreamer-plugins-good
Which will try to remove the whole world, including the meta, and that
will ring alarm bells.
Or in the recommends case:
# apt-get remove gstreamer-plugin-good
Which will remove a bunch of stuff, but leave the meta installed.
In the latter case, you have gnome installed, without a video or audio
player. Gnome sucks.
Similarly, depends protects the novice from removing parts of the
platform, it provides a guaranteed set of packages. For the advanced,
there are ways around the Depends, easy ways. Recommends does not
protect the novice, and offers very little advantage for the advanced.
>> As far as I'm concerned, this defeats the purpose of the meta-package,
>> because it breaks my expectation that whatever else it pulls in, will
>> stay there as long as the meta is installed.
> Did you consider creating your own meta-package? It shouldn't take you
> more than 5 minutes to write an apt hook to get the control file and
I did not, as the existing meta-package works exactly how it should, and
fulfills my expectations. If it bothers you so much, you can do the
s/Depends/Recommends/ too. ;)