Control: reassign -1 runit 2.1.2-35 Hi, On Fri, Apr 24, 2020 at 01:54:42PM +0200, Lorenzo Puliti wrote: > Control: reassign -1 apt 2.0.2 > > Dear apt maintainers, Tipp: Your message does not automatically reach the maintainers of a package you reassign a bug to, only the 'Processed' notification might which is easy to miss, so you should CC them manually e.g. with packagename@packages.debian.org, see also dev-ref §5.8.3 (2). > Please implement a logic where apt parse the alternative recommends in order and pick up > the first that does not require a removal of any installed package in the system. If none > of the listed recommends can be installed without removing any packages, then I think it's > ok to pick the first listed. Such heuristic ideas come up every once in a while, but sadly they do not work in generic case. Your specific heuristic would currently be near impossible to implement in apt and it isn't easy to answer who it is that "requires a removal": If A conflicts with B and you want to install A, A seems to be the culprit, right? Well, what if you wanna install B? Is it Bs fault A has a conflict on it? What if C is a M-A:same package where i386 wasn't built yet but amd64 is and B depends on >= newer. We will need to remove C:i386 if we want B, but that isn't Bs fault, is it? A fan favourite is the heuristic "needs the least new packages". Seems reasonable, right? Yes, until you consider that near no-op packages like discarding MTAs or memory-only settings managers are the best choice then. Apart from these, the general problem with these is that we get more "magic" meaning that you need to understand and keep a lot more state in your head to understand what is going on. Many people don't understand what apt is doing now, what happens if we make it even harder… What you want to express here is a conditional dependency: if A is installed: install B (else C). We don't have these kind of expressions and I highly doubt we ever will as that gets funny rather quickly as well (if A is later installed, do we need to install B now? Of course not you might think, but look at the recommends discussed here: It could make sense…). That said, we might eventually solve certain sub-cases (think: language packs, virtual package provider choice, …) but that is a LONG way off, certainly nothing you could wait for and put this issue on hold for the time being. Also: Even if we had it tomorrow, there would still be the issue of apt/stable not supporting it, so we still have the exact problem in stable→stable upgrades. So, you have to resolve this one way or the other and I am therefore handing this bug back to you. > Note that this bug is not easy to fix on runit side: > * changing the order of the recommends will cause the same issue for sysvinit users Note that I have *NO IDEA* about runit, init systems or the various dependencies surrounding it, so I have no idea if runit is a package a user is expected to install (in which case choosing the right is relatively easy) or if it is e.g. a common dependency of other packages in which case that seems less okay. I am probably stepping on a few landmines now, but the first choice in an or-group should be the least surprising option for the most users. If you aren't sure, that usually achieved by going the route of "default install" needs this one simply because everyone who isn't on the default is more experienced and can deal with choosing non-default options in related cases as well. Also, if there is a reasonable way of making use of runit without either of these recommends installed, then the recommends is indeed wrong. Debian policy is quite clear that Recommends isn't a "just in case", but "for everyone, expect unusual". It MIGHT (remember, I have no idea) also makes sense to integrate into all init systems by default instead of asking the user to pick one via the recommends and do something about it at runtime. Anyway, as there is nothing apt can really do about this I have to reassign back even if I dislike bug-pingpong. Feel free to ask if you have come up with a specific solution for your problem and want some feedback from us regarding apt, but be prepared to explain a lot in your question as apt developers are "only" (FSVO) experts in apt, not in the dependency trees of all of Debian (you may consider us the rubber duck debugging of dependency resolution). 😉 Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature