Hi Steve, On Fri, Apr 18, 2003 at 08:43:45PM -0400, Steve M. Robbins wrote:
> I no longer believe that upstream will release any new versions of > imlib and I plan to ask that imlib2 be removed from the archive. I > don't want to change the current imlib1 linkage since imlib is pretty > much dormant and probably on its way out. > There are six packages currently linked against imlib2: > chinput > fnlib > kdegraphics > mgp > picturebook > wallp > I'm not sure whether they strictly require png3 or whether they could > simply be rebuilt with imlib1 and libpng2. In the past, however, some > KDE folks have explicitly requested imlib+png3. FWIW, fnlib does not require libpng itself; it is, however, linked against libpng3 thanks to the usual libtool idiocy. > What would be the best way to accomodate such a request? I can > imagine introducing a new package of imlib linked with libpng3. But > since it has to use the same SOVERSION as the current imlib1, it would > have to conflict with imlib1. Each individual admin could then choose > to use imlib+png2 or to use imlib+png3. However, each choice would > have its own set of incompatible programs so this option doesn't > appeal to me. If upstream is dormant (and I know that's an understatement), you could also try to coordinate with other vendors who might still ship imlib and agree to pick a new soname anyway. That seems a better choice than creating a new package that conflicts with imlib1, IMHO. > Another option is to drop the idea of imlib+png3. The six packages > mentioned above would then have to build either with png2 or somehow > incorporate imlib into their source build. For the maintainers of the > six packages: is that feasible? No problems here, at least. Cheers, -- Steve Langasek postmodern programmer
pgpSZsPvEs6QY.pgp
Description: PGP signature
