Re: C++ transition stumbling blocks?
Robert Woodcock <firstname.lastname@example.org> writes:
> On Tue, Jan 21, 2003 at 08:24:11PM +0100, Andreas Rottmann wrote:
> > Yes, I already figured they are not the nicest guys wrt sonames &
> > stuff. However, don't you think this is a more reasonable solution:
> > * id3lib source
> > - libid3-3.7-WHATEVER binary
> > * id3lib3.8 source (note the missing 0)
> > - libid3-3.8-WHATEVER binary
> Absolutely not.
This is not an argument.
> > I still think you should dump the id3lib3.8.0 source in favor of a
> > id3lib3.8 one - it simply makes no sense to have a new *source*
> > package name for each *micro* version.
> You still don't get it - please do not NMU id3lib. You *will* break it.
I said I'll NMU when I don't hear from you, not that I will NMU in any
case. It would be really be quite a evil thing to do an NMU against
explicit arguing by the maintainer...
> There's nothing quite like merging patches when you're feeling faint
> but you've certainly given me the motivation to try.
> Upon source package upgrade, dinstall removes the old binary package.
> Otherwise you'd have packages in the archive that have no corresponding
Yes, but if users have installed the library, it will persist. And
packages depending on the library should be rebuilt. It doesn't matter
that ABI has changed, as long as API hasn't. Do you really want to say
that id3lib breaks *API* with every micro version?
Just consider other C++ library packages, such as libsigc++: It has a
1.2 encoded into the library name and source package (not 1.2.x). In
the course of the 1.2.x releases, they broke ABI and API (even in a
quite severe way, once), but there were no 1.2.x source packages due
to this. They only changed soname (and tus binary pkg name) of the
shared library. I think id3lib is quite similar...
Andreas Rottmann | Dru@ICQ | 118634484@ICQ | email@example.com
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62