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