On Mon, Jan 01, 2024 at 09:13:54AM +0000, Askar Safin wrote: > This bug (#229775) is still reproducible with current apt version (apt > 2.7.7). The bug
That is good, because it is documented to behave this way… > can be summarized so: "apt-get build-dep" fails to install a package from a > repo > if its priority is slightly less than priority of installed release. In more > details: > "apt-get build-dep" fails to install a package from backports if backports > priority > is set to 499 and installed release have its default priority (i. e. 500, as > well > as I understand). See apt_preferences(5) for the gory details, but in short: The version equal or higher than the current installed (if any) with the highest pin is the candidate – which is the one pinned to 500 as 499 is clearly lower than 500, end of the story. > I think this is a bug: dependecies can be satisfied if one really tries. > If I set backports priority to 500, then "apt-get build-dep" is able > to install needed packages. So, apt-get doesn't try hard enough. Sure, but in its default configuration apt is not supposed to try hard. > Go to Debian IRC (a. k. a. OFTC IRC), join #debian channel and write to > bot nicknamed "dpkg" the following text: "simple sid backport". The bot > will respond to you with the following *very* helpful text: Sometimes, "simple" is not enough. Sometimes backports are hard, but the bot can't help with that and that is for the better as hard equals dangerous in this case. You wouldn't complain about a bot telling you hat hiking up a mountain is easy, while that certainly doesn't apply to the 8k's. > I use stretch as my main system. So I often need to backport packages. And I Support for stretch ended nearly a decade ago, LTS extended that slight to 2016, but that is still a long time ago. Hoping that current documentation would apply to a system that old is a bit of a … stretch. > Hence there is simply no configuration, which meets my goals. Not that it helps in what you asked first, but the current default for backports is 100 – but I implemented the involved feature set after squeeze if I remember right… you can manually set it to 100 through for a "upgrade from backports if a backports version was installed previously" behaviour (as in that case the highest pin will be 100). > === > if ! apt-get build-dep -y "$PKG"; then > apt-get build-dep -t "$CODENAME"-backports -y "$PKG" > fi > === > > Well, I can write this. But this is a hack. Workaround for a bug! Well, I guess I would just go with -t always, but your choice really. Note that the "real" backports builder use an alternative apt configuration that frees it from its candidate shackles at the expense of other problems as choice, it turns out, is not always desired. The keywords are external solvers, aspcud and what not, but that isn't supported in squeeze either, I made that happen later… I think back in the day backports were using aptitude as builder as its solver is allowed by default to change candidates mid-flight. sbuild documentation is a good choice here as its part of the build infra. So, in summary, yes, apt doesn't switch candidates while running currently. Not even if they have the same pin value – where it might even make sense – and certainly not if they have different values. You may call that a bug, I call that a documented feature, and for the rest of the world lets call this report a wishlist item for a feature that might or might not be implemented in a future default solver (probably by writing said solver first). What I know is that we can't offer any assistance with your quest of backporting to the last decade. This is COMPLETELY unsupported. Best regards David Kalnischkies
signature.asc
Description: PGP signature
