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!
http://www.take6.com/albums/greatesthits.html
Reply to: