Re: Recommends for metapackages
FTR: Please don't CC me on list mail. I'm tired of setting M-F-T.
Tomasz Rybak <tomasz.rybak@post.pl> writes:
> Dnia 2012-07-12, czw o godzinie 15:46 +0200, Gergely Nagy pisze:
>> 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.
>
> I might be misunderstanding situation with dependencies here then.
>
> Let's assume that I have set my system to install recommended
> packages by default and I try install "gnome" package.
> It has some packages in Depends, some in Recommends.
> If it has N-M in Recommends, I can unselect it during installation.
Yes. And you can remove it later too.
> This will result with my system having gnome with all its dependencies
> and recommendation installed except for N-M.
Yes.
> 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.
> It this correct description of apt behaviour, or have
> I misunderstood something?
More or less, except that to the best of my knowledge, it will not
install new recommends on upgrade. And that makes sense, and is good so,
otherwise it will attempt to install all recommends I explicitly did not
install on each upgrade - no thanks. (Or we need to introduce yet
another complexity into the system, to mark packages as
not-to-install-ever. I doubt we have that now... but perhaps hold on an
uninstalled package works that way? I don't know.)
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.
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
system.
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.
It won't come back, unless I install it.
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.
Perhaps that is a silly assumption, but if it is, then there's no point
in having anything in a meta's depends at all, as it's pretty much a
supermarket you can cherry pick from. In that case, I would be very
disappointed.
--
|8]
Reply to: