[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libpng planned changes for etch



Hi Josselin,

On Wed, Apr 06, 2005 at 02:13:43PM +0200, Josselin Mouette wrote:
> Here is a summary of the important changes I'm planning for libpng in
> etch.

> * Removal of the entire libpng source package: libpng2, libpng2-dev,
> libpng10-0, libpng10-dev. All applications currently linking to libpng
> 1.0 will have to be rebuilt against libpng 1.2. As sarge's libpng
> packages include symbol versioning, it can be done smoothly. Some
> packages will temporarily depend indirectly on both versions, but they
> shouldn't be broken.

Sounds good.

> * Removal of the libpng3 binary package, as only 2 packages in sarge
> still depend on this one. Maybe we can keep it, though, as some
> third-party binaries could require libpng.so.3.

Are there third-party binaries known to depend on it?  I didn't think the
libpng.so.3 soname made it very far before being replaced.  At the very
least, it ought to move to oldlibs at that point, I think.

> * Removal of the libpng3-dev binary package, adding a Provides: in
> libpng12-dev. I believe autobuilders can cope with such a change, as
> they are already dealing with packages build-depending on libpng-dev,
> which is a virtual package.

Should do, though it's also reasonable to file bugs against such packages
asking them to switch to libpng12-dev.  There are some packages with a
versioned build-dependency on libpng3-dev, so they would FTBFS once this
change was made if they were not fixed beforehand; it's probably reasonable
to file (wishlist) bugs against those packages pre-sarge.

> * Removal of the private symbols that are exported in the library. This
> can break some applications directly using these private symbols. Which
> means: it shouldn't happen, but you never know how software authors can
> have stupid ideas.

Given that there's the potential for breakage, why would you go to the pain
of removing the symbols once they've been exported in a stable release?
Once published, the damage is done; I don't see any sense in removing them
until something else is known to break the (private) ABI.  Have you talked
to upstream about this?

Cheers,
-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: