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

Re: libjpeg62-dev -> libjpeg-dev transition



On Sat, Sep 19, 2009 at 03:00:54PM -0700, Steve Langasek wrote:
> On Sat, Sep 19, 2009 at 07:40:28PM +0200, Pierre Habouzit wrote:
> > On Sat, Sep 19, 2009 at 07:20:40PM +0200, Pierre Habouzit wrote:
> > > On Sat, Sep 19, 2009 at 02:32:51PM +0200, Andreas Barth wrote:
> > > > * Pierre Habouzit (madcoder@madism.org) [090919 01:08]:
> > > > > I'll put blocks in my hint file to be sure that both those packages will
> > > > > migrate in testing together (I'm unsure if britney is clever enough to
> > > > > block them until all the binNMUs are done, I don't think it is). Then
> > > > > please ask for binNMUs of all the package that B-D on libjpeg-dev. Then
> > > > > we will let that migrate.
> 
> > > > The question is: Are libjpeg62 and libjepg7 co-useable? (This only
> > > > works if symbol versioning is turned on.)
> 
> > > Huh, libjpeg62 and libjpet7 have different so-name so they are
> > > co-installable. I don't get what you mean with "co-useable" and it
> > > certainly has nothing to do with symbol versioning.
> 
> > If you meant things built against libjpeg7 and loading plugins linked
> > against the libjpeg62 then yes, I think we're good, because libjpeg7
> > uses symbol versioning. libjpeg62 doesn't though.
> 
> Then they're not usable together under any circumstances where libjpeg7 will
> be loaded into memory first.

Hmm, you're right.

So we need an intermediate upload before the virtual package changes where
libjpeg7 Breaks libjpeg62. Bill could you do that please ?

Then we'll proceed with switching the -dev Provides, blocking libjpeg62 from
tansitionning, and launching the binNMUs of anything that build-depends upon
libjpeg-dev.

Then we'll see what becomes uninstallable because of the breaks, and fix those
packages first. Then let that migrate.

Bill, could you also check if any of the packages that already Build-Depend on
libjpeg-dev will FTBFS ? Those packages have to be fixed before we start the
binNMU campaign, so that no _known_ issue impedes us. We'll already have our
load of unexpected ones...

TIA.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: signature.asc
Description: Digital signature


Reply to: