> 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.e >n.html Thanks for your answers. I am currently in doubt - should I use etch + backports.org, or etch + private backports for our local needs. Although private repository has obvious disadvantages in maintaince, I'm very concerned about lack of well-defined, detailed, written policy rules for backports.org. In past, there have been several situations with backports.org that lead to inconsistencies. Two examples of it that first come in mind are: (a) qt4 backport with same library package names as in testing, but with different C++ ABI; I tried to write about that on the list, and suggested a better (IMO) backport, but never got reply; (b) post-etch uploads to sarge-backports - this was unexpected change of "rules of the game", making usage of backports.org unsafe. For me, the main advantage of Debian compared to other distros is package consistency. Maybe it's the result of having to maintain at least several tens of long-living debian installations. Also I'm trying to teach students about consistency issues. So if I will recommend to use backports repo, this repo should not break system consistency. Of cource usage of additional repo may "change rules" a bit - but new rules should still be very clear. Also unpleasant for me is this backports.org decision: > I don't think we should upload packages to bpo simply because we can do > it if you can install the package directly from testing without any > recompilation Although this "issue" will almost disappear as soon as glibc 2.5 enters testing, some packages (ntfs-3g, to name one) are needed today. And am very uncomfortable with the idea to recommend users to add testing as low-priority apt source - this will 99% result into misuse of "apt-get -t testing install xxx" and eventially they will come and ask me to repair their systems. This already happened too often in the past :(. So looks like I will have to set up a local backports repo - with well-defined "rules of the game". But I will still look at backports.org, and will immediately switch to it as soon as I will feel it is safe. But anyway I will do some backports, and I'm explicitly asking for possibility to upload those to backports.org, to share my work with backports.org users. Please add my debian key (one with which this mail is signed) to the backports.org keyring. > > 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). This looks very strange for me. How could chroot (that accumulates previous changes, some of which could potentially be destructive) be safer than pbuilder that creates fresh environment for every individual build? Nikita P.S. I'm not trying to blame backports.org. Backports.org is a great effort, useful for many people. Thank you for doing it. The only goal of writing this mail is to share my thoughts on the topic.
Attachment:
pgpwqfaMOPNrJ.pgp
Description: PGP signature