staging.inyokaproject.org

Zu Baustelle/Entwicklungsversion: "Unstable" ist für Ubuntu-Entwicklungsversionen eigentlich nicht üblich, man spricht da eher von "Development release", Unstable kommt aus der Debian-Welt. Vielleicht sollte man einmal in der Einleitung den "Development release" erwähnen und dann nur noch "Entwicklungsversion" schreiben.

barcc schrieb:

Sollte man nicht die ganzen Lucid-Links durch Maverick ersetzen?

Done!

UbuntuFlo schrieb:

Jo, da muss ich (oder Ihr) nochmal ran…

Ich fände es sicher nicht übel wen du dir, zusammen mit dem Team, einen schönen und aufschlussreichen text für "Ubuntu-Entwicklung im ubuntuusers-Forum" ausdenkst, und auch entsprechend verlinkst.

barcc schrieb:

Zu Baustelle/Entwicklungsversion: "Unstable" ist für Ubuntu-Entwicklungsversionen eigentlich nicht üblich, man spricht da eher von "Development release", Unstable kommt aus der Debian-Welt. Vielleicht sollte man einmal in der Einleitung den "Development release" erwähnen und dann nur noch "Entwicklungsversion" schreiben.

Ok mach mal, finde das ne sehr gute Idee. Und keine Angst, zurücksetzen geht immer. 😉

@all Ich meine das wir in dem Dokument das Empfehlungen von Vorgehensweisen unterlassen, und anstelle dessen Möglichkeiten auflisten sollte. Das UU.de Wiki Quellt förmlich über vor freundlichen und einfachen Empfehlungen für alle arten von user. Unter Entwicklungsversion/Testing sollter auch für einsteiger klar sein das man mit einer Development release arbeitet, und mit dem Testing auch am Development teilnimmt (teilnehmen sollte). Daher, den Artikel auf Lucid zu belassen mach absolut keinen sinn. Oder will wehr ne Stable testen?

Ich habe Installation Möglichkeit 1 überarbeitet. Wenn keiner Einwände hat, mach ich das mit 2 und 3 später auch noch.

edit: 2+3: done

barcc schrieb:

edit: 2+3: done

Ach ne, findest du die Änderung gut. Jetzt hast du nur noch ein dist-upgrade, was soll das den? Willst du dir die Kiste absichtlich zerschießen oder was? 2a wieder aktiviert.

Bordi schrieb:

Ach ne, findest du die Änderung gut. Jetzt hast du nur noch ein dist-upgrade, was soll das den? Willst du dir die Kiste absichtlich zerschießen oder was? 2a wieder aktiviert.

Ja, meine Änderungen waren gut. Die Option -y ist nicht empfehlenswert und der Abschnitt 2a auch nicht (jetzt sogar noch schlimmer als vorher).

Deshalb empfehle ich, die Version von 28. Mai 2010 21:09 wiederherzustellen.

Erklärung:

Die man-Page von apt-get sagt zur Option -y folgendes:

      -y, --yes, --assume-yes
          Automatisches »Ja« auf Anfragen; Versucht »Ja« auf alle Anfragen zu
          antworten und ohne Eingaben zu laufen. Wenn eine unerwünschte
          Situation eintritt, wie ein gehaltenes Paket zu ändern, ein nicht
          authentifiziert Paket zu installieren oder ein essentielles Paket
          zu entfernen, dann wird apt-get abgebrochen. Konfigurationselement:
          APT::Get::Assume-Yes.

Automatisches Antworten ist nicht sinnvoll bei einer Entwicklungsversion, da bei inkonsistenten Archivzuständen apt-get mit dem Kommando dist-upgrade versucht Probleme zu lösen, indem Pakete deinstalliert werden (zwar keine essentiellen, aber möglicherweise doch wichtige). Es ist also wichtig, dass die Abfrage erhalten bleibt und der Tester die Möglichkeit hat den Vorgang abzubrechen. Die Option -y ist nur nützlich für Skripte wie pbuilder die ohne Benutzerinteraktion auskommen müssen und in einer kontrollierten Umgebung ablaufen.

Zum Abschnitt 2a: Das Testen einer Entwicklungsversion erfordert immer Handarbeit. Dazu gehört, dass wenn man einen Befehl ausführt, die Ausgabe liest und wenn Fehler oder Probleme auftreten, man diese erst löst bevor man den nächsten Schritt macht (auf jeden Fall vor dem Reboot). Deshalb ist die Verkettung mit && in diesem Fall keine gute Idee. Außerdem sind die verwendeten Befehle teilweise unnötig, teilweise können sie zu Fehlern führen (z.B. --fix-missing -yf).

Bei komplizierten Themen wie Entwicklungsversionen und Testing sollte man sich im Wiki an Vorgehensweisen orientieren, die Ubuntu-Entwickler empfehlen oder selbst verwenden. Jedenfalls gibt es dort keine Hinweise auf die Verwendung von -y oder von Bandwurmbefehlen.

auch in einem Artikel für die Entwicklungsversion sollten nur die von Canonical empfohlenen Methoden zum Upgrade stehen; eine Änderung der sources.list wird nicht empfohlen!

Auf dieser Seite steht unter The Debian way of upgrading:

Please be aware that this method is valid, yet not officially advised by the Ubuntu developers.

Aus diesem Grund hatte ich Methode 2 drin gelassen und Methode 1 mit bevorzugt markiert. Man kann ja noch dazu schreiben "nicht offiziell empfohlen". Das mit dem Bearbeiten der sources.list ist halt weit verbreitet und sollte deshalb erwähnt werden mit der Erklärung, warum es eben nicht die bevorzugte Methode ist.

Auf jeden Fall besser entfernen als so wie jetzt.

barcc schrieb:

Das mit dem Bearbeiten der sources.list ist halt weit verbreitet und sollte deshalb erwähnt werden mit der Erklärung, warum es eben nicht die bevorzugte Methode ist.

man muss aber nicht durch Erwähnung der Methode im Wiki für weitere Verbreitung sorgen.

Eine entsprechende Erklärung warum es nicht die bevorzugte Methode ist sollte dann zumindest ausführlicher sein.

barcc schrieb:

Zum Abschnitt 2a: Das Testen einer Entwicklungsversion erfordert immer Handarbeit. Dazu gehört, dass wenn man einen Befehl ausführt, die Ausgabe liest und wenn Fehler oder Probleme auftreten, man diese erst löst bevor man den nächsten Schritt macht (auf jeden Fall vor dem Reboot). Deshalb ist die Verkettung mit && in diesem Fall keine gute Idee. Außerdem sind die verwendeten Befehle teilweise unnötig, teilweise können sie zu Fehlern führen (z.B. --fix-missing -yf).

Tja da magst du in der tat zumindest teilweise recht haben. Das ändert aber nichts an der Tatsache das diese eine Zeile jene ist, die -genau so wie sie jetzt da steht- in den ganzen Jahren immer funktioniert hat ohne Probleme zu verursachen. Mir teilweise förmlich den Arsch gerettet hat. Alle anderen Update und Upgrade verfahren, die eingentlich besser sein sollten, haben irgend wann den geist aufgegeben, oder sind selbst zum Problem mutiert. Am häufigsten update-manager. Zudem weiss nicht gleich jeder der zu Testewn anffängt, gleich zu beginn das man befehle auch verketten kann, oder das apt-get neben dem update, auch noch andere nützliche Funktionen wie das --fix-missing -yf auf lager hat. Deswegen bin ich auch der Meinung das dies da so stehen bleiben muss, und noch einiges hinzugefügt werden muss. Beispiele dafür währen...

• Ubuntero Status als Gunvoraussetzung für's Testing

• Wie schriebe ich eine Bugreport

• Wo sind die Log's

• Virtualisierungslösungen

• Testing für Anfänger: Der Umgang mit checkbox-gtk

Hallo, wie sieht's mit diesem Artikel aus? Ist der fertig oder wird da noch dran gewerkelt? Gruss

Letzters ☺

Allerdings zurzeit eher auf Sparflamme wegen zu viel zu tun ☹

Flo

Nach der Entwicklung ist vor der Entwicklung. So richtig abgeschlossen wird der Artikel nie sein. Könnte meiner Meinung nach schon langsam aus der raus. Baustelle/Entwicklungsversion/Testing sollte aber noch zurückbehalten werden.

Mosche Jungs!

Ich habe noch Diverses umgesetzt, neu geschrieben, ergänzt usw.

Von meiner Seite ist Baustelle/Entwicklungsversion fertig und kann aus der Baustelle raus.

Baustelle/Entwicklungsversion/Testing ist noch unfertig.

Liebe Grüße,

Flo

Hallo,

bis auf den inflationären Gebrauch von kursiv ist es IMHO ok.

Die Sätze mit Hinweisen auf "Entwicklungsversion/Testing" habe ich auskommentiert, damit keine Deadlinks im Artikel sind. Wenn der andere Artikel fertig ist müssen die weiter aus-auskommentiert werden.

Der Artikel ist wieder im Wiki Entwicklungsversion.

Gruß, noisefloor

So, was soll man auch sonst an einem sonnigen Sonntag machen, als seine Zeit dem Wiki zu widmen 😉

Gut, dass uns heute eine Stunden geschenkt wurde: Ich habe Baustelle/Entwicklungsversion/Testing nun nochmal komplett überarbeitet. Meinerseits ist der soweit feddich.

Auch Entwicklungsversion bekam noch einige kleinere Änderungen verpasst.

Liebe Grüße,

Flo