Re: [timshel@pobox.com: X4 phase 2 packages issue ...]

["Marcelo E. Magallon" <mmagallo@debian.org>]

>> Franklin Belew <frb@balance.wiw.org> writes:

 > xpm4g is so old and out of date that it shouldn't be poerpetuated

 I really fail to understand your fixation on this (non-)issue.

 Josip had expressed his intention to rename xpm4g to libxpm and more
 specifically, he had expressed his intention to do it smoothly:

 | xpm (3.4k-2) unstable; urgency=low
 |
 |   * Following Joel Klecker's example (from zlib1g), for smoother
 |     transition to new names (which I will use after potato), I made
 |     xpm4g{,-dev} provide libxpm4{,-dev}, put that name in the shlibs
 |     file, and removed the version.
 |
 |  -- Josip Rodin <jrodin@jagor.srce.hr>  Tue, 14 Sep 1999 20:09:37 +0200

 xpm's API is not being changed by xfree86:

 [48 ysabell:~/tmp/xpm-3.4k] cmp /disk/hda10/marcelo/cvs/xfree86/extras/Xpm/lib/xpm.h lib/xpm.h && echo files are identical
 files are identical

 xpm itself is a cold turkey:

 3.4k    (98/03/18)
 3.4j    (96/12/31)

 xpm4g in potato is the same as xpm4g in woody (3.4k), and the version
 in slink is indeed 3.4j.

 And above all that, our packaging system does not support package
 renaming in way that allows for trouble-free upgrades.  The only way
 to ensure that is having some package depend on the new name and the
 the package with the new name to provide the old name.  The gotcha
 here is that xpm4g's shlibs contained (with a good reason) a
 versioned dependency, and dpkg currently does not support versioned
 Provides.  The CVS version does.

 4.0whatever >= 3.4j

 So, besides the general uglyness of the name xpm4g, is there any
 technical reason at all to rename the package *now*?

 In short: if you are asking for trouble doing something the package
 system doesn't fully support, then you have to expect trouble and
 deal with it.

 > If these packages don't update to use libxpm4 as the xpm in potato
 > and woody provide, and that XF4 provides, they deserve to be
 > uninstallible because the maintainers are either awol, or just
 > plain ignoring bug reports

 Granted.  Iff there's a technical reason behind it all.


                                   Marcelo