Re: Debian GNU/Linux 3.1r0 released (!?)
Andreas Barth wrote:
> * Sven Hartge (hartge@ds9.gnuu.de) [050608 11:05]:
>
>>Um 10:33 Uhr am 08.06.05 schrieb Andreas Barth:
>>
>>
>>>Nicht mirror-Platz, sondern für einige der Mirror ist die Größe des
>>>täglichen rsync-Pushes zu groß.
>
>
>>Warum schließt man solche Mirror dann nicht aus?
>
>
> Es gibt Länder, wo Traffic _teuer_ ist. Und gar keinen Mirror mehr zu
> haben wäre deutlich schlechter.
Wenn man, wie Sven sagt, die Mirrors ausschließt, wieso erhöht sich für
die dann der Traffic?
Aus ftp://ftp.debian.org/debian/README.mirrors.html:
"A secondary mirror site may have restrictions on what they mirror (due
to space restrictions). Just because a site is secondary doesn't
necessarily mean it'll be any slower or less up to date than a primary
site."
Da steht doch eindeutig da, dass man nicht alles spiegeln muss (und
tatsächlich gibt es eine Reihe von Mirrors, die das nicht machen).
Demzufolge müsste der "rsync-Push" doch dann auch klein genug sein für
solche Mirrors, oder?
Gibt es eine Liste der Mirror, für die die Aufnahme von AMD64
problematisch wäre?
>>Warum muss jeder Mirror alles führen?
>
>
> Genau das wird sich jetzt ändern. Mit SCC muß ein Mirror nur noch
> zwingend amd64, i386 und powerpc haben, alles andere ist optional.
Wenn die README oben stimmt, dann gibt es bereits jetzt Mirrors, die nur
i386 spiegeln.
> (Und es ist auch ganz klar, das ich mit dem Ablauf und dem Ergebnis
> nicht wirklich zufrieden bin. Ich hätte gerne amd64 in sarge gesehen.
> Aber - es ist nicht so, das es keine Gründe gibt. Über die Gewichtung
> der Gründe kann man natürlich verschiedener Meinung sein.)
Weder das Ergebnis noch die Gründe sind überzeugend. Stimmt es
tatsächlich, dass AMD64 auch bei keinem der nächsten Point-Releases mit
aufgenommen wird? Falls ja, dann legt das für AMD64-Nutzer ziemlich nahe
eine Distribution zu verwenden, bei der AMD64 offiziell unterstützt
wird. Demzufolge ist das auch ein Verstoß gegen den Social Contract.
Jens
Reply to: