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

Re: proposed resolution to release-critical libtiff3g bugs

On Fri, Jul 23, 2004 at 05:02:28PM -0400, Jay Berkenbilt wrote:
> The bug in my mental picture was that I was imagining libtiff3g
> disappearing from people's installed systems when they installed
> libtiff4.  This, of course, would not happen since the package names
> are different, unless libtiff4 conflicted with libtiff3g, which it
> wouldn't.  (libtiff4-dev would conflict with libtiff3g-dev.)  I was
> left with this notion because I forgot to update this information in
> my brain when the idea of changing the package name was introduced.
> Must be a mental dependency error somewhere, or maybe a loose brain
> cable.  Thanks for bearing with me on this.  It's finally clear in my
> mind.


> I'll have a libtiff4 package ready to upload this weekend, or maybe
> tonight.  I'm not a DD, but I'm on the NM queue and have a few people
> who have sponsored packages.  Worst case, someone can sponsor an NMU.

I'm available for uploading if needed.

> Once the new tiff package has been uploaded, what are the mechanics of
> getting everything else rebuilt?  My inclination would be to report a
> "serious" bug against each package that explicitly depends upon
> libtiff3g stating that there were ABI changes but not source-level
> changes to libtiff, and that any references to libtiff3g or
> libtiff3g-dev need to be changed to libtiff4 or libtiff4-dev, and that
> no other changes are required.

As this would constitute a mass bugfiling, you would need to get
approval for this on debian-devel first and follow the usual rules on
such mass bugreports.

However, it's best to give maintainers of these packages *immediate*
notice of the coming transition, so they can prepare for it even before
libtiff4 is in the archive.  This should be a part of any library ABI
transition.  The more notice you can give maintainers, the fewer bugs we
have to file and the fewer NMUs we have to do.

>    Severity: Serious
>    Justification: FTBFS

>    As a result of an unintended binary interface (ABI) change in
>    libtiff between 3.5.7 and 3.6.1, the libtiff3g and libtiff3g-dev
>    packages have been replaced by libtiff4 and libtiff4-dev.  All
>    packages that depend upon libtiff3g must be recompiled with
>    libtiff4 in order to enter sarge.  Please note that there were no
>    source-level changes, so it should be sufficient to change the
>    dependencies (and build dependencies) and recompile.

It looks good to me, but I would change "in order to enter" for "to be
included in".  Most of these packages are already in sarge right now, so
it should be clear that recompiling is still a must for the release.

You should also run this by debian-devel when the time comes for filing
bugs.  See Section 7.1.1 of the developer's reference.

> However, in one of your earlier messages, you said:

> >  Following this with a healthy dose of recompile NMUs should let us
> >  transition the whole lot in a couple of weeks, in time for sarge.

> By what mechanism does this happen?  Who does it?  When does it
> happen?  Does this preclude the need to file a bug against each
> package?  Obviously it isn't going to work to wait for individual
> maintainers to take care of this, though surely some will act quickly.

I would allow one week after the upload of libtiff4 before starting to
NMU packages that depend on it.  The mass bugfiling would perhaps come a
couple of days before this.  It is expected that, without permission of
the maintainer, you don't NMU for issues that haven't been reported in
the BTS; but assuming you contact the maintainers outside the BTS before
uploading libtiff, I don't think there needs to be much time between
filing and NMUing.

As far as who does the NMUing, I would suggest rolling the NMUs into a
weekend BSP as part of the sarge preparation.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: