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]
