On Tue, Oct 18, 2022 at 07:53:38PM -0400, Stefan Seefeld wrote: > > On 2022-10-18 03:42, Johannes Schauer Marin Rodrigues wrote: > > Quoting Stefan Seefeld (2022-10-18 00:19:53) > > > Allow me to come back to this question: What determines what is > > > considered a "candidate", and what constraints exist around the concept > > > ? Why do I get an installation error when trying to install a package > > > that depends on an older (as in: not latest) version of a prerequisite > > > package ? > > Of each package, the candidate version is picked using the pin priority and its > > version. Higher pin and higher version wins. Apt will not consider > > non-candidate versions for its solution. If you want this feature, use a > > different solver backend (like aspcud) or a different frontend (like aptitude). > > This is very useful to know indeed; thanks for confirming that ! Are these > limitations (apt-get only considering latest versions as candidates, say) > documented anywhere ? I'm puzzled why it took me so long to learn this ! It is a matter of interpretation if this is a limitation or in fact something you can't even call a feature as it is to be expected this way and behaving any different would be a bug… Let me reframe this: You want the (potentially obsolete) package X to decide if package Y is to be pulled from stable/backports/experimental and/or if Y stays forever on a version without the latest security fixes just because X has a Depends: Y (= 1~unfixed) ? Of course you don't, but given in Debian it (nearly) never happens that the same release carries two or more versions of the same package (with arch:all packages it can happen if your system is multi-arch. Its somewhat close, but a rather temporary situation) apt doesn't have code to single out your specific semi-sensible use case from all the nightmare scenarios which in a Debian context are far more likely. If your goal is to keep multiple series¹ maintained it is best to have each series in its own release (or at least component) or have the series be part of the package name. If that isn't your goal, you should work on getting updates for the entire set shipped more quickly or e.g. go with a staging area. We /might/ add at some point code so libapt could go with 1.0.x or 1.0.y if they are both from the very same (group of) Packages files, but I wouldn't hold my breath. I am idly thinking about this for years now but haven't once even started my editor with the intend of writing it. ¹ TIL that the plural of series is a null derivation of singular series and not the mouthful serieses which I would have guessed… > And more generally: is there any documentation that gives an overview of the > APT architecture, in particular focusing on the rules that may be imposed on > dependency resolution at different levels (frontend, backend, ...) ? (beware: What follows is personal opinion on UI concerns and user expectations. Ask 2 people and you probably get 3 conflicting opinions) Version selection and such is described in apt_preferences(5). Solvers can do anything, but it is a matter of the front end to show the solution the solver came up with to the user in a way that is not confusing. As such, apts default solver (and if it is asked to talk to external solvers, strict-pinning is the default) does what the manpage says. aptitude has a little more free reign… being an interactive UI and all helps at the expense of "forcing" the user to look out for this sort of thing happening. External solvers… well, if your machine is a buildd it might be a good idea to pull stuff at semi-random from experimental if that is required to build something for experimental – but those machines exist only for the duration of the build. Nobody has to worry about them being updated/supported tomorrow, so user expectations are entirely different in this context. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature