Hello Sebastian, lets clarify the facts: Xz-utils ships the localized manpages since 5.2.7. I do not see any backport yet, I assume it will be 5.4.1-0.0~bpo11+1
manpages-l10n shipped the localized manpages before 4.1.0-1. This is
odler than stable. It also shipped them in every backport until
4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1.
But I wonder if I should remove them there. Please tell me, which
languages you (intend to) ship in the backport.
On Tue, Jan 31, 2023 at 09:50:20AM +0000, Thorsten Glaser wrote:
> 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:
Let's try:
> stable → next-stable
No problem, manpages-l10n never shipped it in stable and next-stable.
> stable → stable+backports
I assume if I *remove* the xz manpages for 4.17.0-2~bpo11+1, then
users upgrading manpages-l10n and/or xz-utils get the translations
from xz-utils (no longer from manpages-l10n). I keep the conflict, in
case they take xz-utils with manpages-l10n 4.16.0-3~bpo11+1 installed.
> stable+backports → next-stable
The conflict in manpages-l10n backports ensures that it is not
co-installed with xz-utils in next-stable.
> stable+backports → stable+backports+backports-sloppy
I don't know "stable+backports+backports-sloppy" and I never uploaded
to -sloppy.
> stable+backports+backports-sloppy → next-stable+backports
Dito.
> stable → testing (at any point)
No problem, manpages-l10n never shipped the localizied man-pages in
stable.
> stable → unstable (at any point)
The same.
> testing → testing (at any point)
The same.
> testing → unstable (at any point)
The same.
> unstable → unstable (at any point)
The same.
> testing (at any point) → next-stable
The same.
> stable+backports → testing (at any point)
The conflict in the upcoming manpages-l10n 4.17.0-2~bpo11+1 should
ensure this.
> stable+backports → unstable (at any point)
The same.
> 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).
I think these are covered in your considerations above.
> 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.
I don't see any depends involved here, Replaces/Breaks and conflicts
should suffice.
There should not be any problems with build-depends.
> 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…
This is what we try to tame here, yes. And I hope we did it right.
> 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).
Translations need to mirror the english content. If that evolves in
backports, then so do need the translations.
> 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).
Yes, this is the first time a translation moved packages *and* there
was a backport of said package (here: xz-utils).
> Good luck,
Thanks
Greetings
--
Dr. Helge Kreutzmann deb...@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
signature.asc
Description: PGP signature
