Bug#789339: perl: File conflict with libio-compress-perl (/usr/bin/zipdetails)

Niko Tyni ntyni at debian.org
Tue Jun 30 17:23:17 UTC 2015


clone 789339 -1
retitle -1 libio-compress-perl: needs to divert away the core version of /usr/bin/zipdetails
reassign -1 libio-compress-perl 2.068-1
severity -1 important
thanks

On Fri, Jun 19, 2015 at 11:57:00PM +0100, Dominic Hargreaves wrote:
> Package: perl
> Version: 5.22.0~rc2-2
> Severity: grave
> User: debian-perl at lists.debian.org
> Usertags: perl-5.22-transition
> Justification: breaks installation of libio-compress-perl
> 
> With perl 5.22 (in particular commit 0c03dbe[1], the Replaces
> libio-compress-perl has moved from perl to libperl5.22; however 
> libio-compress-perl and perl both include /usr/bin/zipdetails, so
> this Replaces had the effect of causing both to be coinstallable.
> That's now lost and we have:
> 
> Unpacking libio-compress-perl (2.068-1) ...
> dpkg: error processing archive /var/cache/apt/archives/libio-compress-perl_2.068-1_all.deb (--unpack):
>  trying to overwrite '/usr/bin/zipdetails', which is also in package perl 5.22.0~rc2-2

Urgh. Good that this uncovered the other bug though.

> Note: I think these unversioned Replaces should be reviewed even in
> perl 5.20: in jessie, this causes the newer /usr/bin/zipdetails
> from libio-compress-perl to be masked by the older one from perl which
> is certainly not intended.

Fortunately the full diff between the core version and the dual life
version is minimal in both jessie and sid, so this hasn't really broken
anything. I don't think we need to do anything for jessie at this point.

--- /usr/bin/zipdetails 2015-05-16 14:48:28.000000000 +0300
+++ dual-life/usr/bin/zipdetails    2015-05-06 22:59:42.000000000 +0300
@@ -1,7 +1,7 @@
 #!/usr/bin/perl
-    eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
-   if $running_under_some_shell;
-#!/usr/bin/perl
+
+eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
+    if 0; # not running under some shell
 
 # zipdetails
 #

> The problem here is that Replaces has too
> meanings, and it was having the effect described in policy 7.6.1 when
> it was probably meant to have the effect of policy 7.6.2. Possibly
> all scripts supplied with dual-lived modules should have alternatives
> in place instead, as we have done with other packages.

With s/alternatives/diversions/, they absolutely should. I'm cloning a
severity:important bug against libio-compress-perl.  Are you aware of
other similar cases?

For the record, the Replaces declarations on the dual life module packages
are indeed meant in the policy 7.6.2 sense: when perl is upgraded,
older versions of the dual life module packages should be removed from
the system altogether.

I'm very much not clear on whether it matters if the Breaks or Replaces
declarations is versioned, and/or if Conflicts and Breaks are handled
differently here. Experiments are probably needed. Perhaps it's as
simple as

 Breaks:   libdual-life-perl (<< core_version)
 Replaces: libdual-life-perl (<< core_version)

The current behaviour, where perl is allowed to have file conflicts with
the dual life module packages, certainly isn't intended.  It would be
far nicer to have a dual life module package rendered uninstallable
with a file conflict error if it's missing the diversions.

I'm not sure there's anything wrong on the perl-5.22 side specific
to libio-compress-perl; once that package is fixed, we might want to
reuse this bug for this general Replaces issue (and probably lower
the severity.)
-- 
Niko Tyni   ntyni at debian.org



More information about the pkg-perl-maintainers mailing list