Re: libpng planned changes for etch
Le mercredi 06 avril 2005 à 11:44 -0700, Steve Langasek a écrit :
> > * 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.
Oldlibs would be fine. It's just a symlink, but other distributions
don't do it this way: libpng12.so is a link to libpng12.so.0 but
libpng.so is a link to libpng.so.3, which still has the libpng.so.3
soname. (Yes, this duplicates the binaries actually installed.) Unless
applications are built with -lpng12, they'll still use libpng.so.3.
> > * 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.
That makes currently 47 packages in sarge/main, I think this can be
called mass bug-filing.
> > * 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?
The (optional) feature to remove those symbols is provided by upstream.
The problem is that the private symbol list keeps growing, even in
bugfix releases. In this situation, you may end up with binaries using
the same function names, for various reasons. I have already encountered
similar cases in other libraries, that's why I believe it would be a
good thing.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
Reply to: