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. Thanks, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature