Re: proposed resolution to release-critical libtiff3g bugs
> > If we do this, forcing all these packages to recompile without
> > any changes would resolve the problem in sarge. The package
> > maintainers, at their option, could replace their dependencies
> > on libtiff3g to libtiff4 instead, or they could wait if they
> > don't care about the changes.
>
> Package maintainers do *not* have the option of not recompiling
> for transitions like this. You must remove libtiff3g altogether
> and force a transition to libtiff4; and only after the transition
> is completed would you re-introduce libtiff3g if you felt it was
> necessary. If you give maintainers the option, RC bugs will be
> missed until libtiff3g reverts to the previous ABI, and by then it
> would be too late.
A light just turned on in my brain and I figured out where I went
wrong. Everything is now clear.
Obviously changing the tiff source package to produce libtiff4 and
libtiff4-dev but not libtiff3g and libtiff3g-dev will make the
libtiff3g and libtiff3g-dev binary packages disappear from 'unstable'.
This in turn makes it impossible to *install* applications that have
yet to be rebuilt. This is what you originally said (something like
"packages would be uninstallable during the transition"), but I
misunderstood it. Replacing libtiff3g-dev with libtiff4-dev will make
it justifiable to file FTBFS bugs against packages that haven't been
rebuilt, since packages that build-depend upon libtiff3g-dev would no
longer have satisfiable build dependencies.
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.
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. Something like this:
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.
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.
Thanks for your prompt responses and patience. As a concerned user
and prospective DD, I'm making a concerted effort to get the libtiff
issues resolved for sarge, particularly knowing that we have a very
bad situation right now. As a relative newcomer to Debian though, I'm
still feeling my way around. I'll proceed in this direction pending
further guidance, but I won't post any bug reports relating to this at
least until sometime tomorrow afternoon, east coast US time (GMT
-0400).
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
Reply to: