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

Re: petsc_2.3.0-1_i386.changes REJECTED

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

> 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?

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

Welcome to the best software in the world today cafe!

Reply to: