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-p...@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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org