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