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
