Proposal(s) for handling libqt3-mt situation

[Steve Langasek]

On Sat, Feb 16, 2008 at 10:17:33AM +0100, Pierre Habouzit wrote:
> > 	digikam
> > 	k3b
> > 	kcontrol
> > 	kdirstat
> > 	kexi
> > 	konq-plugins
> > 	konqueror
> > 	ktorrent
> > 	libk3b3
> > 	libmyth-0.20.2
> > 	mythdvd
> > 	mythmusic
> > 	mythtv-backend
> > 	pdfedit
> > 	trustedqsl
> > 	virtualbox-ose

>   Okay that's quite a few, so the "Conflict" option sucks.

Well, considering this is a very small percentage of the total libqt3
reverse-deps, I think it's at least a "less bad" solution than a library
transition.  I don't know for sure, but would expect the impact on
dist-upgrades to be manageable.

> Here is another plan, tell me what you think, we put a debian specific
> hack in the glibc to reenable the extern inlines for _ONLY_ the packages
> that ask for it, for lenny, and remove it in lenny+1.

>   Qt _has_ to use it to build, though digikam and friends won't, so that
> they will _stop_ using the damn symbols. This way partial upgrades to
> lenny works, and in lenny+1 the symbols just disappear for good.

>   No Conflicts are needed, We only need a list of _library_ packages
> that have the stat (and other symbols) defined reuploaded with a
> -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK in the CFLAGS.

I would be inclined to argue that the conflicts should still be there in the
lenny+1 libqt3 package, since nothing else would enforce at the package
level that a user doesn't partially upgrade to lenny and then partially
upgrade again to lenny+1.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org