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?
Cheers,
-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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
