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

Bug#756816: apt: "apt-get upgrade packagename" should not set packagename to manually installed



Hi David,

David Kalnischkies wrote:
> > When doing dist-upgrades from oldstable to stable, I do them in very
> > small bits, so that no service has a downtime longer than necessary.
> > One of these steps usually includes bigger bunches of libsomething
> > packages which I surely never want to have the "automatically
> > installed" mark removed. (aptitude has one or more bugs which causes
> > that and it's already very annoying. But at least it doesn't do that
> > on purpose unless explicitly requested.)
> 
> This is a pretty unusual thing to do,

I disagree here: I know quite a bunch of server administrators
(including several DDs, Rhonda comes to my mind :-) which consider
this the _only_ way to properly dist-upgrade a server while running.
And yes, of course, the release notes only cover the all-at-once case
-- which is not suitable in all situations.

It may be less usual for one's own desktop system where a service
downtime is not that critical, though, or generally less experienced
users.

> > > [...] do I really want it to remove my favorite shell because it
> > > isn't needed anymore? ;)
> > 
> > Yes!
> > 
> > Yes indeed. Otherwise I would not have marked it "automatically
> > installed". All my favourite packages are in a local metapackages. If
> > that metapackages drops a dependency/recommends/suggests on a package,
> > I want this package to be removed.
> > 
> > I mean, that's what the "automatically installed" mark is for! The way
> > apt handles it currently looks as if apt thinks it knows better than
> > the local admin which package got the "automatically installed" mark
> > for good reasons and which not. Which IMHO is clearly wrong.
> 
> Yes, and no. Active management of the autobit requires exactly that:
> active management. Something not everyone wants to do. A lot of people
> got really scared then they removed iceweasel and apt(itude) suggested
> to remove all of gnome with it. Technically completely correct and the
> solution is easy for each user, but the chosen solution in the end was
> to handled metapackages differently (which isn't really nice either,
> which I want to change/discuss at some point, but different beast…

Yes, indeed. I also think the special handling of metapackages you
mentioned is the wrong way. But I do see why it's the default.

> I think active management is something aptitude users are more or less
> used to, as an interactive tool allows to deal with that easily, while
> a tool like apt-get, but also the higher-level tools like the various
> now-called software stores are expected to provide the perfect solution
> on first try without any tweaking – as the user either doesn't want or
> simply can't do the tweaking.

Then again apt-get isn't an App Store. Luckily. :-)

> (which in fact is how I use apt as I usually don't have an opinion on
> or-groups and stuff.

Indeed that's again a difference in how we work. I usually care about
alternative dependencies.

> I tend to check the removes – which unfortunately
> many people consider optional even in unstable – but thats it.

I must admit, I don't have much mercy for such people. (For me, that's
on a similar level as setting APT::Install-Recommends to false and
then complaining that a package doesn't work properly because of a
missing dependency for a specific feature.)

> I think you will agree that not everyone in the world is doing local
> metapackages.

Yes. But that was just an example. The issue is neither limited to
metapackages nor to local metapackages:

# apt-get upgrade libc6
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... libc6 is already the newest version.
libc6 set to manually installed.
[...]

# apt-get install libc6
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libc6 is already the newest version.
libc6 set to manually installed.
[...]

> And do you really think it is that surprising that if you manually
> request the installation of a (new version of a) package that it
> isn't marked as "automatically installed" anymore?

Yes.

> After all, you manually installed it…

No. I had to use "apt-get install $pkg" just because that's the
official (and only) way to upgrade a single package with pure APT. So
that was no "manual installation" request at all.

> I think the problem is more that we try to encode everything in
> a boolean flag here. In my book it would be more sensible to have more
> states here and options for the autoremover to switch between shades of
> "I don't want to think, please only propose something if you are really
> sure" and "*I* have marked packages explicitly, the rest is fair game
> for you as I will check what you propose".

Interesting idea. Not sure what the outcome would be, but allows for
new ideas and workflows. :-)

> > > If you want to upgrade a 'single' package, "install" is for you (which
> > > has the exact same behavior regarding the autobit).
> 
> I actually lied a bit:
> apt-get install pkgA --only-upgrade
> will actually do what you want without changing the autobit.

Thanks for that hint. Will have a look at it.

> > > Partial upgrades tend to lead to disaster,
> > 
> > Huh? Works fine for me for ages in general. Just not with apt-get but
> > with aptitude. ;-) That's one of things I like aptitude for a lot. And
> > is one of the reasons why I use apt-get so seldomly.
> 
> That wasn't a remark on apt-get/aptitude.

I know. :-)

> It was more a remark on how untested partial upgrades usually are,
> so that it isn't unlikely that someone forgot to raise a >= on a
> -common/-data/-whatever package.

>From my experince these issues were quite seldom in the past few
Debian Stable releases. I only remember one case of a missing
versioned dependency from Squeeze to Wheezy. (But already forgot which
package was affected. :-)

> It is also a remark on how people think they have installed a
> security fix by installing pkgA, while the fix is actually in
> libobscureA…

O.o  While I can imagine that people don't exactly know in which
dependency the actual issue is located, I can't believe that people
really try to fix issues that way.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


Reply to: