What to do about hamm/bo overlaps

[dark@xs4all.nl (Richard Braakman)]

I made a scan of overlaps between packages in bo and packages in hamm,
and I now have a list of those that will (in my estimation) cause
problems when upgrading a system from bo to hamm.

The problem is that I don't know what to do with this list.  It's just
a lot of raw data (39 items), together with some of my notes about
relationships between the packages, and I don't have enough experience
with the dependency system to distill that into a set of
recommendations for handling each overlap.

So I'm asking for help.  I pulled out some examples that are each
representative for a class of overlaps, and I wrote down the what
I would recommend for each of them.  Please tell me if I'm wrong.

Overlap hamm/sysvbanner_1.0-4 and bo/bsdmainutils_3.2-0:
   usr/bin/banner
The bsdmainutils in hamm (>= 3.3) installs banner as /usr/games/banner
to avoid this overlap.

My recommendation: add Conflicts: bsdmainutils (<<3.3) to sysvbanner.

Overlap hamm/figlet_2.2-1 and bo/figfonts_2.1.1-2:
   usr/lib/figlet/banner.flf
This file was moved from figfonts to figlet with the 2.2 release (of both).

My recommendation: add Replaces: figfonts (<<2.2) to figlet.

Overlap hamm/svgalibg1_1:1.2.11-1 and bo/svgalib-dummy1_1.2.10:
   usr/lib/libvga.so.1
   usr/lib/libvgagl.so.1
svgalibg1 conflicts with svgalib1 (<< 1:1.2.11-1)
svgalib-dummy1 provides svgalib1
But the versioned conflict does not work for a virtual package.

My recommendation: Add a conflict with svgalib-dummy1 (<<1.2.11-1)
to svgalibg1.

Overlap hamm/mgetty-voice_1.1.7-4 and bo/mgetty_1.1.2-1:
   usr/man/man1/pvf.1.gz
   usr/man/man1/zplay.1.gz
mgetty-voice depends on mgetty.  Presumably these files were moved
from mgetty to mgetty-voice at some point.

My recommendation: Add Replaces: mgetty (<< 1.1.7-1) to mgetty-voice.
Using a versioned dependency is tempting, but I don't think it will
work, because packages are unpacked before dependencies are checked.

Note that in two cases I recommend a versioned Conflicts entry.
This is discouraged by current policy:  (section 8.3, packaging manual)

   A Conflicts entry should almost never have an `earlier than' version
   clause. This would prevent dpkg from upgrading or installing the
   package which declared such a conflict until the upgrade or removal of
   the conflicted-with package had been completed. This aspect of
   installation ordering is not handled by dselect, so that the use
   Conflicts in this way is likely to cause problems for `bulk run'
   upgrades and installations.

Should there be an exception to this policy for the sake of handling
overlaps like the ones above?  If --force-overwrites is not active
by default, the problems caused by versioned conflicts will be less
than the problems caused by such overlaps.

Richard Braakman


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .