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. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature