Bug#1068774: (No Subject)
> And I tried to explain to you that many others believe in the exact opposite 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 > 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 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? > That is an explicit manual install request for some-pkg. 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).
Bug#1068774: (No Subject)
On Sat, Apr 13, 2024 at 11:52:32AM +, mYnDstrEAm wrote: > > So, which is it: You install random things you don't care about because > > 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? > > 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. 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… > > 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 > > 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. 'update' doesn't display something about kept back because that makes no 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. > > based on your explicit manual install request > > This issue is not about installs that are explicitly manual and it shouldn't > be merged with other issues that are about something else. You enter "apt install some-pkg". That is an explicit manual install 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 signature.asc Description: PGP signature
Bug#1068774: (No Subject)
> So, which is it: You install random things you don't care about because 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? 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. > APT isn't keeping back a package because its bored. It has reasons ... Thanks for the explanations. One only sees which packages it would install or remove when one tries to install it, like so for sysv-rc-conf that wants to remove countless core packages: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042467 (still no reply there) / https://unix.stackexchange.com/q/748950/233262 (how to see why) This issue however is not what happens when one checks what it would do when installing a kept-back package or about what could go wrong with installing it, it's about how the package is marked when one already decided and went ahead with installing it. > 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 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. > based on your explicit manual install request This issue is not about installs that are explicitly manual and it shouldn't be merged with other issues that are about something else.
Bug#1068774: (No Subject)
On Thu, Apr 11, 2024 at 10:43:38PM +, mYnDstrEAm wrote: > > You found with #956330 already a feature request that asks for that > > 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. So, which is it: You install random things you don't care about because 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. > This is about kept-back packages where install is used to make them install. 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 signature.asc Description: PGP signature
Bug#1068774: (No Subject)
> You found with #956330 already a feature request that asks for that 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. > Note that "phases upgrades" have their own listing now 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). > it turns out that you 'install' things you care about and don't want removed > as unneeded later on This is about kept-back packages where install is used to make them install.
