[DE] techn Machbarkeit von aptode-sideb - Bitte nicht stören

[se7en11]

[ralul]

schön wäre z.b. wen der Installer für /home eine eigene Partition anlegen würde
...
Ich denke das ist eher machbar als (sorglos) zu jeder Zeit zu gewährleisten.

So sehe ich es auch. Auf das von DonKult vorgebrachte LVM Argument gehe ich aus folgenden Gründen nicht ein:

- Btrfs wird sehr bald LVM vollkommen erledigen.
- /home als extra Partition reicht zur Verschlüsselung aus, weil es mit Hilfe von /run und seinen tmpfs Möglichkeiten genügend Schutz gibt runtime Daten zu verbergen.

Spezialisten mit besonderen LVM und Raid Ambitionen sind keine "easy" Debian sid Kandidaten.

[se7en11]

installer der /home verschlüsselt fällt mir da noch auf Anhieb ein ... falls das nicht als Störung angesehen wird.
Ich weiß auch das das kein 100 % Schutz ist aber wäre trotzdem etwas wo Interesse bestehen könnte. Ubuntu macht das automatisch.

[holgerw]

Hallo Ralph,

@Steve,
@Se7en11
eure Beiträge sind Meinungsäußerung. Ihr wiederholt das allgemein übliche Urteil über Debian sid, dass es nicht geht. Dieses Urteil kenne ich, also hier:

Bitte nicht stören

Das heißt also in Anlehnung an die Signatur von @se7en11:
Die Tatsachen stehen fest, bitte stört mich nicht mit Euren Meinungen ;-)

Mal ernsthaft gesagt bin ich ja immer noch dafür zu haben, das Werkzeug YaST an ein Debianderivat anzupassen. Bitte nicht schlagen, aber ich finde, YaST ist richtig gut geworden.

Falls das nicht hier zum Beitrag technische Machbarkeit passt, dann sagt es mir, ich verschiebe meinen Kommentar dann nach Freie Rede.

Viele Grüße,
  Holger

[ralul]

Hier wollte ich _nur_ mein Projekt "easy" Debian sid auf technische Machbarkeit von problemlosen DUs hin diskutieren.

Die Diskussion über eine neue Distro hatte angefangen:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=1136

Es werden Namen diskutiert:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=1185

[holgerw]

Hier wollte ich _nur_ mein Projekt "easy" Debian sid auf technische Machbarkeit von problemlosen DUs hin diskutieren.

Die Diskussion über eine neue Distro hatte angefangen:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=1136

Es werden Namen diskutiert:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=1185

Hallo Ralph,

wenn Du hier nur Fragen zu anwendefreundlicher Aktualisierung diskutieren möchtest, dann passt der YaST Beitrag nicht. Ich werde ihn später wo anders unterbringen.

Viele Grüße,
  Holger

[Nex]

Hi,

ist es nicht möglich für "easy" Debian sid ein eigenes upgrade Skript zu basteln, das erstmal eine Liste von auf "hold" zu setzende Pakete holt, diese Pakete auf "hold" setzt und danach erst das apt-get dist-upgrade ausführt? Diese Liste müsste dann quasi von den "Frontschweinen" gepflegt werden.

cu

[DonKult]

Ich merke schon, auch an der Frage von devil, ich muss es erstmal selbst mindestens beispielhaft implementieren, um Anhänger für die Idee zu finden. Wie es immer bei openSource ist, dass man nur interessieren kann, wenn man konkret etwas vorweist, und nicht nur drüber redet - DoKratie.

Tue das, dann siehst du nämlich, dass das…

Ich bezieh mich nicht auf testing, aber vom Prinzip dachte ich es sollte so funktionieren:

/etc/apt/sources.list

Code: [Select]

deb  http://ftp.de.debian.org/debian/ unstable main contrib non-free
deb http://ftp.aptode.org/debian/ aptode main fix easyetc/apt/preferences

Code: [Select]

Package: *
Pin: release a=unstable
Pin-Priority: 501
Package: *
Pin: release a=aptode
Pin-Priority: 502Die Metapakete für "easy" Debian Benutzer werden aus dem Verzeichnis easy gezogen, und sind durch die erhöhte Priorität (502) geschützt? Ginge mein Plan besser mit beiden Prioritäten über tausend?

… nicht funktioniert selbst wenn du sie auf eine Millarde hochsetzt. Die Priority bestimmt nur welche Version zur Installation/Upgrade verwendet wird. Nicht ob ein Paket installiert wird (mit teilweiser Ausnahme vom negativen Pin) und beschützen vor dem entfernen tut das schon gar nicht.


@Nex: So ein Script gibt es schon. Es nennt sich smxi und untersützt sicherlich auch bald eMails (Zawinski's Law: "Every program attempts to expand until it can read mail."). Abgesehen vom Endpunkt für so ein Script ist das Problem daran ganz klar die reine Vorspiegelung von Sicherheit durch einen Blackliste - und wäre damit das umgekehrte von ralul der eine Whiteliste vorschlägt - da niemand eine solche Liste maintainen kann ohne das nicht ab und an jemand über die Klippe springt. Genau wie hier jetzt auch mit den Upgrade-Warnungen: Erst muss wer auf die Nase fallen bevor man von dem Fehler weiß.

Stell dir einen Spamfilter vor: Mit einer Blackliste wirst du immer wieder mal Spam bekommen bis du den jeweiligen Absender eingetragen und so blockiert hast. Mit einer Whiteliste wirst du erst Mails bekommen wenn du den Absender eingetragen hast. Beides skaliert kein Stück in einem Archive von mehr als 30.000 Paketen das ständig von anderen mit neuen Versionen gefüttert wird, die sich überhaupt nicht um deine Listen scheren… Willst du also abundan kaputte Pakete weil noch nicht eingetragen oder aber keine (installierbaren) Pakete weil sie nicht freigeschaltet sind - "pick your poison".

@holgerw: Ohne näheres darüber zu wissen: http://yast4debian.alioth.debian.org/

[agaida]

Idee - So ein Expose schreibt man z.B. auf einer Wiki-Seite - da kann dann auf der zugehörigen Diskussionsseite ein Austausch geführt werden. Hat den Vorteil, dass man erledigte Dinge auch einfach mal "erledigen" kann und der Entwurf an sich sauber bleibt. Wenn es dann wirklich richtig Bedarf an einer Diskussion über einzelne Punkte gibt, passen die auch wieder in ein Forum.  

Ist aber nur so ein Gedanke.

[ralul]

@agaida, die Idee nur Metapakete zu nehmen wird von unserem Fachmann verneint. Wir müssen also wenn dann doch ein halbes Repo kopieren.

Bisher dachte ich in meiner Vorannahme, dass Debian das perfekte Paketsystem hat. Jetzt merke ich, dass Gentoo viel besser ist: Allerdings so gut, dass es schon eine richtige Mühe sein kann für einen Gentoo~unstable Benutzer die ganzen "blockings" zu lösen, die durch Abhängigkeiten auf Pakete von "world" / gewollte Pakete entstehen. Da ich rot markierte Blockings auch von Debians aptitude kenne, dachte ich, ich könnte diesen Mechanismus mittels Metapaketen benutzen.

Mich wundert es schon, dass es keine symptomatischen Errorlevel für ein

apt-get dist-upgrade --simulate

geben soll, wenn Abhängigkeiten nicht erfüllt werden.

[reddark]

Ohne jetzt groß alles gelesen zuhaben .. den yast-gedanken von holgerw finde ich auch nicht schlecht. Hab ja damals mit suse (hmm,vergessen 5 oder6) angefangen und fand yast nie doof. Nur das das ganze system zu sehr aufgebläht wurde .. hat mich irgendwann zu redhat, dann ubuntu und seid chaos hierher geführt. Wenn es da möglichkeiten gibt, sollte mensch zumindest mal drüber nachdenken .... <--- meine meinung

edit: in der nachlese .... falscher thread .. hab grad burzeltag --- sehts mir nach (nich ganz nüchtern)

[Nex]

@Nex: So ein Script gibt es schon. Es nennt sich smxi und untersützt sicherlich auch bald eMails (Zawinski's Law: "Every program attempts to expand until it can read mail."). Abgesehen vom Endpunkt für so ein Script ist das Problem daran ganz klar die reine Vorspiegelung von Sicherheit durch einen Blackliste - und wäre damit das umgekehrte von ralul der eine Whiteliste vorschlägt - da niemand eine solche Liste maintainen kann ohne das nicht ab und an jemand über die Klippe springt. Genau wie hier jetzt auch mit den Upgrade-Warnungen: Erst muss wer auf die Nase fallen bevor man von dem Fehler weiß.

Das Skript kenne ich sogar, habe es eine Zeitlang unter Sidux, bevor es geächtet wurde, genutzt. Aber war/ist es nicht so, dass dieses Skript von nur einer einzigen Person verwaltet wird? Das wäre hier ja anders, da es mehr als ein "Frontschwein" gibt. Zudem kann man smxi ja für alles mögliche inklusive Kaffeekochen benutzen, was es natürlich aufbläht und auch anfällig für Fehler macht. So, wie ich es mir vorstelle (ohne wirklich Ahnung der Machbarkeit zu haben), gäbe es wirklich nur die Blacklist. Und eigentlich denke ich, könnte das auch funktionieren, denn wenn man sich die Threads im "Upgrade Warnings" anschaut, posten zu einem sehr großen Teil immer die gleichen Leute von wirklich gravierenden Fehlern.

cu

[holgerw]

Hallo David,

@holgerw: Ohne näheres darüber zu wissen: http://yast4debian.alioth.debian.org/

danke für den Hinweis, die Ernüchterung, die auf der Seite zu finden ist, lautet:

IRC: last meeting on 20050424 on #debian-desktop

Das Interesse ist wohl mittlerweile nicht mehr vorhanden, schade.

Viele Grüße,
  Holger

[holgerw]

Das Skript kenne ich sogar, habe es eine Zeitlang unter Sidux, bevor es geächtet wurde, genutzt. Aber war/ist es nicht so, dass dieses Skript von nur einer einzigen Person verwaltet wird? Das wäre hier ja anders, da es mehr als ein "Frontschwein" gibt. Zudem kann man smxi ja für alles mögliche inklusive Kaffeekochen benutzen, was es natürlich aufbläht und auch anfällig für Fehler macht. So, wie ich es mir vorstelle (ohne wirklich Ahnung der Machbarkeit zu haben), gäbe es wirklich nur die Blacklist. Und eigentlich denke ich, könnte das auch funktionieren, denn wenn man sich die Threads im "Upgrade Warnings" anschaut, posten zu einem sehr großen Teil immer die gleichen Leute von wirklich gravierenden Fehlern.

cu

Hallo,

die Schwierigkeit von smxi liegt in der großen Dynamik beim Zweig Debian Sid, bei Testing ist es vielleicht gar nicht so schlecht.

Stell Dir vor, an einem Tag sind zahlreiche Paketbetreuer seher motiviert beim Bauen und Hochladen nach Sid, und dann bedenke, dass die Hauptserver von Debian vier mal pro Tag synchronisiert werden. Und dann noch, dass die Nutzer hier unterschiedliche Repositorien-Server in ihrer sources.list drin stehen haben, die unterschiedlich rasch mit neuen Paketen versorgt werden.

Da können auch 100 Leute an einem smxi arbeiten, der Schuss ginge häufig nach hinten los.

Wir können es doch schon hier beobachten. @Devil postet zum Beispiel eine Upgrade-Warnung, gibt dann zwei Tage später Entwarnung, während andere Nutzer aufgrund anderer Repo-Server noch von dem gleichen Fehler berichten.

Viele Grüße,
  Holger