Archiv verlassen und diese Seite im Standarddesign anzeigen : Ist Arch-Linux buggy?
Hallo
Den Eindruck habe ich bekommen, nachdem schon einige male nach einem Pacman -Syu bestimmt Dinge nicht mehr gingen.
z.B. habe ich gerade festgetellt, daß Amarok nicht mehr startet, nachdem ich gestern bereits festgestellt hatte, daß kein Sound mehr geht. usw. usw.
Oder ist das der Preis den man bezahlen muß für ein so aktuelles System (immer neuste Pakete)?
ja arch ist noch buggy. Sagt auch version 0.x schon. Vor 1.0 darf man keinen stabilen Bertrieb aerwarten da ist noch bastelphase. Zur Zeit ist Arch also quasi "testing"
Manches klappt manches nicht.
ActionNews
2005-04-07, 12:41:43
Also eigentlich ging es bei mir bisher zimlich gut. Allerdings seit neuesten wird bei mit beim booten dei rc.local nicht mehr richtig ausgeführt, doass ich die Nach dem booten als root noch mal starten muss (starte damit z.B. meine speziellen AVM-Treiber).
CU ActionNews
bei mir ging manches schief. gut ich gehöre noch nicht lange zu den linuxern. dürfte imho aber trotzdem nicht sein, daß nach einem pacman -Syu manchmal die böse überraschung wartet.
daher bin ich am überlegen vielleicht zu (k)ubuntu zu wechseln oder das "ähnlich" slackware zu testen. allerdings ist pacman genial.
naja wenn arch mal 1.0 ist, dann wird das sicherlich absolut top!
nggalai
2005-04-07, 14:24:13
Bei Arch ist's immer etwas Glückssache. Arch Linux patcht Pakete nicht (höchstens den Kernel oder ein eigenes Archlinux-Wallpaper für KDE ...), wenn eine Applikation nicht mehr läuft, liegt's zu 99% an einem Upstream-Bug in der Applikation selbst.
Leider rutschen immer wieder mal fehlerhafte Pakete ins Archlinux-System. Die Maintainer testen Sachen bei weitem nicht so ausgiebig wie z.B. bei Debian. Sachen werden schnell eingepflegt und dann schaut die Community, ob's läuft. Aktuelles Beispiel wäre GnuPG, welches schon in der Version 1.9 in extra drin ist, obwohl's von den GPG-Leuten selbst als "unstable development release" angesehen wird.
Manche Leute haben damit selten bis nie Probleme. Mir ist das System auch noch nie "kaputt" gegangen. Aber wer eine "stabile" Distribution will, sollte sich eventuel wirklich nach Alternativen umschauen ... oder halt bei jedem Update nachschaun, WAS denn upgedated wird und ob man updaten will. Ich bin mitlerweile so weit, dass ich praktisch nur noch Pakete mit -2 oder höher im Paketnamen einpflege, wenn mir die Applikation wichtig ist ... -1 hat doch ab und an unangenehme Bugs drin.
MatrixP
2005-04-07, 17:59:46
ja arch ist noch buggy. Sagt auch version 0.x schon. Vor 1.0 darf man keinen stabilen Bertrieb aerwarten da ist noch bastelphase. Zur Zeit ist Arch also quasi "testing"
Manches klappt manches nicht.
Das stimmt so nicht. Die haben halt bei 0.1 angefangen. Aber der Status 0.x sagt nix über stabilität oder testing aus.
Man kann ja auch bei a anfangen und bis z zählen und da wüsste man nie wann es stable is (bei s evtl?).
War auch mal diskussion in der mailing liste. Kannst ja mal danach suchen.
Bei mir läuft arch prima. Hatte nur einmal ein Problem mit eterm, welches aber nach einigen Stunden durch ein neues package behoben wurde.
MatrixP
1.0 ist schon seit ewigkeiten die Nummer für die "gold" bzw. "stable" version.
Ich wage doch arg zu bezweifeln das arch da anders ist O_o
Exxtreme
2005-04-07, 20:02:37
1.0 ist schon seit ewigkeiten die Nummer für die "gold" bzw. "stable" version.
Das ist falsch. ;)
Wenn ein Projekt die Version 1.0 erreicht dann enthält es alle Features und Eigenschaften, die der/die Programmierer von Anfang an geplant haben. Dann ist das Programm quasi "fertig". Das hat nichts mit "stable" etc. zu tun. Ein Programm kann auch in der Version 0.3.54.357 stable sein. Aber eine derartige Nummer zeigt meist, daß der/die Programmierer noch viel einbauen wollen.
nggalai
2005-04-07, 20:09:32
1.0 ist schon seit ewigkeiten die Nummer für die "gold" bzw. "stable" version.
Ich wage doch arg zu bezweifeln das arch da anders ist O_o
Da Arch ein "Rolling-Releases"-System verwendet, sind die Versionsnummern eigentlich egal. Sie könnten's genau so gut à la Gentoo mit einer Nummer basierend auf dem Datum benennen.
Das ist falsch. ;)
Wenn ein Projekt die Version 1.0 erreicht dann enthält es alle Features und Eigenschaften, die der/die Programmierer von Anfang an geplant haben. Dann ist das Programm quasi "fertig". Das hat nichts mit "stable" etc. zu tun. Ein Programm kann auch in der Version 0.3.54.357 stable sein. Aber eine derartige Nummer zeigt meist, daß der/die Programmierer noch viel einbauen wollen.
gold heist fertig O_o
stable heisst auch keine großartigen Änderungen mehr also alles drin was rein sollte.
Wo genau war da jetzt der Fehler?
MatrixP
2005-04-07, 22:37:12
gold heist fertig O_o
stable heisst auch keine großartigen Änderungen mehr also alles drin was rein sollte.
Wo genau war da jetzt der Fehler?
stable heisst stable version.....
gold heisst fertig - bei spielen zumindest ;)
stable kann schon änderungen haben, wenn z.b. eine neue version da ist. bei arch werden meist neue versionen für neue packages genommen.
wo is dein problem? wenn ausreichend neue features im arch-teil der distribution vorhanden sind kommt halt ein neues release raus mit dem entsprechend aktuellen paketen zu diesem zeitpkt. die sind aber alle stable!!!
also kann man nicht wirklich sagen arch ist unstable...
MatrixP
Thujon
2005-04-07, 22:43:56
nope das mit stable stimmt schon. Stable heisst nicht nur das es brauchbar läuft stable heisst auch das es "fertig" ist. Daran ist nichts falsch es weiß nur kaum einer :>
Wenn zum Beispiel noch größere Änderungen anstehen ist etwas noch nicht stable weil es eben noch Verändert wird.
Wenn man mal drüber nachdenkt ist es ansich logisch ;)
Also haut nicht gleichd rauf sondern erstmal selbst informieren =)
€: Denkt auch mal drüber nach warum man bei 1.0 auch sehr sehr oft vom stable release spricht ;) Wird euch sicherlich schon öfter begegnet sein. Achtet mal drauf.
MatrixP
2005-04-07, 22:49:32
nope das mit stable stimmt schon. Stable heisst nicht nur das es brauchbar läuft stable heisst auch das es "fertig" ist. Daran ist nichts falsch es weiß nur kaum einer :>
Wenn zum Beispiel noch größere Änderungen anstehen ist etwas noch nicht stable weil es eben noch Verändert wird.
Wenn man mal drüber nachdenkt ist es ansich logisch ;)
Also haut nicht gleichd rauf sondern erstmal selbst informieren =)
€: Denkt auch mal drüber nach warum man bei 1.0 auch sehr sehr oft vom stable release spricht ;) Wird euch sicherlich schon öfter begegnet sein. Achtet mal drauf.
schau mal in die mailing list von archlinux, da hat der gründer selbst gesagt, dass die 1.0 nix mit stables release zu tun hat. jede einzelne version ist stable an sich...
MatrixP
Thujon
2005-04-07, 22:51:26
Dann stellt Arch eine Ausnahme dar. Er sagte was die Regel ist und das er dran zweifel das Arch es anders macht. Sie tun es zwar aber das ändert immernoch nichts daran das seine Aussagen vollkommen korrekt waren.
Texte zu ende lesen und richtig verstehen kann manchmal helfen ;)
MatrixP
2005-04-07, 23:09:26
Dann stellt Arch eine Ausnahme dar. Er sagte was die Regel ist und das er dran zweifel das Arch es anders macht. Sie tun es zwar aber das ändert immernoch nichts daran das seine Aussagen vollkommen korrekt waren.
Texte zu ende lesen und richtig verstehen kann manchmal helfen ;)
falls du den link in der arch mailing list gefunden hast kannst ihn ja mal posten.. würde es gerne nochmal lesen, hab ihn nämlich net gefunden ;)
MatrixP
Thujon
2005-04-07, 23:14:56
Noe, wozu auch? Das Arch es mit der 1.0 anders nimmt wie der Rest zweifelt hier niemand an. Jetzt wohl jedenfalls nicht mehr.
Es ging darum was der Ausdruck Stable im REGELFALL bedeutet, was schon korrekt wiedergegeben wurde. Ansich ist die Diskussion also eigentlich durch. Also verrate mir bitte:
Was willst du da jetzt mit der Mailingliste?
MatrixP
2005-04-07, 23:17:38
Noe, wozu auch? Das Arch es mit der 1.0 anders nimmt wie der Rest zweifelt hier niemand an. Jetzt wohl jedenfalls nicht mehr.
Es ging darum was der Ausdruck Stable im REGELFALL bedeutet, was schon korrekt weidergegeben wurde. Ansich ist die Diskussion also eigentlich durch. Also varrate mir bitte:
Was willst du da jetzt mit der Mailingliste?
den entsprechenden teil nochmals lesen, damit ich das nächste mal besser vorbereitet bin für eine solche diskussion :D
*g*
MatrixP
Thujon
2005-04-07, 23:20:01
ICh glaube da hättest du eher DIESEN Thread richtig lesen sollen :> Es gibt eigentlich nichts zu diskutieren.
Aber ich gucke grade das archiv durch (mir ist fad)
Thujon
2005-04-07, 23:32:53
hab nicht alles gelesene aber der hier
http://www.archlinux.org/pipermail/arch/2005-January/003289.html
läuft glaub ich drauf hinaus.
Wenn man unter Arch z.B. KDE installiert, dann wird einiges an unnötigem Krempel mitinstalliert. Ich habe gelesen, daß da die Gentooer flexibler sind und die Möglichkeiten haben, nur genau das zu installieren, was gewünscht.
Gibt es da Tricks bei Arch?
z.B. was soll ich mit Noatun wenn ich Amarok nutzen möchte
Thujon
2005-04-08, 15:11:21
kde-libs kde-base ;)
kde-libs kde-base ;)
da wird glaube ich immer noch recht viel unnötiges zeug mitinstalliert. ich glaube die gentooer sind da noch flexibler
Thujon
2005-04-08, 15:16:56
wäre mir neu. Hab auchg ne zeitlang gentoo benutzt da gab es auch nur base und libs
Willst du hier unterschwellig gentoo werbung machen oder mein ich dat nur :>
Nagilum
2005-04-08, 15:30:18
wäre mir neu. Hab auchg ne zeitlang gentoo benutzt da gab es auch nur base und libs
Gentoo kennt mittlerweile auch "Splits", also eine Möglichkeit nur einzelne Pakete zu extrahieren. Z.B. "konqueror" aus der "kdebase". Funktioniert aber wohl auch nur, wenn der Buildapparat des ursprünglichen Programm sowas unterstützt.
Mal ne OT Frage bzgl. Gentoo: Wie zum Geier bringe ich eigentlich Wildcards in der "package.keywords" unter? Also etwas in der Art von "kde-base/* ~x86"
Es kann doch nicht sein, dass man jedes Paket und jede Abhängigkeit einzeln aufführen muss?!
Arcanoxer
2005-04-08, 15:30:28
arch base mit der fluxbox = kein unötiges zeugs. :D
Thujon
2005-04-08, 16:02:19
Gentoo kennt mittlerweile auch "Splits", also eine Möglichkeit nur einzelne Pakete zu extrahieren. Z.B. "konqueror" aus der "kdebase". Funktioniert aber wohl auch nur, wenn der Buildapparat des ursprünglichen Programm sowas unterstützt.
Mal ne OT Frage bzgl. Gentoo: Wie zum Geier bringe ich eigentlich Wildcards in der "package.keywords" unter? Also etwas in der Art von "kde-base/* ~x86"
Es kann doch nicht sein, dass man jedes Paket und jede Abhängigkeit einzeln aufführen muss?!
Benutzt du etwa gentoo O_O
Nich das es schlimm wäre aber es überrascht mich doch einiegermaßen.
Wie kommts?
€ falls wer den einwand net versteht: Nagilum war eigntlich immer gentoo gegenüber etwas negativ eingestellt...
Thujon
2005-04-08, 16:02:58
arch base mit der fluxbox = kein unötiges zeugs. :D
bringt aber auch nur was wenn man fluxbox mag ;>
Duraner
2005-04-08, 17:26:38
Gentoo kennt mittlerweile auch "Splits", also eine Möglichkeit nur einzelne Pakete zu extrahieren. Z.B. "konqueror" aus der "kdebase". Funktioniert aber wohl auch nur, wenn der Buildapparat des ursprünglichen Programm sowas unterstützt.
Mal ne OT Frage bzgl. Gentoo: Wie zum Geier bringe ich eigentlich Wildcards in der "package.keywords" unter? Also etwas in der Art von "kde-base/* ~x86"
Es kann doch nicht sein, dass man jedes Paket und jede Abhängigkeit einzeln aufführen muss?!
ls /usr/portage/kde-base | awk '{ print "kde-base/"$1" ~arch" }' >> /etc/portage/package.keywords
arch durch verwendete Architektur ersetzen, also bei dir x86
Nagilum
2005-04-09, 00:23:53
ls /usr/portage/kde-base | awk '{ print "kde-base/"$1" ~arch" }' >> /etc/portage/package.keywords
Ok. Soweit war ich dann auch. :)
Aber damit erlege ich weder die Abhängigkeiten, noch reagiert die Lösung in Zukunft auf irgendwelche Änderungen in "/kdebase/*". Die müsste ich immer wieder aufs neue, händisch eintragen.
Da muss es doch sinnvollere Lösungen geben?
Duraner
2005-04-09, 13:11:45
Ok. Soweit war ich dann auch. :)
Aber damit erlege ich weder die Abhängigkeiten, noch reagiert die Lösung in Zukunft auf irgendwelche Änderungen in "/kdebase/*". Die müsste ich immer wieder aufs neue, händisch eintragen.
Da muss es doch sinnvollere Lösungen geben?
In Zukunft wird es einfach eine stable Version von den kde split ebuilds geben. ;)
Auch sind Änderungen in der kdebase meist nur bei einem neuem Release von KDE vorhanden. Und auch hierauf dürfte dich emerge --sync&&emerge world aufmerksam machen, wenn du zuvor einmal kdebase-meta emerged und dann musst du nur noch den/die ebuild/-s unmasken und fertig.
Ferner haben die split ebuilds den Sinn, dass man sich selbst nur das notwendige von KDE zulegt. Wenn es nur darum geht kdebase ganz zu haben, tun es die monolithischen ebuilds auch.
Also ich habe keine Probleme mit den Abhängigkeiten, worin besteht hier dein Problem?
Nagilum
2005-04-09, 13:30:04
In Zukunft wird es einfach eine stable Version von den kde split ebuilds geben. ;)
Dolle Lösung. :D
Ich suche ja nur eine einfache Möglichkeit zu sagen "Zieh dir automatisch immer die neueste Version eines Programms. Egal ob Stable oder Unstable". Dazu bräuchte ich halt sowas wie Wildcards in der "package.keywords".
Aber ich hab die Antwort gerade selbst im offiziellen Forum gefunden: Gibts nicht. :(
Was die Abhängigkeiten betrifft: Wenn ich ein Paket mit dem Vermerk "~x86" in die "package.keywords" schmeisse, was passiert dann mit Abhängigkeiten die ebenfalls ein "~x86" voraussetzen? Diese Abhängigkeiten müsste man ja auch alle von Hand eintragen. Oder nicht?
klutob
2005-04-09, 14:01:02
Jupp,
wobei das Anhängen von "~x86" in den Keywords bei einer x86-Architektur nicht notwendig ist.
Ist halt die Frage, ob du eher mit Ausnahmen (die dann von dir per Hand maskiert werden müßten) alles "fresh" haben möchtest, so daß der Tippaufwand für das freischalten der Pakete enorm wird --> (gleich global "~x86" in der make.conf setzen), oder gegenteilig nur ein paar Anwendungen immer Up-to-Date sein sollen --> (package.keywords).
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.