Re: Uploading for etch-backports
Nikita V. Youshchenko schrieb am Dienstag, den 01. Mai 2007:
> Hello.
>
> Looks that etch-backports repo actually already exists on backports.org
> Also looks like documentation on the site is outdated.
I will update them as soon as I have a little bit more time.
But I wrote most things to the users ml:
http://lists.backports.org/lurker-bpo/message/20070419.092600.5007052f.en.html
> 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.
currently nothing changed. And until somebody come with a good solution
without ugly version strings it will stay the same.
> What is the "official" policy on allowing/disallowing post-etch libraries
> into etch-backports? What about other "infrastructure-changing" things?
Same as for etch. Don't do it until neccessary. If ever possible build
against the etch libs and don't import new libs to bpo.
> 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...
No, this has to be decided "per case". If in doubt, ask me.
> 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
I personally use just a chroot. Everything else breaks to fast (at least it
did when I started to do backports a few years ago).
> Maybe it is a good time to discuss and document these and other related
> policy issues.
Already been done.
Alex
P.S. if somebody has enough time to do some updates on the webpage let me
know.
Reply to: