[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits (Nybbles?) from the Vancouver release team meeting

On Mon, Mar 14, 2005 at 06:20:23PM +0100, Goswin von Brederlow wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
> > I don't really understand that point though, since the plan is to drop mirror
> > support for all minor arches, what does it cost to have a 3 level archive
> > support : 
> >
> >   1) tier 1 arches, fully mirrored and released.
> One full set of sources, 10G.
> >   2) tier 2 arches, mostly those that we are dropping, maybe mirrored from
> >   scc.debian.org in a secondary mirror network. (why not ftp.debian.org/scc
> >   though ?).
> Second set of identical sources, +10G == 20G.
> >   3) tier 3 arches, or in development arches, available on
> >   ftp.debian.org/in-devel or something.
> Third set of identical sources, +10G == 30G.

Ah, no, nothing is stopping us from keeping the pool architecture for this,
just having different views of the stuff for different mirror networks to work

> Only if all 3 are on the same server can the sources be hardlinked and
> getting those hardlinks preserved to mirrors is tricky.

Well, it just calls for smarther mirroring tricks.

Also, i do believe that not all mirrors carry experimental for example, and
said packages are in the pool all the same, or whatever.

> > I don't see how having the in-devel arches be hosted on alioth
> > instead on the official debian ftp server would cause a problem.
> >
> > Also, i don't understand why scc.debian.org is better than ftp.debian.org/scc,
> > really, ideally we could have /debian, /debian-scc, and /debian-devel or
> > something such. Is it really a physical problem fro ftp-master to held all
> > these roles ? What is it exactly that ftp-masters want to drop all these
> > arches for ? 
> >
> > Mirrors could then chose to go with 1) only (most of them will), or also
> > mirror 2) and/or 3).
> Why not just /debian as we have now. That means all sources are in
> debian/pool/ just once. And mirrors can choose to exclude archs from
> the mirrors as many (non primary) mirrors already do. The know-how for
> partial mirrors is there and nothing needs to be invented for it.

Yeah, that would be easiest, i was speaking about a logical separation of the
arches, not a physical one.

> I fail to see why the mirror situation should have an (changing)
> impact on the archive layout and I fail to see how splitting the
> archive, and thereby duplicating sources, helps mirrors that want
> more than just i386/ppc/amd64.

Thanks for your input


Sven Luther

Reply to: