[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: petsc_2.3.0-1_i386.changes REJECTED

On Sat, 2005-11-19 at 00:22 -0800, Steve Langasek wrote:
> On Wed, Nov 16, 2005 at 10:53:57AM -0500, Adam C Powell IV wrote:
> > > > > For that matter, why is it important that Debian provide support for
> > > > > coinstallability with older packages that are, evidently, not important
> > > > > enough themselves to be supported by Debian?
> > > > In contrast, libxml-dev has 731 users and at least one major reverse
> > > > dependency (gnucash), making it much more valuable.  Not to mention just
> > > > one large API change, vs. PETSc's, um, 10 or so since I first uploaded
> > > > it.
> > > Right; it's the API changes that make the idea of an unversioned petsc-dev
> > > package of questionable utility...
> > Fair enough.  It's a convenience, but one which forces a user/developer
> > to upgrade his/her code -- or point to the old version (likely still
> > there because there are no conflicts) until such time becomes available.
> > Hmm.  Perhaps the analogy to linux-image-2.6-SUBARCH is better.  The
> > kernel "API changes" enough to suggest or require some new utilities,
> > and obsolete others.  This *usually* doesn't require users to change
> > things, as there's a big effort to be backward compatible (e.g. ALSA
> > provides an OSS-compatible interface), but not always.
> 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?

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?

Again, the point is that these are all over Debian, and it's
inconsistent to accept all but one.

> > But what about the empty linux-image upgrade convenience packages
> > mentioned above?  If the answer is "Such packages are all bad and should
> > go away", I'm fine with that.
> No, I certainly think that packages like linux-image-2.6-686 should be kept
> around.  And you've also made a case for why it may be useful to keep
> petsc-dev around.  In any case, it's ultimately the ftp team's decision to
> make; it sounds to me like all the arguments have been made at this point.

Thanks again for your feedback and explanations.

Joerg, the ball is in your court:

      * There is broad consensus for versioned -dev packages (e.g.
        Thomas Viehmann's precedent, Junichi's libpkg-guide),
        particularly for this case where both the Debian alternatives
        system and PETSC_DIR mechanism allow users to select between
        multiple versions or multiple builds of the same version (LAM,
        single precision or complex, -contrib linked vs parmetis and
        hypre, -dec with HPaq alpha tools, etc.)
      * There is a very strong consistency argument for keeping
        petsc-dev, cf. octave, python-dev, linux-image-2.6-xxx, though
        I'll drop petsc-dbg with its six users on popcon if you like.

What's the verdict?

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!

Reply to: