On Mon, Mar 20, 2006 at 08:31:11AM +0100, Rafael Laboissiere wrote: > * Thomas Weber <[EMAIL PROTECTED]> [2006-03-20 07:58]:
> > both 2.1 and 2.9 packages of Octave have been semi-automatically been > > updated to a new hdf5 library. > > changelog: > > ===================================================================== > > octave2.1 (1:2.1.72-12+b1) unstable; urgency=low > > > > * Binary-only non-maintainer upload for i386; no source changes. > > * Rebuild against libhdf5 1.6.5 > > > > -- Debian/i386 Build Daemon <buildd_i386-cyberhq> Fri, 17 Mar 2006 > > 21:31:52 -0800 > > ===================================================================== > > I don't have a clue, why a transition to 1.6.5 is so urgent (it hit > > unstable 3 days ago). Does anybody have an idea about this? Er, it's not urgent at all, but neither is there a reason to delay it AFAICT? Since octave2.1 was uploaded at about the same time that hdf5 cleared the NEW queue, there was certainly no way that octave2.1 was going to reach testing ahead of hdf5 itself, since at least one of the (non-binNMUed) builds of octave2.1 1:2.1.72-12 built against libhdf5-1.6.5-0 instead of libhdf5-1.6.4-0c2. Likewise, the octave2.9 builds on alpha, mips, mipsel, and powerpc are all linked against hdf 1.6.5; since britney isn't going to keep libhdf5-1.6.4-0c2 around when pushing libhdf5-1.6.5 into testing, the only way these packages get into testing now is if they're updated on all architectures to use 1.6.5 instead of 1.6.4. > I think that once hdf_1.6.5 will enter testing, the transition package > hdf5_1.6.4-0c2 will be removed from the archive. This will stale all the > packages in testing depending on the 1.6.4-0c2 version. Rather, the update in testing is not possible at all until all related packages are in sync. > The release team is apparently taking care of this. However, since I am > not subscribed to the debian-release mailing list, I only discovered the > post above today. My understanding is that we should not upload new > versions of octave2.1 and octave2.9 until the aging period is finished. It would be appreciated if you didn't upload new versions of those packages without an important reason that would justify delaying the hdf5 transition, yes. > I am hence Cc:ing this message to the debian-release mailing list, along > with the following request to whoever did the upload of the new > binary-compatible packages: the next time such uploads are done, could > you please keep the maintainers informed? Do you mind if I ask why you feel such notification is important? Part of the value of binNMUs is that it lets rebuild-only library transitions be completed without the need to involve maintainers (as well as without any need to add backport-disrupting versioned build-dependencies). If I'm going to have to negotiate binNMUs for each package individually with the maintainer, I might as well not try, and just file RC bugs against all the packages instead. Given that these are not sourceful changes, I think it's better to trust the release team and the porters to know when a binNMU is needed. As I noted above, it's not as if the binNMUs in question were actually disruptive; octave2.1 and octave2.9 were already going to be left uninstallable in unstable, and owing to the timing of the uploads neither package was going to be able to migrate to testing ahead of hdf5. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
