Re: Uploading for etch-backports
Nikita V. Youshchenko schrieb am Mittwoch, den 02. Mai 2007:
Hi Nikita,
*snip*
> 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;
This is indeed suboptimal but since with an upgrade the libs got exchanged
there isn't that big problem I think.
> (b) post-etch uploads to sarge-backports - this was unexpected change
> of "rules of the game", making usage of backports.org unsafe.
This was expected as we ever said that sarge-bpo won't be closed after etch
release.
> 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.
Its not that easy to define rules for such things and some problems come
unexpected. Its my personal target for etch-bpo to extend the "policy" if
there is a new case that should be documented. But life isn't always black
and white so is bpo too, there are too much cornercases.
> 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
> :(.
Users should use their brain. I don't see any reason for adding a single deb
to bpo that can get installed directly to etch. Things vary of course if
there are many debs (for example the egroupware backports which contains a
bunch of debs).
> 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.
If you have sane additions to the policy, tell us. They can be discussed and
if they are still sane they will be added.
> 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.
>
done
> > 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?
Its wasn't very easy to automate such things with pbuilder in the past and
sometimes the pbuilder took wrong decisions, for example taking unwanted
dependencies out of backports. Maybe this is better now, I just haven't
tested.
Alex
> 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.
I never thought it as "blaming". I know that some of the topics aren't easy
to solve. But we really try to keep the quality of bpo high, thats one of the
reasons why we try to limit the uploads to bpo a little bit.
Reply to: