Re: Proposal(s) for handling libqt3-mt situation
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/