Sebastian Andrzej Siewior dixit:

>It is bpo but if you look I'd you look at the files for the same
>version in bpo and sid you will see that sid skipped a few man pages
>while bpo created them.

Ouch!

That adds to the problems, of course. That makes fully resolving
this in all possible combinations a nightmare.

In general, these have to go:

stable → next-stable
stable → stable+backports
stable+backports → next-stable
stable+backports → stable+backports+backports-sloppy
stable+backports+backports-sloppy → next-stable+backports
stable → testing (at any point)
stable → unstable (at any point)
testing → testing (at any point)
testing → unstable (at any point)
unstable → unstable (at any point)
testing (at any point) → next-stable
stable+backports → testing (at any point)
stable+backports → unstable (at any point)

In addition, partial upgrades that do not span more than a release
either way need to work (so you could have, say, manpages-fr from
buster and xz-utils from sid(before the bookworm release), or vice
versa, on one single bullseye system).

Explicit Depends are needed to make all these either work or the
package manager not consider them (which forces upgrading a part
of the system to match). In addition, Build-Depends need versioning
unless present in stable, better oldstable, because buildds are not
required to upgrade (only update) before a run, plus packages can be
lagging on some architectures.

Now backports take from testing at the point of backporting.
If the backported packages significantly differ from the
package in testing, however, combinatory explosion, as the
above holds true for every single package…

In particular, I’ve personally held back from backporting
packages when I know I had versioned constraints on the
package in question but backporting would require bringing
the old behaviour back (i.e. the backported package needs
to behave like the new one, not the old one, and if that’s
not possible in the old distro, then don’t package it).

I see why this would be a problem for manpages… but you
cannot re-enable manpages in bpo that aren’t in testing
meaningfully when there’s also a backport of the package
from testing that includes the manpage (and you cannot
meaningfully drop the manpage from the backport because
then the package relationships aren’t possible any more).

Good luck,
//mirabilos
-- 
<ch> you introduced a merge commit        │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo      │  fault (core dumped)
<ch> if I rebase that now, it's really ugh     │<mika:#grml> wuahhhhhh

Reply via email to