Hi Craig and Helge,
Craig Small wrote:
> reassign -1 manpages-de
Might be the right place indeed, but maybe not in the way you'd
expect. See below.
> > JFTR: What came to me after sending that mail and what I didn't check
> > so far, is if 4.9.3-4 is fine, but 4.9.3-4~bpo10+1 has those files.
> >
> > Actually in that case, I have no idea how the Breaks/Replaces headers
> > and the maintainer scripts need to look like.
>
> $ debdiff manpages-de_4.9.3-4_all.deb manpages-de_4.9.3-4_bpo10+1_all.deb |
> head
> [The following lists of changes regard files as different if they have
> different names, permissions or owners.]
>
> Files in second .deb but not in first
> -------------------------------------
> -rw-r--r-- root/root /usr/share/man/de/man1/fuser.1.gz
> -rw-r--r-- root/root /usr/share/man/de/man1/killall.1.gz
> -rw-r--r-- root/root /usr/share/man/de/man1/lzmainfo.1.gz
> -rw-r--r-- root/root /usr/share/man/de/man1/peekfd.1.gz
> -rw-r--r-- root/root /usr/share/man/de/man1/prtstat.1.gz
>
> There's about 20 "new" files and 20 removed files.
>
> For some reason, the backport version included files that clash with the
> procps and psmisc packages. The sid version on 4.9.3-4 doesn't have those
> conflicting files.
This actually makes sense, because the backports version is targetted
for buster with psmisc/procps package versions which don't/still have
them. So the exclude/include list the buster-backports package is more
similar to the buster package than the bullseye package — just the
contents of the manpages is as up to date as the bullseye package.
>From that point of view, this is _not_ a bug in the manpages-de
package in buster-backports. (But it still might be the best option to
fix it in there.)
Then again, dist-upgrades from buster with to bullseye should work
smoothly like without backports and it seems to be that the main
burden to make this sure lays in the backports-packages.
I though still think that this is a serious (sic!) issue and it should
be fixed.
Here's my analysis of the potential solutions I see:
1) If that Breaks/Replaces headers in psmisc (and probably procps)
would be bumped to "<< 4.9.3-4" it would also match the manpages-de
backports package, but then again, this would also match other
non-backports manpages-de package versions inbetween which don't
have these files. And I fear this would have any unwanted (and
potentially also RC-level) side effects. :-/
2) So I wonder if the buster-backports package of manpages-de could
conflict with the psmisc and procps package in bullseye(*)? This
should probably take care that it is upgraded before procps and
psmisc are upgraded and hopefully solves the issue without too many
side-effects.
(I'm not sure if Breaks/Replaces with ">>" or ">=" really work as
expected. I've never seen that in use anywhere before. Taking
Guillem into Cc so maybe he can tell something about if Conflicts
or Breaks/Replaces are the better choice here.)
I only see these hopefully only minor disadvantages of that latter
solution:
* Users need to have uptodate buster-backports package, i.e.
4.9.3-4~bpo10+2. If they don't upgrade to 4.9.3-4~bpo10+2 before
dist-upgrading and then upgrade with 4.9.3-4~bpo10+1 still being
installed, they will run into this issue again. Might be
something for the Release Notes.
* I'm not sure if apt gets confused while trying to find a good
order for dist-upgrading if the Conflicts/Breaks/Replaces is in
the old package and not the to-be-upgraded-to one. I hopefully
think that this is no issue, but I'm Cc'ing the APT team for
input on that to be on the safe side.
3) Only ship manpages in manpages-de in buster-backports which are in
psmisc/procps neither in buster nor in bullseye. I assume this is
the solution, Craig had in mind when reassigning the bug report.
IMHO this is also a viable solution if variant 2) has too many side
effects as it IMHO only has a minor impact on the usability of the
manpages-de package in buster-backports.
Footnotes:
(*) buster-backports neither seems to have psmisc nor procps which
surely makes this issue less complicated than it could be. :-)
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
