Steve Langasek <[EMAIL PROTECTED]> wrote:

> On Mon, Mar 14, 2005 at 10:06:35AM -0600, John Goerzen wrote:
>
>> I also have no objection to releasing stable later on some archs, or not
>> at all, of nobody from those archs works to do it.
>
>> I do object to preventing those archs from releasing stable, and from
>> being supported at all by the security infrastructure.
>
> Please clarify what you think a late-releasing stable arch is going to
> look like, in contrast to what has been proposed, given that keeping
> release architectures in sync is the only thing we have that guarantees
> the sources in testing (and therefore in stable) are in a releasable
> state for each of those architectures.

I guess the late-releasing stable arch would very much look like the
core architectures, just that its buildd's took more time to do the
compilation, and that there are different promises to our users on this
arch (security support by the porters team "as good as possible").

In case there are bugs in the release that are RC bugs for the
late-releasing, tier-2 arch, but do not apply to the main arches (or are
not RC for them), there are two possibilities:

a) drop that package (and (build-)dependencies) from that arch.  That
   might well be a working alternative; arches that are used for
   embedded devices, or mainly for servers/firewalling/... might well do
   without KDE or some number-crunching application.

b) Provide the possibility to have a "stable-plus-tier-2-patches" branch
   in the archive, with a very limited number of source packages that
   are derived from stable with the necessary patches for tier-2 arches.

In the long run, it might be even possible to get along with the stable
sources alone, plus a second, tier-2-specific diff.gz - if I'm not
mistaken it is planned to enable dpkg to work with a more flexible
format for source packages.

If there are such source changes, the porters must rebuild the parts of
the archive that build-depend on the changed packages, guaranteeing the
consistency of the release.  But this won't be a very harsh requirement,
since most of the arch-specific RC bugs are FTBFS, anyway.


Regards, Frank


-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Reply via email to