Could you please make apt not mark packages as manually installed when installing packages that have been kept back in specific? Alternatively, the user could be asked whether they want to have it marked if the mark would be added but I think most users would not want that. It makes little sense and only causes problems, partly because they then won't uninstall when removing packages that depend on them. The packages could also be marked differently such as "kept-back manually installed" and there could be a parameter for marking it as manually installed like it is now. This is a common problem and it's recommended or best practice to not mark them as manually installed, see: https://askubuntu.com/questions/601/the-following-packages-have-been-kept-back-why-and-how-do-i-solve-it Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956330
Control: forcemerge 956330 -1 You found with #956330 already a feature request that asks for that, so I am merging this one with it as even in the best case this could only be considered a sub-task (if at all). Note that "phases upgrades" have their own listing now, but you might be better of asking in Ubuntu support channels about this as Debian doesn't use the Phasing feature at all. In #956330 Алексей Шилин actually makes a good point about an install request having predictably the same outcome. In any case, I think in part this comes from a conceptional disagreement: I don't think 'install' is meant to "force" an upgrade of a package, but it can have that side effect and so some users end up using it for that side effect: Well, see, that is the thing: If you don't use 'install' to force random packages to upgrade it turns out that you 'install' things you care about and don't want removed as unneeded later on… But how should apt differentiate between "apt install firefox": - I dislike Chromium, let me try out this other browser - … that I had never installed before - … that I had installed in some old version years ago - … that happened to be removed recently - … oh, I have it already installed? Didn't know! - … that I have already installed as a dep, but now I am active user! - New version is phased, but I want it now now now because - … that's my beloved browser I want always latest and never removed - … friend said I should test this new version early - … I have no idea what it is, but upgrades are good, right? - Critical security bug! The announcement tells me to upgrade - … no time to upgrade everything, lets just pick that one - … unattended-upgrade did it all before me - Whoa! autoremove tells me it wants to remove my beloved browser, lets install it explicitly to make it stop that - Ups, I let autoremove remove it! Lets rectify that mistake! And that aren't even all… so I certainly have some sympathy for the predictable outcome mentioned and conversely not putting too much value in what it means that a package is marked manual or auto installed as it effectively just guards against suggesting auto-removing packages the user somehow showed they cared about at some point with a failure mode of just keeping some dead weight around. Giving it more value means we would need to involve users a lot more in the management of it, which many would probably be happy to do, but many also not appreciate much given the failure mode is so low key. Best regards David Kalnischkies
No, that other issue is not about kept-back packages in specific. I don't see how the functionality of that issue would be very useful but for kept-back packages asking the user or by default not marking them as manually installed could be very useful and seems more like what one would expect it to do. Do you mean phased updates? Whether or not you meant that, I don't know what you mean there (what and how it relates to this issue). This is about kept-back packages where install is used to make them install.
their name appeared in the kept-back list or you explicitly install that package from the kept-back list because you care very deeply about it? APT isn't keeping back a package because its bored. It has reasons, different ones even, and the general reply from a user to it should be: "Okay" and not "Lets try to force it". In some cases that force will not work and end in failure (unsatisfied dependencies), in some cases it will lead to non-optional solution which might lead to problems later on (unsatisfied recommends), sometimes its an ongoing transition that apt decides to wait on instead of applying (which usually means a bunch of stuff has to be removed), sometimes the distro itself decides that newer versions are shipped piece meal to different users to avoid potential issues hitting them all at once (phasing) and sometimes a user has explicitly put that package on hold. I probably forgot a few more possibilities. No it isn't because that isn't how apt sees it. You might remember that in a previous request you made apt might have said that about a package, but apt has no such memory. What would that memory even be given that your last request could have been something between complete bogus you would prefer to pretend to have never entertained and a heartfelt "I can't do without you" plea. Would that memory be time bound: If its two seconds later, its related, but if it was last week, it is not? That would turn quickly into a complete mess of unpredictable behaviour. So, even if you think you are forcing apt with an install request to install a package version it decided to keep back in a previous request, for apt you are "just" asking it to install the given package, period. apt could ask about if it should modify the auto/manual installed state based on your explicit manual install request (<- note the wording choice) for a package you attempt to upgrade (compared to new install), but it currently doesn't and that is what the request I merged it with is talking about. Best regards David Kalnischkies
I and many others (this issue is not about me) install them like that because their name appeared in the kept-back list. So it's the former and I never said it wouldn't be that. Well then part of this would be to make it run a check if any of the packages to be installed is currently kept-back. I never said it would have to keep prior apt commands in mind, it just knows (can check) which packages are kept-back. In the usual scenario the notice about a kept-package displays during an apt-get upgrade/update command. This issue is not about installs that are explicitly manual and it shouldn't be merged with other issues that are about something else.
And I tried to explain to you that many others believe in the exact opposite: That the package they asked to be installed is of course important enough for them that it should be marked manual. Just because you can find people who complain about the current behaviour doesn't mean there aren't people who like it – they just have no reason to complain. If everyone would always listen to complains we would have blasted the sun from orbit ages ago. All the glaring, sunburn and oh god, its so hot some times… and I heard the sun is the main cause of global warming… 😉 sense. kept-back is a property of the specific request you just made: Just like all the other packages listed as new, remove or upgrade. A package might be phased (repository) or put on hold (user) and for that reason appear in kept-back (or not, as said, phased is display nowadays in another list), but that is still related to the request as if you explicitly request that package name they are not considered kept-back and while the kept-back-reason package-was-put-on-old-by-user is checkable (and apt checks that and even prints a warning about that: Changing held packages) most reasons for kept-back are not as if you explicitly install a package the question if other packages can or should fiddle with its state never arises. "Worse" it might lead to other packages being kept-back like the other side of a transition that was previously winning the tug of war. Your sysv-rc-conf is kinda an example: A normal upgrade doesn't do it because it is deemed not a good idea to prefer this over 20 other packages. Removing the package serves no real purpose either through, at least not if the user isn't asking for it – after all, who likes packages being removed needlessly. If you explicitly request the installation that is no longer the case: Everything is okay for the benefit of respecting the user request, so 1, 20, or 2000 pkg to remove are not a problem even if it includes systemd-sysv, the default init process and the only one many packages are nowadays prepared to work with. Any package who looses the ability working with anything else but systemd-sysv would in that scenario be kept-back even through it happily upgrades if you don't ask for sysv-rc-conf explicitly. request for some-pkg. Just because you wish it to be something else doesn't make it true. The observable difference is if some-pkg was previously not installed (in which case it is installed and tagged manual installed) or if some-pkg is currently installed. For the later, two cases exist: Either the candidate version is installed or it is not which both want to ensure the same outcome: The candidate version is installed. The only question that arises is: Should that ALSO, like the first scenario set the package to manually installed given its installation was manually requested. The answer so far is yes – and you insist on it being changed to no, while I keep telling you that there are usecases/scenarios for both, so an acceptable compromise might be to implement both and offer a choice… Best regards David Kalnischkies
Sure, I'm aware of that. Once again, this is about kept-back packages. When kept-back packages in specific are installed through apt-get install, then that is usually not because the user wanted to mark them as manually installed, something many don't even know exists at all or for years, but because they want to solve the problem shown when upgrading their packages. Those who actually want to mark it as manually installed *for kept-back packages* could still do so. I'm not complaining, just pointing out an issue and that issue may not be clear to those who used Debian and apt-get for years/decades and for example assume that the users know everything they know or should be required to (and that right from the time of their first upgrade problems). Another option would be to display a prompt like "The following packages have been kept back ... If you want to install them as if they were dependencies, run sudo apt-get install --fix-held-back ..." so that the user just runs that instead of the normal install command but I don't think it would be as good as the thing proposed here for example because such a command doesn't exist. I think any issues you bring up that could, probably rarely, exist if the package is not marked as manually installed could be solved and they also exist for solutions like the top recommendation (--with-new-pkgs) in the top answers here https://askubuntu.com/questions/601/the-following-packages-have-been-kept-back-why-and-how-do-i-solve-it packages I guess I just remove it. But why does require so many packages to be removed, seems like it would need to be upgraded properly so it doesn't require that? Fair point, but then please change it so that the process of resolving kept-back is different. That could be a prompt the user needs to confirm, a prompt displaying another command the user could run (or several options), or something else. Basically this issue is broadly about how kept-back packages are installed with the only best feasible solution I came up with being that the install command simply doesn't mark them manually installed by default (except if for example a parameter is used). Yes, having a choice there would be good but if you're referring to the other issue with that, this one is only about kept-back package installation (that is ways that treat these different from any other package installations such as running certain code if it detected it to be a kept-back package).