Re: FWD: C++ library packaging
On Sun, Jun 30, 2002 at 07:24:44AM +0200, Matthias Klose wrote:
> > I've been out of the loop for some time. Has there been any
> > discussion of this?
> Jeff Bailey <jbailey@nisa.net> did some preparations for such an
> upgrade. Basically if Debian should change the sonames of the
> libstdc++ dependent packages or should do the transition in place.
The proposal that I've been putting together has essentially been for
a massive binnmu. I imagine that we'd just redo it for 3.2 or
something.
There are essentially three areas of concern:
1) Trying to avoid breaking people's current Debian systems.
2) Trying to avoid breaking 3rd party (whether Free of Non-Free)
software linked in.
3) Allowing for a smooth upgrade when Woody+1 comes around.
My thoughts so far are:
1) This can be handled with careful use of awk, apt-cache and friends.
There appear to be 900-1000 packages that we'd be affecting (Based on
cat http.us.debian.org_debian_dists_unstable_main_binary-i386_Packages
|grep libstdc++ |wc )
The idea is to generate dependancy trees and upload them at once. At
the same time as the first batch is uploaded, gcc-defaults gets
bumped.
(This is, BTW, yet another reason why I think we should *require*
source uploads for all archs. There will be problems here where
people upload packages without upgrading first!)
I haven't generated the trees yet, but I'm hoping they're small enough
that we can do every arch at once at not annoy the ftp masters.
2) To some degree this is inevitable. Because no matter how we handle
this, the sonames are not likely to change. I'm not sure of a good
way to control this.
3) I'd like to see us put the old (but still supported) libstdc++'s
into a "compatability package" under some funny name in oldlibs. Then
the libstdc++ that comes out with Woody can simply conflict with all
the older ones. This is important because unless we start mangling
sonames, having a mix on the systems are just timebombs.
Of course, if we follow our usual release schedule, we may simply
choose not to support older versions. 2.95.x should be old and dead
history by then. 3.0.x should quietly rot away by then too. So we'd
be talking about maybe a backwards compatability case for 3.1 - Which
I think we shouldn't do, because we're unlikely to ever see a Debian
release with this as the standard compiler. The same applies for
whatever other versions we go through before we release again.
Tks,
Jeff Bailey
--
I reincarnated for this?
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: