> > On Sat, Aug 02, 2014 at 02:02:50AM +0200, Axel Beckert wrote: > > > But it also seems to set the given package to "manually installed" for > > > which there is no reason at all: > > > > Well, there is apts usual reason: If you care enough to mention the > > package explicitly on the commandline, you properly don't want apt to > > suggest its removal later on. > > I definitely disagree here. IMHO this is very non-intuitive behaviour. > > 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, so don't expect the defaults to be helping you with this. The release notes are pretty specific in how you should be doing a dist-upgrade… (more of a general remark, not specific to this one here). > > I can't say I am a huge fan of that, but it is at least very consistent > > and avoids that the autoremoval is overagressive – or 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… I just mention it here, because some of what you think are bugs above are probably caused by this). 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. (which in fact is how I use apt as I usually don't have an opinion on or-groups and stuff. I tend to check the removes – which unfortunately many people consider optional even in unstable – but thats it. I choose the stuff I interact with directly, for the rest I don't care…) I think you will agree that not everyone in the world is doing local metapackages. Or wants to deal with package management below the level of install/remove what he likes (not). 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? After all, you manually installed it… 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". > > 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. > > 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. 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. 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… Best regards David Kalnischkies P.S.: I will be offline starting tomorrow, so don't be suprised if I don't answer in the next ~weeks.
Attachment:
signature.asc
Description: Digital signature