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

Uploading for etch-backports



Hello.

Looks that etch-backports repo actually already exists on backports.org
Also looks like documentation on the site is outdated.

Could someone please explain me what I (a DD) should do do upload to 
etch-backports? E.g. whom should I contact to get my DD key imported into 
backports keyring?

Also, what is the current policy for etch-backports uploads? Some points 
are below.

What is the "official" policy on packages that could be just installed from 
testing (while glibc 2.5 is not yet in testing, there still are some). I 
think that putting those on backports.org may still be a good idea - to 
make it possible for people to keep only etch and etch-backports (and not 
testing/unstable) in their sources.list.

What is the "official" policy on version strings? ~bpo.N? See my previous 
mails to the list on this. I still think that ~bpo40-N is not too 
bad-looking, and is better scalable to multiple-suite situation.

What is the "official" policy on allowing/disallowing post-etch libraries 
into etch-backports? What about other "infrastructure-changing" things?

Is there any "official" policy on what should NOT be allowed into 
etch-backports (e.g. to keep etch+backports systems not "too different" 
from etch)? I guess glibc should not be backported - but not only glibc...

Any "officially recommended" way to build for etch-backports? E.g. pbuilder 
with etch as high-prioruty apt source and etch-backports as a low-priority 
apt source and PBUILDERSATISFYDEPENDSCMD set to 
pbuilder-satisfydepends-experimental 

Maybe it is a good time to discuss and document these and other related 
policy issues.

Nikita

Attachment: pgpSAPAlv6qFg.pgp
Description: PGP signature


Reply to: