Re: When will amd64 join sid?
Mattias Wadenstein <maswan@acc.umu.se> writes:
> On Sat, 22 May 2004, Goswin von Brederlow wrote:
>
>> Michael Banck <mbanck@debian.org> writes:
>>
>> > On Sat, May 22, 2004 at 12:59:41AM +0200, Frederik Schueler wrote:
>> >> Why should we not go into sid within the next days? what is keeping us
>> >> out of it?
>> >
>> > Well, the mirrors are getting restructered to allow for less-than-all
>> > architectures to be mirrored. Then, consensus seemed to be that amd64
>>
>> Who says so? Who is working on that? What has still to be done?
>
> Well, ftp-master, ftp-master, sarge being released are my semi-informed
> guesses. I don't think there is going to be any restructuring until after
> sarge release, and there is a hold on new arches until that happens.
The Debian mirror structure is dists/<suite>/main/source/Sources and
dists/<suite>/main/[debian-installer/]binary-<arch>/Packages and then
all the files those refernce.
The actual position of the debs and source files can be changed
without impact to any software in debian. This could even be done on
an arch by arch basis.
E.g. amd64 packages could go into pool-amd64 (or whatever the
restructured way is) without changing the rest.
What is to be restructured? How will it look like? Details please.
>> I also, without further details, see this argument as pure
>> rubish. There are many less-than-all architectures mirrors in
>> existance so this is nothing new and nothing that needs to be invented
>> first. So whats realy going on?
>
> Having actually sat down and discussed this with the ftpmasters, no, this
> argument isn't rubbish. Every arch/gig added is a bigger strain on mirrors
> and leads to mirrors dropping either debian or other valuable community
> resources. I'll ask around a little and see what the current consensus is
> wearing my mirror admin hat.
Then please do ask the ftpmasters if you can make the discussion
public. Discussing those things behind closed doors only is contrary
to Debians openness and very frustrating to the people left in the
dark.
The argument that we need partial mirroring, which is done all over
the place already, still looks like pure rubish, since it is done all
over the place already. I'm not saying that a size increase doesn't
matter but that using something that is already solved lots of times
as excuse looks bad. There must be other reasons, other problems,
other plans. DETAILS please.
There is also discussion about changes to the Debian archive structure
neccessary for a well functioning multiarch support. As you know, the
problem is the split of every library into arch dependent and arch
independent data and the drastic increase in -all packages with
versioned depends on them. Those arch all packages should be tracked
seperatly per arch. The problem already exists for years but the
increase in all package would make it a constant problem (instead of
just temporary like now).
How does that figure into the plans for the new archive structure? Has
that been considered? Will we need to restructure the archive again
just after it hass been restructured because the structure was decided
behind closed doors?
Maybe with your mirror admin hat you can get some more details out of
ftpmasters and enlighten us. :)
> It might be possible that debian-amd64 gets an exception to this, given
> that we have a well-managed port that is up to date and there is big
> public demand for it. But I wouldn't bet on it.
>
> /Mattias Wadenstein
As it has been suggested before there are several archs less important
than amd64. Arches with a smaller userbase don't need to be mirrored
as widely. For example m68k (since I use that myself) could be droped
from all but one mirror per continent.
With amd64 getting installable just like any release candidate the
userbase will increase drastically and alioth will be flooded with
traffic. Don't forget that.
MfG
Goswin
Reply to: