Dear APT Developers, it seems that -- despite the documentation suggests otherwise -- you now can pass package names as parameter to "apt-get upgrade" and it does what you expect: Try to upgrade only that package. But it also seems to set the given package to "manually installed" for which there is no reason at all: # apt-get upgrade zsh Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... zsh is already the newest version. zsh set to manually installed. <---------------- This shouldn't happen! The following packages were automatically installed and are no longer required: […]
Control: retitle -1 document "apt(-get) (dist-)upgrade pkga pkgb-" No, they don't do that, at least it is not intended. (dist-)upgrade is performed as usual, the packages you can provide are just hints. Imagine a dist-upgrade which has to decide between A | B and chooses A, while you prefer B. "apt-get dist-upgrade B" will take care of this – as well as "apt-get dist-upgrade A-" in that case. In the past you would have to either manually upgrade certain packages earlier or set them on hold or something to make such a choice. Michael (git d8a8f9d7) should have documented that though. package explicitly on the commandline, you properly don't want apt to suggest its removal later on. 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? ;) If you want to upgrade a 'single' package, "install" is for you (which has the exact same behavior regarding the autobit). Partial upgrades tend to lead to disaster, so that we see no real point in exposing them more directly – at least not in favor of more useful cases. An interactive tool like aptitude can do that differently of course, but we have only the commandline available for decision making… Best regards David Kalnischkies
Could we get rid of it for the "apt" tool? We have apt-mark to set manual/automatic, so there's not much point anymore. Especially since this often happens by accident (at least for me, with install).
Hi David, thanks for the explanations. David Kalnischkies wrote: done that. JFTR: I looked IIRC in the man-page for apt-get, maybe also in the one for apt. IMHO such a behaviour is highly non-intuitive. This is definitely a thing where aptitude's behaviour is way more consistent and intuitive. "aptitude full-upgrade ~slibs" just does what I mean: Upgrade all package in the section libs without marking them suddenly as not automatically installed. Ah, that kind of hints. Should be documented at least, yes. I though still think aptitude's behaviour is the more intuitive one. Well, that is one of the reasons why I usually prefer aptitude for dist-upgrades. I don't have to press Ctrl-C and think about which packages I have to pass to apt-get to make it understand what I want. In aptitude I can do that just interactively and I'm done. (I don't want to start a flamewar here. I just want to point out what I used to. It likely explains how I come to my expectations. :-) 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.) 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. Which I disagree, too. For the very same reasons. 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. Ok, maybe I'm really too much of an aptitude user to fully unterstand that reasoning. :-D Anyway, thanks again for all these explanations. I think, I understand apt-get a little more than before. And IMHO it clearly shows why there are both, apt-get and aptitude, and what's their use cases. Much appreciated, despite my disagreement. :-) Regards, Axel
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). 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". apt-get install pkgA --only-upgrade will actually do what you want without changing the autobit. 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.
Hi David, David Kalnischkies wrote: (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. 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. Then again apt-get isn't an App Store. Luckily. :-) Indeed that's again a difference in how we work. I usually care about alternative dependencies. 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.) 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. [...] Yes. 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. Interesting idea. Not sure what the outcome would be, but allows for new ideas and workflows. :-) Thanks for that hint. Will have a look at it. I know. :-) 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. :-) 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
[...] While it's not precisely equivalent, there's a reason that openssl DSAs now include the text "It's important that you upgrade the libssl1.0.0 package and not just the openssl package". Regards, Adam
As said, I don't doubt that people are doing it, it is just that it is not the default/recommended way of doing it, so it is also not the default mode of operation. Well, it is… It lacks the graphic "clickiness" of course, but you will agree that you don't (usually) do fine-grained choosing in the dependency tree, but 'apt install foo' and hit y(es). If you would, you would be using something with more feedback (like aptitude). You e.g. get no choice regarding which version to install. A successful execution of 'apt install foo' will result in foo being installed in the candidate version, regardless of it is was already up-to-date, needed to be upgraded or was an entirely new install (which is also why 'install' combines "install new package" and "upgrade existing package") similar to how you click on the install/run button in an app store and it will be there and optionally executed. What is the problem with that? Do you say that because libc6 is a library and therefore should be always auto-installed, no matter what? If so, people will disagree with you… (think third-party binaries, compiling yourself, …). (see also next one) a single package, but that isn't the default mode of operation. If I understand the ancient records correctly, apt was supposed to replace specifically crafted upgrade scripts as upgrades of packages had to be done in a specific order by a human before. With this backstory, apt always has a whole-world approach to everything and in this world-view a "upgrade only a single package" simply doesn't exist. The whole point was to get away from "first upgrade this, than this and than that" mentality after all! In this mentality, seeing a package name on the commandline means the user explicitly cared for this package to be installed (in the candidate version) and hence will miss it if apt goes on and autoremoves it as if he would just be interested in a (security)bug-free system he would just do a (dist-)upgrade. Or in other words: While aptitude has a similar commandline interface, it has a different mentality – so while they are 100% compatible, they aren't exchangeable… (would be boring if they were, right?). stable/some derivative. Not that this would be a recommend way of doing things, but people do it and expect it to work – much like you will be the "personal friend" of many DDs if you tell them that they should just enable recommends (and read the debian-policy) [as a comment to another paragraph in your mail]. As one simple datapoint: I tend to forget ensuring a fitting version sync between libapt and apt (as the later depends on the former, but the former needs the later for some operations – fun in circles) and I doubt I am the only one. I was indeed thinking about OpenSSL here, but that also frequently happens if we have a security bug in apt, which is in fact in libapt. I doubt it is much different for any source package building more than one package if they don't happen to have a =-relation. I would bet a fair bit of money that this was a(nother) reason to adopt the 'all or nothing' mentality in apts design back then. Best regards David Kalnischkies