Veni, Vidi, VISA

| aptitude wird jetzt apt-get bevorzugt[...]

Ist schon länger so. Aber definitiv kein Muss.

| Dafuer ist es immer noch nicht moeglich, komplette Strukturen
| (KDE, Gnome, Emacs, www-*, ..) vom Update auszuschliessen, [...]

Klar, setz einfach die relevanten Packages auf Hold.

| Aber das einzige was *wirklich* stinkt, ist die Tatsache, dass keine
| neuen Versionen von Programmen nach Stable kommen.

Das ist *deine* Ansicht. Wer mehrere Produktiv-Server zu betreuen hat, Softwarehäuser (die wollen ihre Software nicht täglich auf eine neue libc, $FOO,... aktualisieren), Systemintegratoren (die wollen nicht täglich zig hundert Desktops aktualisieren müssen) oder einfach auch die große Paketauswahl (>18.000 Pakete alleine in Etch) *mit* Security-Support braucht, dem ist das idR recht. (Ach ja, auch der typische Enduser will keine täglichen/wöchentlichen Updates, die leiden idR nämlich nicht unter Featureitis.)

Ich kann heute meine Pakete für Debian/stable zusammenschnüren, diese auch noch mehrere Monate/Jahre lang auf anderen Systemen einsetzen, weil dort halt nicht auf einmal eine andere lib$FOO vorhanden ist, oder ein Paket mit anderen Flags kompiliert wurde (weil das halt von Upstream so vorgesehen ist). Der Begriff "stabil/stable" betrifft *nicht* die Stabilität von der Software, sondern der Paketauswahl/des Paketmanagements. Wem das nicht klar ist oder wem das nicht schmeckt der soll halt Debian meiden. *Ich* schätze exakt das. Weil ich genau weiss, was mich auf einem fremden Server den ich übernehmen/warten/richten muss bei einem Debian/stable erwartet. Genau so wie die Installation eines Debian/stable-Systems. Ebenso das Upgrade von einer stable auf die Nachfolger-Release. Ich muss das auch nicht in einem unbekannten Zyklus, sondern kann das mit einem ganz klarem Upgrade-Pfad durchziehen.

| AsciiDoc ist in Version 7.1.2 vorhanden; die ist von 2006-03-07!

Ich garantiere dir, dass backports.org in Kürze ein aktuelleres asciidoc liefern wird.

mfg,
-mika-

| Das aptitude gegenueber apt-get bevorzugt wird, halte ich fuer sinnvoll. War also ein "Endlich steht das auch im Release!".

Das war schon bei Sarge der Fall.

| Ich rede nicht von einzelnen Paketen, sondern von "kompletten Verzeichnissen".

% for i in `dpkg --get-selections| awk '/^zsh/ {print $1}'`; echo $i hold | dpkg --set-selections

| IIRC werden die Informationen dazu so und so heruntergeladen; nur die Aktualisierungen der Pakete auf dem System wird unterbunden.

Nope.

| Urban legend. Ich arbeite als Freiberufler und hatte schon mit einigen grossen Unternehmen (>=1000 Hosts) zu tun, die sich aus exakt diesem Grund strikt gegen Debian ausgesprochen haben.

Welche Distribution(en) wurden dann genommen?

| Auf anderen Distributionen stehen Updates zur Verfuegung; das bedeutet aber nicht das man diese zwingend einspielen muss.

Und du schaust dir für z.B. 1000 installierte Pakete an, was du aktualisierst und was nicht? Oh, und dann bringt ein Update von einem Paket sowohl Feature- als auch Security-Update(s) - dann bin ich ja gespannt was du dann machst, wenn du das Feature-Update davon nicht haben willst. Da bevorzuge ich das reine Security-Update bei Debian, wenn ich wirklich ein Feature-Update machen will, mach ich halt selbst einen Backport (oder gehe im Radikalfall halt Richtung Testing/Unstable und zieh mir meinen eigenen Paketpool dazwischen ein).

| Es dauerte ~14 Monate bis ich mit sed(1) unter Debian das "Feature" "-i.foo" nutzen konnte.

Und? Das kannst du heute noch nicht auf einem Solaris. Die Welt ist nicht homogen und du bekommst auf keinem einzigen System all die Features die du kennst und/oder haben willst.

| Software entwickelt sich weiter; wenn ich eine Distribution habe, bei der ich auf ein neues Release warten muss, bis neue Software verfuegbar ist, dann hat das nichts mit "Featureitis" zu tun. Fakt ist das es kein Problem darstellt, z. B. neue Versionen des GNU Programm - Pools einzubinden, da diese komplett abwaertskompatibel sind.

Muhaha, gerade GNU als Beispiel anführen.... Es *gibt* Pakete für die es auch in Stable Aktualisierungen gibt (=>Volatile), das sind aber Pakete die einfach vom Design her dynamisch sind (Virenscanner-Signaturen z.B.) und die dir auf keinen Fall deinen Core angreifen.

| Mit welchem Paketmanagemensystem funktioniert das nicht? Eine statisch gelinkte Executable erstellen und dann spielt das ziemlich exakt gar keine Rolle auf welcher Version von $DISTRI ich das einspiele (gleiche Architektur und Distribution vorausgesetzt).

Dann hast du z.B. in einer lib gegen die du gelinkt hast ein Security-Update und kannst alle Programme neu kompilieren gehen. Und fürs Verteilen will man es sowieso in Pakete stecken, da hast du die Dependencies auch korrekt drin und brauchst keine Angst vor menschlichen Fehlern haben.

Du hast aber nicht meinen Punkt getroffen, mir geht es nicht um den Paketmanagement-Mechanismus (welcher das im Endeffekt ist, ist irrelevant) sondern darum, dass man seine Pakete eben nicht im Wochentakt an irgendwelche Aktualisierungen anpassen muss.

|| Ich muss das auch nicht in einem unbekannten Zyklus, [..]

| Wie meinen? Ich hatte (mal abgesehen von Suse =< 7.0) noch bei keinem Update auf ein neueres Release ein Problem.

Gentoo z.B. hat keine Pointreleases.

|| Ich garantiere dir, dass backports.org in Kürze ein aktuelleres asciidoc liefern wird.

| Moeglich. Es ist aber alles andere als Benutzerfreundlich, einen Admin dazu zu zwingen, "optionale" Software zu installieren, damit er Usern aktuelle Versionen anbieten kann.

Ein Admin muss die Umgebung sowieso auf die Benutzer abstimmen, und Backports.org ist eine bekannte und gut gewartete Ressource, die einfach in Betrieb zu nehmen ist.

mfg,
-mika-