[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports



Hello Axel,
hello Craig,
On Mon, Jun 14, 2021 at 12:19:17PM +0200, Axel Beckert wrote:
> Craig Small wrote:
> > reassign -1 manpages-de
> 
> Might be the right place indeed, but maybe not in the way you'd
> expect. See below.

Ack. And thank you very much for your analysis and suggestions.

> > > 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. :-/

I see. But if we decide on the final version for unstable and
backports, this should work, shouldn't it?

> 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 always remember that your system has to be up-to-date before the
dist-upgrade and extra care was necessary for users of backports.
Hence I would think this is reasonable.

>    * 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.

If (and relly if) this works, then from a maintainers POV this would
be the nicest solution. 

> 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. 

But this would partially defeat the purpose of the backport, to
provide localized man pages where upstream did not.

So from a maintainer POV I would prefer either solution 1) or 2). And
as this situation will come up again and again in the future (with
other packages of course, manplages-l10n has > 100 upstreams) I think
it is worth investigation into a proper solution.

So, in conclusion, I'd prefer 2) for the long run (if possible), 1)
for now (with agreed upon versions) and 3) only as emergency fall back
if 2) or 1) really do not work at all.

I currently imported the latest version of manpages-l10n in sid, namely 4.10.
I intend to ask the RMs to accept this in testing and then provide a
backport again. This one could contain the "right" solution we decide
upon.

> Footnotes:
> 
> (*) buster-backports neither seems to have psmisc nor procps which
>     surely makes this issue less complicated than it could be. :-)

I wonder if and who manages file conflicts amongst backported
packages?

Greetings

              Helge

-- 
      Dr. Helge Kreutzmann                     debian@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/

Attachment: signature.asc
Description: PGP signature


Reply to: