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
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
Reply to: