Re: petsc_2.3.0-1_i386.changes REJECTED
On Mon, 2005-11-14 at 21:32 +0100, Joerg Jaspert wrote:
> 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.
I understand, these things happen. :-)
> > What gives? Is this sufficient justification for rejecting a
> > lintian-clean package?
>
> Yes.
Wow, that's news to me...
> > 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.
And the latest version of libpetsc2.3.0-d[ev|bg].
> >> > > 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.
Right, but I mention in the README.Debian that users can download the
old -dev and -dbg versions from a separate website.
> 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.
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.
So now the needs/requests of the users are less important to Debian than
removing two empty packages?
Thanks for the reply,
-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: