Bug#531556: upgrade problem with the proposed libarchive-tar-perl Etch update

[Niko Tyni]

On Tue, Jun 02, 2009 at 04:05:51PM +0200, Toni Mueller wrote:
> On Tue, 02.06.2009 at 15:36:31 +0300, Niko Tyni <ntyni at debian.org> wrote:

> methinks that the by far easiest and cleanest solution would be to
> update the perl or perl-modules package in Lenny.

That would leave a broken upgrade path from the (future) Etch r9 release
to the (base and current) Lenny 5.0.0 and 5.0.1 releases. I don't think
that's acceptable, particularly for 5.0.0.

> > FWIW, I'd prefer having this fixed inside the libarchive-tar-perl etch
> > update, but I can certainly prepare a lenny update for the perl package
> > if that turns out to be necessary.
> 
> Since Archive::Tar is afaik already contained in Perl 5.10 via
> upstream, there is imho no place for a libarchive-tar-perl package in
> Lenny in the first place. Therefore, I don't understand why the
> "Replace" clause has a version number. Just removing the version number
> and conflicting with all libarchive-tar-perl packages therefore seems
> to be the correct solution to me.

Minor point: the version number is in the "Conflicts" field, not
"Replaces".

The Perl policy and packages go to some trouble to ensure that the
modules bundled with the core can be overridden by separately packaged
newer versions. The conflicts are primarily there to ensure that
separately packaged older versions get removed.

See for instance the libpod-simple-perl and libmodule-corelist-perl
packages, which are both in Lenny despite being contained in the core.

Normally, we'd just conflict with libarchive-tar-perl (<< 1.38) or 
(<< 1.38-1): even if overriding the core 1.38 version with a separate 1.38
package is pointless, there's no harm done. 

In particular, if somebody wants to package a newer version, like the
current 1.48, they should be allowed to.

The special thing in this case is /usr/bin/ptar and /usr/bin/ptardiff,
which cause file level conflicts. The Lenny perl package has
made allowances for those by replacing all the earlier versions of
libarchive-tar-perl - they couldn't have known about the file conflict
ahead of time.

However, the perl package couldn't predict the future either, so it only
conflicts with (<= 1.38-2), with the expectation that later versions
will use diversions to handle the file conflicts.

In hindsight, the choice for the Etch update version (leaping from 1.30-2
to 1.38-3~etch1) was unfortunate, and if it's still possible to revert
it, that would be the easy way out. Given it's already in pool/ on the
FTP servers, I doubt that.

So the only real fix I can see is adding the diversions with 1.38-3~etch2.

We can still put out a Lenny perl update to upgrade the Conflicts field,
but that's neither sufficient nor necessary. The sid perl version contains
additional fixes, and I will update the Conflicts there in any case.

Oldstable release managers: will you accept a libarchive-tar-perl
1.38-3~etch2 upload with the diversions added, or can you suggest
another fix?  What's the schedule for the Etch r9 release?
-- 
Niko Tyni   ntyni at debian.org