Re: petsc_2.3.0-1_i386.changes REJECTED
On Thu, 2005-12-15 at 15:05 +1000, Anthony Towns wrote: On Wed, Dec 14, 2005 at 09:29:11PM -0500, Adam C Powell IV wrote: 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. So upload it? If you've replied to the REJECT message with appropriate reasons why the REJECTion was wrong, that seems the natural thing to do? Well, I don't see how it's natural to put something in the queue to wait another few weeks, but then I had already waited a couple of weeks since the discussion concluded so it could do no more harm... Thanks, I'll try again. -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]
Re: petsc_2.3.0-1_i386.changes REJECTED
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]
Re: petsc_2.3.0-1_i386.changes REJECTED
On Wed, Dec 14, 2005 at 09:29:11PM -0500, Adam C Powell IV wrote:
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.
So upload it? If you've replied to the REJECT message with appropriate
reasons why the REJECTion was wrong, that seems the natural thing
to do?
Leaving a pointer to the analysis in the changelog entry (Introduce
unversioned development packages, libpetsc-{dev,dbg} as per
http://lists.debian.org/debian-release/...;) would be helpful, but I
don't think even that's necessarily required or expected.
It's usually best just to upload stuff rather than wait for permission --
we've got plenty of procedures in place to stop bad uploads from doing
too much harm; in this case, the queue/new delay. (Not that that's an
excuse to setup a procmail script to reupload everything that gets a
REJECT or anything crazy like that...)
Cheers,
aj
signature.asc
Description: Digital signature
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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? 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]
Re: petsc_2.3.0-1_i386.changes REJECTED
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. 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. 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...) 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. 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), No, actually, there are vocal *proponents* of versioned -dev packages. That's not the same thing as broad consensus. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: petsc_2.3.0-1_i386.changes REJECTED
Hi, Adam C Powell IV wrote: * 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.) Eh. I only said that versioned -dev packages seem tolerable to most people. In particular, I don't really like the idea of my name being mentioned so close to petsc's use of the alternative system. IMHO it's a genuine example of a very bad idea. * There is a very strong consistency argument for keeping petsc-dev, cf. octave, python-dev, linux-image-2.6-xxx, though I don't really think that any of these packages have too much in common with petsc-dev - octave and linux-image-2.6-xxx aren't even -dev packages. Python and the notion of a default-python-version and it's implementation seems rather special to me, and TBH, I don't think anyone claims that the python dependency construction is without problems. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: petsc_2.3.0-1_i386.changes REJECTED
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. 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. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: petsc_2.3.0-1_i386.changes REJECTED
On Wed, Nov 16, 2005 at 01:46:04AM -0600, Peter Samuelson wrote: [Steve Langasek] python-dev provides an interface that packages can build-depend on which gives them both /usr/bin/python, and a set of development tools from the corresponding version of python. This is not analogous to petsc-dev, which only depends on the versioned -dev package. The only point of python-dev seems to be to pull in the development package for Debian's default python version. That it also pulls in 'python' (another near-empty package) is pretty incidental to that. No, it is *not* incidental to that. Package: python-dev Depends: python (= 2.3), python ( 2.4), python2.3-dev (= 2.3.4-18) If the python dependency were incidental, there would be no reason for the versioned dependency. This is specifically there to ensure that you get a consistent devel environment for the version of python that's installed as /usr/bin/python. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: petsc_2.3.0-1_i386.changes REJECTED
On Tue, 2005-11-15 at 23:03 -0800, Steve Langasek wrote: On Tue, Nov 15, 2005 at 05:15:28PM -0500, Adam C Powell IV wrote: On Mon, 2005-11-14 at 23:59 -0800, Steve Langasek wrote: I understand that, and the whole proposal. And it will break a lot of things for many of my users, who need to use old versions of the -dev packages at the same time -- which is why I do the versioned -dev packages and the alternatives system. *Why* do users need to use old versions of -dev packages at the same time? How can it be so important to maintain parallel installable versions of devel packages for a library package that has only *one* reverse-dependency in Debian? Users of PETSc are developers, almost always of some local code of their own, most of the time which links with third-party libs, such as libmesh (not yet in Debian), dolfin (from what I hear may soon be in Debian), etc. Because PETSc upstream changes its API with every point release, a user's local code -- and these various third-party libs -- often lag behind, such that upgrading a single libpetsc-dev package would break all of those builds. On the other hand, upgrading my petsc-dev package requires only a simple update-alternatives --config to reinstate the older version as the default, since the newer one doesn't conflict with or replace the older one. Ah, I didn't notice the alternatives there. That's definitely an interesting approach to dev packages; though given that only root can run update-alternatives, I don't know that this is really much of an advantage over just keeping two .debs around and switching between them. PETSc also provides its own sort of alternatives mechanism: a programmer is required to set PETSC_DIR in order to program with PETSc at all, and that can be e.g. /usr/lib/petscdir/2.3.0 or /usr/lib/petscdir/2.2.0 etc. The static libs are there, along with links to the shlibs, C includes, makefile includes, my own petsc.m4, various scripts, etc. I put the real shlibs, and alternatives slaves to the static libs, in /usr/lib following the FHS. There are also alternatives slaves for the C includes dir, petsc.m4, etc. So a user can either manually set PETSC_DIR to point to a particular version, or set it to /usr/lib/petsc to use the system default pointed to by the alternatives symlink. All of this is documented in README.Debian, which is also at http://lyre.mit.edu/~powell/petsc/README.Debian 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. Anyway, the empty petsc-dev package is completely pointless. It can't be used sanely as a dependency or build-dependency, because it does *not* guarantee a constant interface thanks to petsc's FHS-incompatible layout. I think it would be better if there *were* a single petsc-dev package containing the header files and library links in FHS locations, making libpetsc2.2.0-dev unnecessary; but if this is not to be the case for whatever reason, then petsc-dev ought to be dropped. In any case, I agree with Joerg that there ought to only be one -dev package here... So then, we don't need python-dev? python-dev provides an interface that packages can build-depend on which gives them both /usr/bin/python, and a set of development tools from the corresponding version of python. This is not analogous to petsc-dev, which only depends on the versioned -dev package. Okay, noted your followup posts, python-dev is perhaps not the best analogy. It also helps that most of the python API is stable, vs. most PETSc upgrades require code changes. 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. Thanks again for the thoughtful reply. Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe!
Re: petsc_2.3.0-1_i386.changes REJECTED
On Mon, 2005-11-14 at 23:59 -0800, Steve Langasek wrote: [redirecting this to -devel; discussions of ftp team NEW queue policies are off-topic for -release.] Sorry, my mistake. I'm adding debian-beowulf because that's where some of PETSc's users are. On Mon, Nov 14, 2005 at 05:13:47PM -0500, Adam C Powell IV wrote: And thats what I asked for, yes. Drop the version from -dev|-dbg|-doc, use the shlib system for the rest (which makes packages built against it depending on the right version) and have fun. I understand that, and the whole proposal. And it will break a lot of things for many of my users, who need to use old versions of the -dev packages at the same time -- which is why I do the versioned -dev packages and the alternatives system. *Why* do users need to use old versions of -dev packages at the same time? How can it be so important to maintain parallel installable versions of devel packages for a library package that has only *one* reverse-dependency in Debian? Users of PETSc are developers, almost always of some local code of their own, most of the time which links with third-party libs, such as libmesh (not yet in Debian), dolfin (from what I hear may soon be in Debian), etc. Because PETSc upstream changes its API with every point release, a user's local code -- and these various third-party libs -- often lag behind, such that upgrading a single libpetsc-dev package would break all of those builds. On the other hand, upgrading my petsc-dev package requires only a simple update-alternatives --config to reinstate the older version as the default, since the newer one doesn't conflict with or replace the older one. 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? Why are multiple versions not worth supporting in Debian? With just 72 users in popcon, and weighing in at about 140 MiB/distro (woody, sarge and etch/sid), I don't think it's worth n-tupling the impact on the mirrors for these few users. 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. Why is coinstallability worth supporting? The package is worth much more to those few users with this feature than without it, as described above. I've had a number of users contact me about old versions, which are available at a URL in README.Debian, and which might be necessary for an old version of one of the packages mentioned above, or even some old code written by a former grad student in a research group. [The alternatives system can also be used for alternate builds of PETSc, e.g. vs. the LAM MPI implementation instead of mpich, complex or single- precision, -contrib version linked against ParMETIS and hypre, etc. All of these are build-time options described in README.Debian. Such packages have different names and library sonames, so the shlib system can set package lib dependencies for any resulting binaries.] Anyway, the empty petsc-dev package is completely pointless. It can't be used sanely as a dependency or build-dependency, because it does *not* guarantee a constant interface thanks to petsc's FHS-incompatible layout. I think it would be better if there *were* a single petsc-dev package containing the header files and library links in FHS locations, making libpetsc2.2.0-dev unnecessary; but if this is not to be the case for whatever reason, then petsc-dev ought to be dropped. In any case, I agree with Joerg that there ought to only be one -dev package here... So then, we don't need python-dev? According to popcon, 36 people have petsc-dev installed, 72 libpetsc2.2.0-dev, so roughly half of the PETSc users find petsc-dev useful. By comparison, about 3/4 of python2.3-dev users have python-dev installed, a similar ratio for a package which serves a similar purpose. Or will python-dev be rejected next time, or the entire python-defaults source package? Thanks for the reply. I think there's a good case for keeping the package as it is, and have yet to hear good counter-arguments to the above which don't apply to other packages. If python-dev qualifies for rejection, then I can understand petsc-d[ev|bg] as well. Please CC me in replies. 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]
Re: petsc_2.3.0-1_i386.changes REJECTED
On Tue, Nov 15, 2005 at 05:15:28PM -0500, Adam C Powell IV wrote: On Mon, 2005-11-14 at 23:59 -0800, Steve Langasek wrote: I understand that, and the whole proposal. And it will break a lot of things for many of my users, who need to use old versions of the -dev packages at the same time -- which is why I do the versioned -dev packages and the alternatives system. *Why* do users need to use old versions of -dev packages at the same time? How can it be so important to maintain parallel installable versions of devel packages for a library package that has only *one* reverse-dependency in Debian? Users of PETSc are developers, almost always of some local code of their own, most of the time which links with third-party libs, such as libmesh (not yet in Debian), dolfin (from what I hear may soon be in Debian), etc. Because PETSc upstream changes its API with every point release, a user's local code -- and these various third-party libs -- often lag behind, such that upgrading a single libpetsc-dev package would break all of those builds. On the other hand, upgrading my petsc-dev package requires only a simple update-alternatives --config to reinstate the older version as the default, since the newer one doesn't conflict with or replace the older one. Ah, I didn't notice the alternatives there. That's definitely an interesting approach to dev packages; though given that only root can run update-alternatives, I don't know that this is really much of an advantage over just keeping two .debs around and switching between them. 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... Why is coinstallability worth supporting? The package is worth much more to those few users with this feature than without it, as described above. I've had a number of users contact me about old versions, which are available at a URL in README.Debian, and which might be necessary for an old version of one of the packages mentioned above, or even some old code written by a former grad student in a research group. Ok, that's fair. Anyway, the empty petsc-dev package is completely pointless. It can't be used sanely as a dependency or build-dependency, because it does *not* guarantee a constant interface thanks to petsc's FHS-incompatible layout. I think it would be better if there *were* a single petsc-dev package containing the header files and library links in FHS locations, making libpetsc2.2.0-dev unnecessary; but if this is not to be the case for whatever reason, then petsc-dev ought to be dropped. In any case, I agree with Joerg that there ought to only be one -dev package here... So then, we don't need python-dev? python-dev provides an interface that packages can build-depend on which gives them both /usr/bin/python, and a set of development tools from the corresponding version of python. This is not analogous to petsc-dev, which only depends on the versioned -dev package. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: petsc_2.3.0-1_i386.changes REJECTED
[Steve Langasek] python-dev provides an interface that packages can build-depend on which gives them both /usr/bin/python, and a set of development tools from the corresponding version of python. This is not analogous to petsc-dev, which only depends on the versioned -dev package. The only point of python-dev seems to be to pull in the development package for Debian's default python version. That it also pulls in 'python' (another near-empty package) is pretty incidental to that. If petsc-dev has the purpose of providing the development environment for Debian's default (only current shipping?) libpetsc version, that seems like exactly the same situation. The difference would be the expected degree of source API compatibility between library versions in each case - it may be that the python development API is more stable. In either case, though, I can't see why a package would want to build-depend on either petsc-dev or python-dev. signature.asc Description: Digital signature
Re: petsc_2.3.0-1_i386.changes REJECTED
[redirecting this to -devel; discussions of ftp team NEW queue policies are off-topic for -release.] On Mon, Nov 14, 2005 at 05:13:47PM -0500, Adam C Powell IV wrote: And thats what I asked for, yes. Drop the version from -dev|-dbg|-doc, use the shlib system for the rest (which makes packages built against it depending on the right version) and have fun. I understand that, and the whole proposal. And it will break a lot of things for many of my users, who need to use old versions of the -dev packages at the same time -- which is why I do the versioned -dev packages and the alternatives system. *Why* do users need to use old versions of -dev packages at the same time? How can it be so important to maintain parallel installable versions of devel packages for a library package that has only *one* reverse-dependency in Debian? 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? Anyway, the empty petsc-dev package is completely pointless. It can't be used sanely as a dependency or build-dependency, because it does *not* guarantee a constant interface thanks to petsc's FHS-incompatible layout. I think it would be better if there *were* a single petsc-dev package containing the header files and library links in FHS locations, making libpetsc2.2.0-dev unnecessary; but if this is not to be the case for whatever reason, then petsc-dev ought to be dropped. In any case, I agree with Joerg that there ought to only be one -dev package here... So now the needs/requests of the users are less important to Debian than removing two empty packages? Users often make requests that would be bad for the system as a whole if we honored them unconditionally. Package indices that grow without bounds are one way that choices that may be good for a subset of users come with a cost for the rest of our users. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
