>> Franklin Belew <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
