Re: [PROPOSAL] Archive audit, cruft removal, unmaintained packages
On Wed, 18 Aug 1999, Richard Braakman wrote:
> The main problem with such cruft is often, what are we supposed to do
> about it? We even have a bugreport asking *not* to remove libstdc++2.8.
Which bug report is that? I checked the bug reports on this package and I
couldn't find it.
> And there's the libjpeg situation... it is entirely unclear which of
> the libjpeg packages are supposed to exist, and the maintainer doesn't
> reply to my mail.
The libjpeg case shouldn't be too much of a problem. On my potato system,
I have libjpegg6a and libjpeg62. The first entry in libjpeg62's changelog
is on the same day as the last entry in libjpegg6a's changelog. Need I say
more?
The problem is, of course, that there are still programs depending on
libjpegg6a:
fsviewer
gzilla
hfsutils-tcltk
imaptool
knews
libmagick4g-lzw
libtiff3
mosaic (which, BTW has a capital M in the package name!)
xacc
xloadimage
xpaint
yagirc
Do these programs really need to have libjpegg6a or can they (perhaps
easily) be converted to use libjpeg62 instead?
A message should probably also be sent to the maintainers of the qcam and
zgv packages, which still depend on libjpeg6b, which is not available in
potato. libjpeg62 replaces, provides and conflicts with libjpeg6b.
Remco
--
rd1936: 10:20pm up 62 days, 13:16, 6 users, load average: 1.09, 1.24, 1.18
Reply to: