[Pkg-octave-devel] Re: hdf5 transition

[Steve Langasek]

On Mon, Mar 20, 2006 at 08:31:11AM +0100, Rafael Laboissiere wrote:
> * Thomas Weber <thomas.weber.mail at gmail.com> [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.
vorlon at debian.org                                   http://www.debian.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20060320/7ace3a1a/attachment.pgp