Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
Sven Luther <sven.luther@wanadoo.fr> writes:
> On Tue, Aug 26, 2003 at 11:17:48AM +0200, Goswin von Brederlow wrote:
> > Sven Luther <sven.luther@wanadoo.fr> writes:
> >
> > > On Mon, Aug 25, 2003 at 07:42:13PM +0100, Mark Howard wrote: > Hello,
> > > If we don't rebuild every dependant package in the experimental pool,
> > > we need then to have a way to eventually retrigger the build of every
> > > dependant package once it reaches unstable.
> >
> > Binaries from experimental should not move into sid but be rebuild for
> > it. That can happen automatically by the buildds if source-only
> > uploads could be handled. Move the source to sid killing all binaries
> > and let the autobuilder crunch away.
>
> Well, but you need to build all the dependant packages (and use them) to
> catch bugs caused by it.
Only those contained in the sections enabled on the users system. If
you have experimental-core and experimental-gnome all gnome debs
should be comnpiled against the experimental glibc for example.
Having all combinations on the mirrors would overflow them.
> > > That said, ideally all packages would be rebuilt in the experimental
> > > pool with in an automatic triggered way and then only can the library
> > > component migrate to unstable, in the same way as stuff migrate from
> > > unstable to testing in this way.
> > >
> > > Special care would need to be taken for uploads of new stuff when one of
> > > the library pools is waiting to move to unstable.
> >
> > Maybe experimental could be a source only section with a proper
> > build-experimental package thats preconfigured to build on a local
> > maschine and install.
>
> No, you loose the benefit of the autobuilder, and would result in
> experimenting only on x86 this way.
Some base set, like experimental-core + experimental-<section this is
in>, could be autobuild and any other combinations build on the
clients side.
MfG
Goswin
Reply to: