On Thu, Apr 07, 2005 at 01:24:48PM +0200, Josselin Mouette wrote: > 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. Ah, lovely. Ok. > > > * 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. Well, I was only suggesting filing bugs against the ones with a versioned build-dependency, which are much less numerous. Mass bug-filings aren't inherently evil, though, they're just something that should be discussed first to see if there's a better way. > > > * 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. Ah, good point. In that case, it probably makes sense to prune them at the first available opportunity, since the bigger risk here is namespace conflicts, not people referencing them when they shouldn't. Cheers, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature