Re: petsc_2.3.0-1_i386.changes REJECTED
Greetings,
Can someone please clarify what's going on here?
* On November 1, I uploaded petsc-2.3.0-1_i386.changes.
* 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.
What gives? Is this sufficient justification for rejecting a
lintian-clean package?
What is "rejected for now", and where is such a process/status described
on the Debian website? Do I re-upload the same package, or bump the
version number and re-upload?
Has my clarification been heard, and accepted? Or Will the package be
rejected again for the same reason?
Looking for answers...
On Wed, 2005-11-09 at 12:53 -0500, Adam C Powell IV wrote:
> On Mon, 2005-11-07 at 18:33 -0500, Adam C Powell IV wrote:
> > On Sun, 2005-11-06 at 11:32 -0800, Joerg Jaspert wrote:
> > > Hi Maintainer,
> > >
> > > rejected for now.
> > >
> > > You have the following binaries in your package:
> > >
> > > 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
> > >
> > > 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.
> >
> > As you may be able to tell, upstream breaks compatibility with every
> > point release of PETSc. 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.
> >
> > This is described in README.Debian.
> >
> > On the other hand, the number of PETSc users is small enough that,
> > unlike say libssl0.9.6/0.9.7 etc., it's not worth it to have multiple
> > versions on the mirrors. I'm pretty sure README.Debian also has a link
> > to http://lyre.mit.edu/~powell/petsc.html which in turn links to a
> > directory containing all of the latest Debian packages for each upstream
> > version of PETSc.
> >
> > Is this now against policy? Otherwise, why such a strong action as a
> > rejection?
>
> Hello? Any reply?
>
> What happens next, do you re-accept, or do I re-upload? What exactly is
> a "reject for now" and is there any established procedure for how it
> works? Can you send me a link?
>
> -Adam
Adam C. Powell, IV
http://lyre.mit.edu/~powell/
Thomas B. King Assistant Professor
of Materials Engineering
77 Massachusetts Ave. Rm. 4-117
Phone (617) 452-2086
Cambridge, MA 02139 USA
Fax (617) 253-5418
Reply to: