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

Re: G++ 2 => 3 transition (was Re: GNU C++ 3.0 porting help wanted)

On Mon, 2001-10-15 at 10:06, Richard Kettlewell wrote:
> Sean Middleditch writes:
> > Richard Kettlewell wrote:
> >> Upstream should have changed the version number to reflect the ABI
> >> change anyway, shouldn't they?
> > 
> > Not if upstream doesn't release a new version and Debian tries to
> > convert the whole system.
> I think that's a response to "upstream will have..." rather than
> "upstream should have...".  Do you believe they *shouldn't* change
> shared library version number when the ABI changes?

No, I don't believe that, and I don't think I said that I did.

> If upstream are shipping code that will produce shared libraries then
> surely that is the first place to go to decide what the new shared
> library version should be.  Each individual Linux distribution
> inventing its own new numbers will just lead to incompatibility.

Which is exactly my point.  ^,^

> > Not to mention upstream can be pretty dumb sometimes... ~,^
> Better to give them the chance to do the right thing, rather than
> assuming they're going to be stupid from the start, I would have
> thought.

Yes, understood.  I was arguing that the change of library version
numbers as a solution to the library incompatible is *not* a good idea. 
We need to recompile the libraries, whether upstream changes the version
number or not.  Debian libs version number must match.  We should make
use of the power of apt and dpkg to get the transition to work smoothly,
not hack on the libraries themselves.  ^,^

I still think the best solution is simply to disallow the
addition/updates of C++ libs (or any libs, whatever is affected by ABI
change) to unstable (after Woody freeze/release) unless they are
compiled against gcc 3.0.  Then any apps that need the libs either will
not be updated until ported/compiled, or will depend on older versions
of the libs that will disappear eventually.  There will be a few big
bottlenecks, but there is no solution that will get around that.  I'm
sure there were similar problems (like big libc version changes) that
the Debian project either had to plow through as best it could, or stall
and never use the new technology.

> ttfn/rjk
> -- 
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: