Re: Mischen von testing und stable
Hallo,
Ich habe auf meinem Desktop System ursprünglich woody installiert.
Inzwischen habe ich jedoch auch etliche packages aus testing und unstable
installiert. Wenn man das macht, kommt man um eine neuere Version von
glibc nicht herum. Dennoch funktioniert mein System (bis auf manche
Probleme mit packages aus unstable) relativ stabil. Auch woody packages
funktionieren problemlos, wenn man eine neuere Version von glibc
installiert hat. Dieses Vorgehen bringt gegenüber einem testing System
einige Vorteile. Bei nahezu allen packages ist die Version aus woody
ausreichend. Daher bekommt man Sicherheitsupdates vom Security Team.
Dennoch kann man einige aktuelle packages nutzen. unstable ist für
Produktionsserver jedoch wirklich nicht zu empfehlen. Da bei testing
wesentlich mehr updates als bei stable installiert werden müssen, ist es
bei 120 Systemen empfehlenswert, entweder einen lokalen Debian Mirror oder
einen Proxy einzurichten.
Gruß
Wolfgang
On Mon, 14 Jul 2003 15:40:10 +0200, Markus Gürtler wrote:
> Hallo,
>
> ich habe eine Frage bzgl. dem Mischen von verschiedenen Debian
> Install-Trees, im Speziellen "stable" und "testing". Meine Firma betreibt
> eine Serverfarm unter Debian (ca. 120 Büchsen) welche einige recht aktuelle
> Softwarepakete benötigt, z. B. Apache, Tomcat, Postfix. Das Problem hierbei
> ist, dass die Applikationen in der "stable"-Distribution teilweise zu alt
> sind. Komplett auf "testing" möchte ich aber auch nicht umsteigen, da
> ansonsten zu häufig, zu viele (teilw. kritische) Updates anstehen. Gerade in
> Produktionsumgebungen eine gefährliche Sache. Wenn man jetzt alle
> Applikationen manuell installiert, hat man das Problem das man zig
> Dependencies manuell auflösen muß und manchmal sogar Libraries u. ä. mit
> neueren Versionen ersetzt werden müssen.
>
> Daher stellt sich für mich die Frage, ob ich "stable" vorsichtig mit
> "testing" mischen sollte. Hat jemand hiermit schon Erfahrungen gesammelt?
> Gefährdet das in der Praxis die Systemstabilität. (Ich achte z. B. darauf,
> möglichst keine neue glibc, etc. zu installieren. An den testing-Coreutils
> kommt man wohl aber nicht herum...)
>
> Grüsse,
>
> Markus
Reply to: