On 10473 March 1977, Adam C. Powell, IV wrote:
> * On Sunday 11/6, Joerg Jaspert marked my upload "rejected for
> now", citing number of packages and naming convention as a
> reason.
> * I gave the reason for my naming convention and number of
> packages.
> * He hasn't replied in a week.
Oh wow. A week. How bad of me.
> What gives? Is this sufficient justification for rejecting a
> lintian-clean package?
Yes.
> Has my clarification been heard,
Yes.
>> > > libpetsc2.3.0 - Shared libraries for version 2.3.0 of PETSc
>> > > libpetsc2.3.0-dbg - Static debugging libraries for PETSc
>> > > libpetsc2.3.0-dev - Static libraries, shared links, header files for PETSc
>> > > petsc-dbg - Empty package depending on latest PETSc debugging package
>> > > petsc-dev - Empty package depending on latest PETSc development package
>> > > petsc2.3.0-doc - Documentation and examples for PETSc
The empty packages are useless here. They dont bring you or the users
anything except confusion.
>> > > Why not simply drop the petsc-[dbg|dev] dummy packages and rename the
>> > > libpetsc2.3.0-[dbg|dev] to libpetsc-[dbg|dev]? That should get you exactly
>> > > the same effect as you have right now, but kills the ugly dummy packages.
>> > > I would also drop the version number from the -doc package, as you dont keep
>> > > the old one around, so no version needed.
>> > > If you have good reasons to keep it this way, and I just dont see them - please
>> > > reply to this mail stating them.
Thats why i suggest to remove them and to drop the version number out of
the [dbg|dev] package. The actual lib can keep the version, I personally
would prefer to drop the minor part of it, except upstream is that
braindead that even minor versions are incompatible.
>> > As you may be able to tell, upstream breaks compatibility with every
>> > point release of PETSc.
Wäh, looks like they are.
>> > Because a number of developers work with specific packages which
>> > use PETSc, from Illuminator (debianized) to Dolfin and libmesh (not
>> > yet), each of which builds against a specific version of PETSc (and
>> > they upgrade somewhat asynchronously), it's important to be able to
>> > install multiple versions of the development packages side by side.
>> > That's why I use the alternatives system to switch between them.
I just skip the alternatives system and -dev package in one sentence
(It's a sick and ugly idea), but except that your "solution" doesnt work
as I understand what you wrote.
Right now your petsc builds:
libpetsc2.2.0, libpetsc2.2.0-dbg, libpetsc2.2.0-dev, petsc-dbg,
petsc-dev, petsc2.2.0-doc.
Now you upload with the packages listed at the top of this mail. That
makes the ones from 2.2.0 right away to be "Not built from source" and
one of us ftpmasters removes them within a few days. Which makes them
disappear from unstable, and a short time later also from testing,
whenever britney feels its good to do.
So you can't count on multiple versions to be available until you upload
multiple of them in different source packages (DON'T). IOW: No reason
for the layout as it's right now.
--8<------------------------schnipp------------------------->8---
As an example take linux-ntfs, which was uploaded yesterday changing
its lib-package:
* linux-ntfs_1.12.1-1 builds: ntfsprogs, libntfs-gnomevfs, libntfs-dev,
ntfstools-udeb, ntfstools, libntfs8
but no longer builds:
o 1.11.2-3: libntfs7
--8<------------------------schnapp------------------------->8---
This is what you see in http://ftp-master.debian.org/removals.txt marked
as "[rene]".
On 10473 March 1977, Luk Claes wrote:
>> I don't see anything there pertaining to my package. Perhaps I am
>> overlooking something, can you please be more specific?
> Look at package split... You split the package too much...
>> Hmm, there are numerous such meta packages in Debian, are they now
>> against policy or otherwise discouraged? How is a user to automatically
>> update to the latest version?
> There are only a very few of this *empty* meta packages... though there
> are a lot of unversioned development packages... Apparantly you didn't
> understand Joerg's proposal? He proposed to remove the empty packages
> and to drop the version in the *name* of the development, debug (and
> documentation) package. This will make sure that a user automatically
> updates to the latest version...
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.
--
bye Joerg
<liw> er, *not* what I meant, is what I meant
Attachment:
pgpX418uEuK9j.pgp
Description: PGP signature