On Sat, Apr 13, 2024 at 11:52:32AM +0000, 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
