[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: