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

Re: uploading new binary packages from a DM approved source package



Hi,

On Wed, Apr 16, 2008 at 01:08:05PM +0200, Ondrej Certik wrote:
> if I want to packge a new upstream version of DM-Upload-Allowed
> library (for example [1]), it changes the name of the binary package
> and thus goes to NEW.
> 
> Last time I asked it wasn't possible for me, as a DM, to upload it and
> I had to search for a sponsor.
> 
> Is there some policital reason for that,

Yes.  DMs are not as thoroughly checked as DDs, and thus have less
rights to change things in the archive.  The idea is that they should be
allowed to upload packages they already maintain, but not add new ones.
This is true both for new source, and new binary packages.

A library soname transition is a binary package name change for
technical reasons.  IMO there isn't really a good reason to send them
through NEW at all, but that's how the scripts work.  And it's not that
bad, it makes sure there's an extra check on each soname bump, which can
be useful.  It does also mean that DMs need a sponsor for the upload,
but that should be acceptable as well.

> or is it just because noone has yet implemented it in the scripts? If
> the latter case, how can I help?

If you can build consensus on the fact that soname bumps shouldn't go
through NEW, then you could implement that technically.  But I don't
think you will be able to.  In fact, most people might well think that
soname bumps should indeed go through NEW, and that that is not a bug.

Personally I didn't really think about it.  I've never considered it a
problem, but wouldn't consider it a problem if they don't go through NEW
either.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

Attachment: signature.asc
Description: Digital signature


Reply to: