> > 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 <[EMAIL PROTECTED]> http://www.ql.org/q/
