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 <firstname.lastname@example.org> 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