Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV <hazelsct@debian.org>]

Joerg,

Did you receive this email or any of this thread?  It's now more than
two weeks old, and I'd really like to upload a new PETSc 2.3.0 ASAP.  If
you didn't see it, the discussion was on debian-release, archive at
http://lists.debian.org/debian-release/2005/11/msg00107.html , then
Steve Langasek moved it to debian-devel (and I copied debian-beowulf) at
http://lists.debian.org/debian-devel/2005/11/msg00986.html

In particular, can you please reply to:

      * Strong support for versioned -dev packages, and in particular,
        the PETSc alternatives system which lets admins choose between
        different versions or different builds of the same version
        (single/double/complex, with/without parmetis and hypre, gcc/ccc
        compilers, mpich/lab MPI implementation, etc.), and PETSC_DIR
        which lets user/developers choose between installed versions.
        Removing the version from the -dev package would cause all
        user/devs a lot of trouble during upgrades -- and the vast
        majority of users are devs, 43 have -dev vs. 45 the lib.
      * Inconsistent application of the "no empty packages" rule, a rule
        which is not found in policy (or if it is, please show me
        where), cf. octave, python(-dev), linux-image-2.6, etc.

As mentioned, I'd be happy to remove petsc-dbg, it's petsc-dev which is
important -- and installed by 39/43 of the users of petsc2.2.0-dev
according to popcon.

Regards,
Adam

On Mon, 2005-11-28 at 15:11 -0500, Adam C Powell IV wrote:
> On Sun, 2005-11-20 at 17:50 -0800, Steve Langasek wrote:
> > On Sun, Nov 20, 2005 at 06:57:36PM -0500, Adam C Powell IV wrote:
> > > > Well, I think the factor there is that we "usually" want users to upgrade to
> > > > the latest kernel automatically, whereas users of petsc usually can't
> > > > auto-upgrade to the new API.
> > 
> > > Okay, then what about octave, another empty package which forced an
> > > incompatible auto-upgrade from octave2.0 to octave2.1, and now to 2.9?
> > 
> > Probably depends on how incompatible the upgrades are.
> 
> I've only worked with octave a bit, but such upgrades have bit me on all
> of the .m files I've written.  I'd say roughly similar backward
> compatibility to PETSc-linked source.  There's a larger user community
> for octave, but that's why I don't put multiple PETSc versions in Debian
> simultaneously.
> 
> > BTW, the other big reason for linux-image-2.6-$flavor metapackages is that
> > they provide a hook for debian-installer, so the installer doesn't have to
> > be futzed with in 5 places every time there's a kernel update.
> 
> Okay, fair enough.
> 
> > > And come to think of it, the python-dev python version consistency
> > > argument doesn't really apply to anyone running a single distribution,
> > > because the "python" version in that distribution is automatically
> > > identical to the "python-dev" version.  The only way this "guarantee" of
> > > the same pythonx.y-dev and python -> pythonx.y actually does anything is
> > > if an admin somehow attempts to shoehorn the woody python with the sarge
> > > python-dev onto the same system, and how likely is that?
> > 
> > So you're suggesting that people who package python tools should be ok with
> > having to update their build-dependencies as part of every python
> > transition, even when nothing else in their package needs to change?  (This
> > also has implications for backports and cross-ports, mind you...)
> 
> No, I'm merely saying that the versioning in the python dep is
> irrelevant because python-dev and python will automatically have the
> same version in every Debian release.
> 
> As for what should be OK, two scenarios: (1) empty upgrade packages are
> good, so people build-dep on python-dev, which depends on python; (2)
> empty upgrade packages are bad, so people build-dep on "python2.3-dev |
> python-dev", the latter of which is a virtual package provided by
> python*-dev.  No need to change the python-dependent package.
> 
> > > Again, the point is that these are all over Debian, and it's
> > > inconsistent to accept all but one.
> > 
> > I don't think anyone has been proposing an inconsistent guideline, here.
> > I'll grant you that these guidelines probably haven't been *applied*
> > consistently in the past, but that's not the same thing.
> 
> Makes sense.  Can someone please write the guideline somewhere,
> preferably in policy, so we can apply it?
> 
> Thanks,
> -Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html