[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Broken uploads to mentors.debian.net



On Sun, 15 Jul 2007 00:31:29 +0200
Christoph Haas <haas@debian.org> wrote:

> On Sat, Jul 14, 2007 at 10:42:52PM +0100, Neil Williams wrote:

> > Is this a result of the need to allow repeated uploads of packages at
> > the same version?
> 
> Actually I don't like the idea of uploading a different file with the
> same revision number. But a lot of sponsors seem to expect a ~mentors001
> revision suffix or just always a "-1" revision until the package is
> sponsored. When I sponsor packages I always make my sponsorees use
> proper revision numbers. Who cares if it takes 10 revisions until the
> package is ready for upload? Let it be revision "-10" then. At least I
> don't need to know that the sponsoree meant "the version from yesterday
> evening 7 p.m. CET-4" but rather use revision "-4". I found it
> educationally better to handle mentors.debian.net just like the usual
> ftp-master:
> - once uploaded the orig tarball can't be altered any more
> - new uploads are only valid with higher version/revision numbers

I'm coming around to that way of doing things, I must say.
:-)

Aligning m.d.n with ftp-master can't really be a bad thing - the fewer
surprises I get, the easier it is to sponsor.

AFAICT the habit of keeping the same version during sponsorship comes
down to "the package hasn't been uploaded to Debian / is not available
to users so why change the version". Personally, I'm beginning to think
that this is spurious. Lots of upstream packages move from 0.1 to 0.6
and there is no particular reason why all debian versions must be
sequential - gaps are perfectly acceptable. If sponsors choose to
create gaps during sponsoring and then use -sa as necessary, is there
really a problem with that?

> - the sponsoree somehow alters the orig tarball but keeps the filename
>   (or rather the name and version number)
> - mentors.debian.net believes it already has the orig file in the pool
>   directory and ignores the newly uploaded file
> 
> Instead of obeying the MD5 sum of the package at that point (I do when
> the .dsc file is checked though) I'll make sure that all the uploaded
> files will replace all previous existing files of a source package in
> the pool directories. That should do it.

Thanks for the quick response.
 
> > At the very least, m.d.n should be able to prevent this situation where
> > 'dget -x' fails as this is the most common method of sponsors obtaining
> > sources from m.d.n.
> 
> Correct. I have to either forbid that or make it work gracefully.
> I think I'll rather accept that but send the uploader a big warning.

OK.
 
-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpjil6Err4VI.pgp
Description: PGP signature


Reply to: