Re: Allgemeine Fragen zum Package System
Frank Terbeck [EMAIL PROTECTED] wrote: Oh gut, die Diskussion wird sachlich | Ich kann mich mit aptitude nicht anfreunden weißt IMNSHO nicht auf den Wunsch hin das sachlich zu Diskutieren. Es geht nicht um das TUI von aptitude, sondern um seine Fähigkeiten bzgl. der Interpretation und Auflösung von Abhängigkeiten. Das kann dselect IMHO ebenso gut. Und im Übrigen: empfohlen != must-use Eben. EOD. Gerne. Rob -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
On Fri, 13 Jan 2006 12:11:51 +0100, Andreas Pakulat [EMAIL PROTECTED] wrote: On 13.01.06 09:49:13, Marc Haber wrote: Das sollte kein Problem sein. Für stable gebaute Packages sollten auch auf unstable installierbar und lauffähig sein. ... so lange die Abhängigkeiten noch zu befriedigen sind. Bei binaeren Paketen wirds dann noch deutlich schwieriger (Ich sag mal als Beispiel nur C++ Transition). Bei der C++-Transition wurden die Packagenamen geändert. Es sollte also (in der Theorie) dann die ABI-passende Library aus stable nachgezogen werden. Packages aus stable oder oldstable unter unstable habe ich erst eine Handvoll Male benötigt, und da hat es immer funktioniert. Und je mehr ich darüber nachdenke, desto weniger Gründe gibt es dafür dass es nicht funktionieren sollte. Auch gibt es manche Pakete in unstable einfach nicht mehr - oder siehst du noch Gnome 2.8 in unstable? Die Argumentation verstehe ich nicht. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Allgemeine Fragen zum Package System
On 13.01.06 22:47:01, Marc Haber wrote: On Fri, 13 Jan 2006 12:11:51 +0100, Andreas Pakulat [EMAIL PROTECTED] wrote: On 13.01.06 09:49:13, Marc Haber wrote: Das sollte kein Problem sein. Für stable gebaute Packages sollten auch auf unstable installierbar und lauffähig sein. ... so lange die Abhängigkeiten noch zu befriedigen sind. Bei binaeren Paketen wirds dann noch deutlich schwieriger (Ich sag mal als Beispiel nur C++ Transition). Bei der C++-Transition wurden die Packagenamen geändert. Es sollte also (in der Theorie) dann die ABI-passende Library aus stable nachgezogen werden. Ja, nur die neuen Pakete in unstable haben ein Conflicts mit den alten. Wenn ich also ein Programm aus stable haben will das auf z.B. Qt aufbaut aber ein 2. aus unstable welches auch Qt nutzt gibts ein Problem. Und es gibt AFAIK eine Menge C++ Pakete, aehnliches gilt evtl. fuer X11, aber da kenn ich mich nicht soo aus. Packages aus stable oder oldstable unter unstable habe ich erst eine Handvoll Male benötigt, und da hat es immer funktioniert. Glueck gehabt das die Abhaengigkeiten einfach so zu installieren waren. Und je mehr ich darüber nachdenke, desto weniger Gründe gibt es dafür dass es nicht funktionieren sollte. s.o. Bei Skripten kann ich mir ausserdem vorstellen das Paket X ein Script aus Paket Y benoetigt welches aber in der unstable-Version anders benutzt werden muss. Und Paket Z, welches du auch unbedingt brauchst braucht die neue Version von Paket Y. Auch gibt es manche Pakete in unstable einfach nicht mehr - oder siehst du noch Gnome 2.8 in unstable? Die Argumentation verstehe ich nicht. Ich bin davon ausgegangen dass du die Abhaengigkeiten nur in unstable versuchst aufzuloesen und stable-Pakete dabei nicht beruecksichtigst. Andreas -- Your lover will never wish to leave you. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
On Thu, 12 Jan 2006 08:23:52 +0100, Christian Frommeyer [EMAIL PROTECTED] wrote: Am Donnerstag 12 Januar 2006 02:59 schrieb Christoph Anton Mitterer: 1) Ich laufe generell auf sid. Ist es sinnvoll security.debian.org in die sources.list einzufügen? Oder sind die Packages in unstable eh immer neuer? Nein, macht keinen Sinn. Die Pakete von security.debian.org sind für stable gemacht. Das heißt sie bauen auch auf den Versionen aus stable auf (Bibliotheken, C-Compiler, ...). Das sollte kein Problem sein. Für stable gebaute Packages sollten auch auf unstable installierbar und lauffähig sein. Somit hat die Aufnahme von security.debian.org in die sources.list eines sid-Systems dann sinn, wenn es Security-Updates für Packages gibt, die in derselben Version in stable und unstable sind: Dann ist nämlich die Versionsnummer des Security-Updates größer als die in unstable, und apt zieht dann das Update. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Allgemeine Fragen zum Package System
On Thu, 12 Jan 2006 18:41:34 +0100, Andreas Pakulat [EMAIL PROTECTED] wrote: On 12.01.06 18:07:40, Frank Terbeck wrote: Andreas Pakulat [EMAIL PROTECTED] wrote: On 12.01.06 02:59:58, Christoph Anton Mitterer wrote: [...] volatile ist irgendwo zwischen stable und unstable denke ich. Aber ich hab damit keine direkten Erfahrungen. IIRC ist volatile für sich ständig ändernde Packete; Virendatenbanken wären dafür passend... Nicht Virendatenbanken, sondern die Virenscanner. Die Virendatenbank sollte der Scanner taeglich selbst aktualisieren (koenne). Nichtsdestotrotz gibt es clamav-data in volatile. Die Packages für clamav-data werden automatisch gebaut und sollten deswegen leidlich aktuell sein. Praktisch dort, wo ein Virenscannerhost zwar Debian-Packages ziehen kann, aber keinen vollwertigen Internetzugang für freshclam u.a. hat. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Allgemeine Fragen zum Package System
On Thu, 12 Jan 2006 21:33:50 +0100, Robert Grimm [EMAIL PROTECTED] wrote: debfoster. Ist beim ersten Start Arbeitsintensiv, IMHO lohnt sich das aber. debfoster erscheint mir bei konsequenter Verwendung von aptitude eher verdoppelte Arbeit. Aber es ist natürlich ein weiterer Schritt, in dem die Installation und Beibehaltung neuer Packages noch einmal überprüft werden kann. Deswegen benutze ich debfoster immer noch, obwohl ich eigentlich inzwischen nur noch aptitude verwende. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Allgemeine Fragen zum Package System
Am Freitag 13 Januar 2006 09:49 schrieb Marc Haber: Das sollte kein Problem sein. Für stable gebaute Packages sollten auch auf unstable installierbar und lauffähig sein. Somit hat die Das kann ich mir so allgemein nicht vorstellen. Allein schon wegen des anderen C-Compilers. Für die Security-Updates, die tatsächlich anschlagen würden, hast Du allerdings recht. Da hatte ich wohl nicht lang genug nachgedacht. Die Packete müssen dann ja noch in der Sarge Version in sid sein und also die selben Abhängigkeiten haben. Gruß Chris -- A: because it distrupts the normal process of thought Q: why is top posting frowned upon
Re: Allgemeine Fragen zum Package System
On 13.01.06 09:49:13, Marc Haber wrote: On Thu, 12 Jan 2006 08:23:52 +0100, Christian Frommeyer [EMAIL PROTECTED] wrote: Am Donnerstag 12 Januar 2006 02:59 schrieb Christoph Anton Mitterer: 1) Ich laufe generell auf sid. Ist es sinnvoll security.debian.org in die sources.list einzufügen? Oder sind die Packages in unstable eh immer neuer? Nein, macht keinen Sinn. Die Pakete von security.debian.org sind für stable gemacht. Das heißt sie bauen auch auf den Versionen aus stable auf (Bibliotheken, C-Compiler, ...). Das sollte kein Problem sein. Für stable gebaute Packages sollten auch auf unstable installierbar und lauffähig sein. Hae? Sag mal Marc ich glaub du hast die falschen Pillen eingeschmissen. Das gilt fuer nicht-binaere Pakete vllt. aber auch dann nicht unbedingt, je nach dem was fuer Abhaengigkeiten existieren. Bei binaeren Paketen wirds dann noch deutlich schwieriger (Ich sag mal als Beispiel nur C++ Transition). Auch gibt es manche Pakete in unstable einfach nicht mehr - oder siehst du noch Gnome 2.8 in unstable? Andreas -- Tonight's the night: Sleep in a eucalyptus tree. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
On 13.01.06 04:05:40, Christoph Anton Mitterer wrote: Andreas Pakulat wrote: Sag mal kannst du das CC an mich bitte lassen. Ich lese die Liste mit. logo.. Danke. Des doofe an meinen client (TB,... wird Zeit dass ich auf was vernünfitges umsteige ;-) )... ist nur dass er bei Reply,.. nur an dich schickt und bei reply-all,.. auch an dich... Ja der kennt halt kein List-Reply. Dazu gabs schon (recht kurze) Diskussionen hier und (recht lange) in den Bugreports bei Mozilla Mail und TB (upstream BTS natuerlich). Irgendwie scheinen die TB/Moz-Entwickler das Feature nicht zu moegen. Ich kann muttng empfehlen wenn man mit Text-Only auskommt, ansonsten kenne ich nur noch KMail, das hat auch einen List-Reply. -anzeigt wenn bei nem package update zwischen zwei versionen dependencies entfallen,... Hmm, das solltest du mit grep-dctrl _vor_ dem Update selbst hinbekommen und evtl. ein bisschen awk oder so. Vllt. macht man sowas aber auch besser in ner richtigen Programmiersprache... -und beim update sollten nicht nur recommendet packages angezeigt werden sondern auch suggested... Hmm, kann man wohl geteilter Meinung drueber sein. Suggested bedeutet ja nur, dass die dort genannten Pakete zusaetzliche Funktionalitaeten bereitstellen die nicht viele Leute brauchen. Recommended bedeutet hingegen dass die Pakete installiert werden sollten um das Programm im vollen Umfang nutzen zu koennen. Oder so aehnlich. Eine Option waere vllt. sinnvoll, die es erlaubt die Anzeige von Recommends und/oder Suggests auf der Upgrade-Seite an/abzuschalten. Kannst ja mal nen Wishlist-Bug gegen aptitude schreiben. Ja bei suggested und recommendet gibts da extra optionen für (siehe aptitude doc),... bei gar nix leider net,.. Hab ich nicht gewusst, weil noch nicht gebraucht... d.h. Du machst es so, dass Du alles was suggested ist (wenn du es willst),... auch manuell reinsetzt? Jupp, wenn ich Paket X installieren und das Recommended Paket Y und mir scheint das sinnvoll markieren ich Y manuell. Suggests gucke ich mir im Normalfall nicht an, weil dann wird der taegliche Update-Aufwand doch zu hoch. Sag mal, ist das eigentlich bei deinem MUA normal dass er ueberall ne extra Leerzeile einfuegt? Ja,.. wie gesagt,.. der swtich wird wohl irgendwann fällig werden,.. es sei denn 1.5 macht alles besser,... aber mutt oder so taugt mir auch nicht, weil eigetlich nutze ich auch ganz gern MIME emails... Ich weis viele Leute wollen des net, aber ich finde es sollte komplett auf die umgestiegen werden... Was sind denn MIME-Mails? Wie unterscheiden die sich von dieser hier? Ich hoffe du meinst keine HTML-Mails, sowas ist krank, bei HTML in einer Mail steht der Bloat in keinem Verhaeltniss zum Nutzen. Wenn du ein Paket findest dass nicht hinter sich aufraeumt (Dateien in /etc, /usr, /lib, /bin, /sbin u.U. auch /var), dann schreib nen Bugreport gegen das Paket. Das darf naemlich nicht sein, einzige Ausnahme sind Daten und Logs in /var. Ich kenn die Debian-Policy nicht genau aber IIRC duerfen Datenbanken ihre Datenbanken in /var liegen lassen und ebenso duerfen Logdateien in /var/log liegenbleiben. Hmm var is klar,.. Was mir vorher grad auffiel,.. unter /etc/console/boottime.blah gibts ein .old ? Weis net ob des gerechtvertigt ist,... zumindest gehörts zu keinem Package.. Keine Ahnung. Ich kenne nur .dpkg-old und das wird angelegt wenn du eine von Hand geaenderte Datei durch die Version aus dem Paket ueberschreiben laesst bei nem Paketupgrade. .dpkg-new analog wenn du deine Version behaelst. Da diese nicht in Paketinhalten auftauchen werden die auch nicht geloescht. Kann natuerlich immer mal sein, das ein Paket ein nicht-leeres Verzeichnis nicht loeschen kann weil ein anderes Paket dort ne Datei reingelegt hat. Ich find aber auch da sollte man sich was einfallen lassen,.. klar apt bzw. dpkg zeigt des an, aber wenn ich mal ein riesiges update fahre,.. kann man so schnell ja gar net guggen... Deswegen schreibt dpkg+aptitude ja jeweils ein Log. Ok... ich geb ja zu, dass es nicht so helle war zu fragen, ob s.d.o bei sid sinnmacht,.. allein schon die dependencies machen einem da ja bald nen stric durch die Rechnung... Nee, der eigentliche Grund warum es keine security-Updates fuer sid gibt ist, dass die security-updates ganz einfach in einer neuen Paketversion aufgehen. Ja gut,.. des war mir schon auch klar,... ABER wenn ein sec-hole da ist,.. dauer es evtl. bis jemand ein neues Package nach unstable schiebt,... und die s.d.o Leute reagieren halt sofort,.. dachte ich,.. Also ich beobachte das nicht genau, aber ich denke bei Security-Bugs reagieren die s.d.o Leute nicht viel schneller als der Paketmaintainer. Vor allem wenn die Security-Fixes nicht leicht zurueckportierbar auf das Sarge-Paket sind ist ein neues Paket in Unstable wahrscheinlich fixer. Ausserdem muss sich das Security-Team um die ganze Distri kuemmern, waehrend ein Paketmaintainer nur ein paar
Re: Allgemeine Fragen zum Package System
Marc Haber [EMAIL PROTECTED] wrote: debfoster erscheint mir bei konsequenter Verwendung von aptitude eher verdoppelte Arbeit. Darüber kann ich nichts sagen. Aber es ist natürlich ein weiterer Schritt, in dem die Installation und Beibehaltung neuer Packages noch einmal überprüft werden kann. Deswegen benutze ich debfoster immer noch, obwohl ich eigentlich inzwischen nur noch aptitude verwende. Ich kann mich mit aptitude nicht anfreunden und verwende deshalb dselect oder apt-get. Rob -- Schmeiß die +90% PCs weg und 'das Internet' wird noch immer funktionieren. Streiche noch immer setze besser als vorher -- Toni Grass und Jens Sülwald in de.comp.security.firewall -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
Robert Grimm [EMAIL PROTECTED] wrote: Ich kann mich mit aptitude nicht anfreunden und verwende deshalb dselect oder apt-get. Tag Robert, Seit 'Sarge' wird aptitude als Packetverwaltungstool empfohlen (siehe Sarge Release Notes). Und im Allgemeinen kann aptitude als drop-in-replacement für apt-get benutzt werden: # aptitude update # aptitude upgrade und andere funktionieren genau so wie man es von apt-get erwarten würde. Gruss, Frank -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
Frank Terbeck [EMAIL PROTECTED] wrote: Robert Grimm [EMAIL PROTECTED] wrote: Ich kann mich mit aptitude nicht anfreunden und verwende deshalb dselect ^^^ oder apt-get. Seit 'Sarge' wird aptitude als Packetverwaltungstool empfohlen (siehe Sarge Release Notes). Muß ich jetzt eine andere Distribution verwenden? ;- , | [EMAIL PROTECTED]:~]$ apt-cache show dselect aptitude | Package: dselect | Priority: required | [...] | Package: aptitude | Priority: optional | [...] ` Auch scheint man das für sarge nicht so ernst gemeint zu haben. Und im Allgemeinen kann aptitude als drop-in-replacement für apt-get benutzt werden: # aptitude update # aptitude upgrade und andere funktionieren genau so wie man es von apt-get erwarten würde. Wozu? apt-get funktioniert auch genau so wie ich es von apt-get erwarte. Rob -- Linux is not user-friendly. It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly. -- Seen somewhere on the net -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
Robert Grimm [EMAIL PROTECTED] wrote: Frank Terbeck [EMAIL PROTECTED] wrote: Seit 'Sarge' wird aptitude als Packetverwaltungstool empfohlen (siehe Sarge Release Notes). Muß ich jetzt eine andere Distribution verwenden? ;- , | [EMAIL PROTECTED]:~]$ apt-cache show dselect aptitude | Package: dselect | Priority: required | [...] | Package: aptitude | Priority: optional | [...] ` Auch scheint man das für sarge nicht so ernst gemeint zu haben. Und im Allgemeinen kann aptitude als drop-in-replacement für apt-get benutzt werden: # aptitude update # aptitude upgrade und andere funktionieren genau so wie man es von apt-get erwarten würde. Wozu? apt-get funktioniert auch genau so wie ich es von apt-get erwarte. *sigh* Natürlich darfst du nutzen was du willst... Ich würde niemals jemandem vorschreiben wollen welche Software er/sie nutzt. Hättest du jedoch (wie ich vorschlug in die Release Notes zu Sarge geschaut, wäre dir folgendes aufgefallen: [snip] Aktualisierungstests haben gezeigt, dass die aptitude-Version aus Sarge komplexe Abhängigkeiten während einer Aktualisierung besser auflöst als apt-get oder aptitude aus Woody. [snap] und [snip] Die empfohlene Methode, zwischen Debian GNU/Linux-Releases zu aktualisieren, ist die Benutzung des Paket-Management-Werkzeugs aptitude. Dieses Werkzeug trifft sicherere und bessere Entscheidungen über Pakete als apt-get. [snap] Gruss, Frank -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
Frank Terbeck [EMAIL PROTECTED] wrote: Hättest du jedoch (wie ich vorschlug in die Release Notes zu Sarge geschaut, wäre dir folgendes aufgefallen: Du darfst Dir sicher sein, daß mir die Release Notes bekannt sind. Nur leider hatte ich zum Zeitpunkt als Sarge released wurde, das upgrade längst mit Hilfe von dselect hinter mich gebracht. [snip] Die empfohlene Methode, zwischen Debian GNU/Linux-Releases zu aktualisieren, ist die Benutzung des Paket-Management-Werkzeugs aptitude. Dieses Werkzeug trifft sicherere und bessere Entscheidungen über Pakete als apt-get. [snap] Und wenn dann bei Etch YAST empfohlen wird, werd ich immer noch dselect nehmen. ;-) Rob -- You only think this is a free country. Like the US the UK spends a lot of time explaining its a free country because its a police state. -- Alan Cox -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
Robert Grimm [EMAIL PROTECTED] wrote: Und wenn dann bei Etch YAST empfohlen wird, werd ich immer noch dselect nehmen. ;-) Oh gut, die Diskussion wird sachlich Es geht nicht um das TUI von aptitude, sondern um seine Fähigkeiten bzgl. der Interpretation und Auflösung von Abhängigkeiten. Und im Übrigen: empfohlen != must-use EOD. Gruss, Frank -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System (OT)
Robert Grimm wrote: Muß ich jetzt eine andere Distribution verwenden? ;- Können wir darüber Abstimmen was Du verwenden _musst_?? Also ich schlage für den Anfang einer Liste an Möglichkeiten mal potato, fedora und hmm... gabs nicht mal von Corel ne Distri? ... vor. *g* :-P noch mehr OT und nur @ Robert... is eigentlich mal wieder Stammtisch in München? (hab dein Key noch nicht vergessen, aber momentan muss ich auf Semesterprüfungen lernen) Chris. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
On 12.01.06 02:59:58, Christoph Anton Mitterer wrote: Hallo. Ich hätte mal ein paar Fragen zum Package System und allem was damit so zusammen hängt. Erst mal noch nicht aus der Sicht wie-macht-man-packages. Vorweg: Gibts da ne allgemeine allumfassende Doku zu? Man koennte die Doku von www.debian.org lesen, das debiananwenderhandbuch.de und die manpages zu APT und co. Reicht dir das? 1) Ich laufe generell auf sid. Ist es sinnvoll security.debian.org in die sources.list einzufügen? Oder sind die Packages in unstable eh immer neuer? Wenn du diese Frage stellen musst, bist du bei sid falsch. 2) Es gibt ja folgende mehr oder weniger offizielle trees: stable, testing, unstable, backports, volatile Seh ich des richtig, dass der Versionsaufbau immer so ist: stable = (security.debian.org =) backports = (security.debian.org =) volatile = (security.debian.org =) testing = unstable Nein. volatile hat erstmal nicht wirklich was mit Debian zu tun. Ansonsten gilt: stable security testing unstable experimental dass stable = testing = unstable is mir schon klar, es geht mir mehr um die position von volatile und den sec-patches. (Was im Prinzip 1) mit beantworten würde). volatile ist irgendwo zwischen stable und unstable denke ich. Aber ich hab damit keine direkten Erfahrungen. 3) Zum Paketmanagement nehm ich meistens aptitude her (es sei denn es geht tieder ins System, dann halt apt/dpkg und zig tools wie grep-*) Da ist es ja so, dass oft durch upgrades/neuinstallationen, Packages automatisch deinstalliert werden (automatically deinstalled to satisfy dependencies). Da ist der status bei diesen dann dA. Ok d heißt ja löschen, dess Pakets ohne config-files wenn ich mich recht erinnere. Sollte man des abändern auf purge? Kommt drauf an ob du die Konfig-Dateien behalten willst. Da gibts ne Konfigurationsoption zu damit immer gepurged wird, wie die heisst steht in der Doku zu aptitude im Paket aptitude-doc-en. Also meine Frage lautet im Prinzip wenn Packages andere automatisch deinstallieren, sollte man da nicht generell Purge machen damit von den deinstallierten Packages keine Dateileichen übrig bleiben? Oder nehmen die (meißt ersetzenden Packages) genau jene Konfiguration her (also sollte man nicht purge machen?)? Kommt auf die jeweiligen Pakete an... Beispiel wäre als hotplug durch udev ersetzt wurde. udev unterstuetzt IIRC nur einen Teil von hotplugs Konfigurationsdateien. 4) last but not least Was ja immer wieder ein gewisses Problem ist, sind Paketleichen, also Pakages die nicht mehr gebraucht werden. Noe, wenn ich ein Paket nicht mehr brauche deinstalliere ich es. Wenn ich mir nicht sicher bin bleibts halt drauf. Wenn ich eines vergesse: Mein Gott, einmal im Jahr kann man sich mal 2 Stunden frei nehmen und die Liste der installierten Pakete durchgucken. Aptitude bietet da ja seinen mechainsmus mit dem A-Marker an,... ich missbrauche das Ganze immer ein wenig, und setzte auch suggested und recommended Packages mit auf A die ich sonst (ohne das Hauptpackage) nicht verwenden würde. Ich installiere suggests und recommends erst gar nicht. Ausser ich will sie wirklich haben und dann gilt wieder obiges. Ein tool wäre deborphan, aber so recht gefällt mir das nicht, vor allem glaub ich mal pauschal nicht dass es packages anzeigen würde, die eigentlich nicht mehr gebraucht werden, die sich aber im Kreis dependen (gibt mehrere libs die des machen). Ich verstehe nicht ganz, aber ich kann mich auch nicht wirklich erinnern was deborphan macht. War das dass welches Pakete findet auf die kein anderes eine Abhaengigkeit hat? Gibts irgendwie ein tool, dass graphisch den Paketbaum (aller installierten) und deren dependency/suggested/recommended Abhängigkeiten zeigt? Grafisch nicht, aber wenn obiges richtig ist koenntest du mal debfoster ausprobieren, das fragt dich welche Pakete du behalten willst und welche Abhaengigkeiten davon beruehrt werden. Oder was kann man sonst noch tun gegen Paketleichen? s.o. ab und zu hinsetzen und schauen was alles so rumfliegt. Insbesondere auch, was kann man tun gegen Dateileichen die bei der deinstallation nicht mitgelöscht wurden? rm -rf Andreas -- Stay away from flying saucers today. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
Andreas Pakulat [EMAIL PROTECTED] wrote: On 12.01.06 02:59:58, Christoph Anton Mitterer wrote: [...] volatile ist irgendwo zwischen stable und unstable denke ich. Aber ich hab damit keine direkten Erfahrungen. IIRC ist volatile für sich ständig ändernde Packete; Virendatenbanken wären dafür passend... Eine Einordnung zwischen stable/testing/unstable macht keinen Sinn. Gruss, Frank -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
On 12.01.06 18:07:40, Frank Terbeck wrote: Andreas Pakulat [EMAIL PROTECTED] wrote: On 12.01.06 02:59:58, Christoph Anton Mitterer wrote: [...] volatile ist irgendwo zwischen stable und unstable denke ich. Aber ich hab damit keine direkten Erfahrungen. IIRC ist volatile für sich ständig ändernde Packete; Virendatenbanken wären dafür passend... Nicht Virendatenbanken, sondern die Virenscanner. Die Virendatenbank sollte der Scanner taeglich selbst aktualisieren (koenne). Eine Einordnung zwischen stable/testing/unstable macht keinen Sinn. Doch, denn in unstable kriegst du die neuen Pakete auch. In testing nciht so schnell, da mag volatile noch Sinn machen. Aber ich denke das erklaerte Ziel ist schnellebige Pakete wie eben Virenscanner fuer Stable in aktuellen Versionen bereitzustellen. Andreas -- You have the capacity to learn from mistakes. You'll learn a lot today. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
bndreas Pakulat [EMAIL PROTECTED] wrote: On 12.01.06 18:07:40, Frank Terbeck wrote: Andreas Pakulat [EMAIL PROTECTED] wrote: On 12.01.06 02:59:58, Christoph Anton Mitterer wrote: [...] volatile ist irgendwo zwischen stable und unstable denke ich. Aber ich hab damit keine direkten Erfahrungen. IIRC ist volatile für sich ständig ändernde Packete; Virendatenbanken wären dafür passend... Nicht Virendatenbanken, sondern die Virenscanner. Die Virendatenbank sollte der Scanner taeglich selbst aktualisieren (koenne). Möglich, nutze keinen Virenscanner... Wobei das Schnelllebige an Virenscannern doch wohl die Datenbanken sind. Eine Einordnung zwischen stable/testing/unstable macht keinen Sinn. Doch, denn in unstable kriegst du die neuen Pakete auch. In testing nciht so schnell, da mag volatile noch Sinn machen. Aber ich denke das erklaerte Ziel ist schnellebige Pakete wie eben Virenscanner fuer Stable in aktuellen Versionen bereitzustellen. Wir sind uns über den Sinn von volatile einig, aber es irgendwo zwischen den Distris plazieren zu wollen, macht keinen Sinn. Vielleicht habe ich dich auch in der ursprünglichen Mail falsch verstanden. Gruss, Frank -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
On 12.01.06 18:51:29, Frank Terbeck wrote: bndreas Pakulat [EMAIL PROTECTED] wrote: On 12.01.06 18:07:40, Frank Terbeck wrote: Andreas Pakulat [EMAIL PROTECTED] wrote: On 12.01.06 02:59:58, Christoph Anton Mitterer wrote: [...] volatile ist irgendwo zwischen stable und unstable denke ich. Aber ich hab damit keine direkten Erfahrungen. IIRC ist volatile für sich ständig ändernde Packete; Virendatenbanken wären dafür passend... Nicht Virendatenbanken, sondern die Virenscanner. Die Virendatenbank sollte der Scanner taeglich selbst aktualisieren (koenne). Möglich, nutze keinen Virenscanner... Wobei das Schnelllebige an Virenscannern doch wohl die Datenbanken sind. Das schnelllebigste, ja. Aber es geht vor allem darum Lücken in Virenscannern und aehnlicher Software zeitnah fuer stable zu reparieren ohne an die Bedingungen von security.debian.org gebunden zu sein. Eine Einordnung zwischen stable/testing/unstable macht keinen Sinn. Doch, denn in unstable kriegst du die neuen Pakete auch. In testing nciht so schnell, da mag volatile noch Sinn machen. Aber ich denke das erklaerte Ziel ist schnellebige Pakete wie eben Virenscanner fuer Stable in aktuellen Versionen bereitzustellen. Wir sind uns über den Sinn von volatile einig, aber es irgendwo zwischen den Distris plazieren zu wollen, macht keinen Sinn. Vielleicht habe ich dich auch in der ursprünglichen Mail falsch verstanden. Die ganze Einsortierung des OP war nicht so richtig sinnig. Mehr als stable s.d.o testing unstable experimental macht keinen Sinn. Andreas -- Your own qualities will help prevent your advancement in the world. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
Andreas Pakulat wrote: 1) Ich laufe generell auf sid. Ist es sinnvoll security.debian.org in die sources.list einzufügen? Oder sind die Packages in unstable eh immer neuer? Wenn du diese Frage stellen musst, bist du bei sid falsch. Ach ich denk ich bin da schon ganz richtig,... 3) Zum Paketmanagement nehm ich meistens aptitude her (es sei denn es geht tieder ins System, dann halt apt/dpkg und zig tools wie grep-*) Da ist es ja so, dass oft durch upgrades/neuinstallationen, Packages automatisch deinstalliert werden (automatically deinstalled to satisfy dependencies). Da ist der status bei diesen dann dA. Ok d heißt ja löschen, dess Pakets ohne config-files wenn ich mich recht erinnere. Sollte man des abändern auf purge? Kommt drauf an ob du die Konfig-Dateien behalten willst. Da gibts ne Konfigurationsoption zu damit immer gepurged wird, wie die heisst steht in der Doku zu aptitude im Paket aptitude-doc-en. Ja das ist mir schon klar,.. es ging ja auch mehr darum,.. ob, wie zum Beispiel im udev/hotplug Fall des generell überhaupt was bringen würde, sprich dass udev Konfigsachen von hotplug übernehmen könnte und an sich anpassen. Seh ich es richtig, dass ich folgendermaßen auf der richtigen seite bin: Immer purge auswählen (also in aptitude pA - automatisch gepurged to satisfy dependencies), es sei denn bei Paketen deren Konfiguration ich selber schon modifiziert habe. Die kann ich dann manuell zurückspielen Und bei allem anderen müssten eventuelle Dateileichen verschwinden (wegen dem purge) und aber auch die neue Konfig vom Maintainer kommen = sollte alles sauber sein. Also meine Frage lautet im Prinzip wenn Packages andere automatisch deinstallieren, sollte man da nicht generell Purge machen damit von den deinstallierten Packages keine Dateileichen übrig bleiben? Oder nehmen die (meißt ersetzenden Packages) genau jene Konfiguration her (also sollte man nicht purge machen?)? Kommt auf die jeweiligen Pakete an... Hmm hab ich befürchtet. Beispiel wäre als hotplug durch udev ersetzt wurde. udev unterstuetzt IIRC nur einen Teil von hotplugs Konfigurationsdateien. Ja wie gesagt,.. ich denke ich müsste auf jeden fall sicher dabei senn,.. wenn hotplug automatisch gepurged wird, weil dann muss udev halt alle config-files frisch und neu installen. Eventuelle manuelle Änderungen muss ich dann halt nach machen. 4) last but not least Was ja immer wieder ein gewisses Problem ist, sind Paketleichen, also Pakages die nicht mehr gebraucht werden. Noe, wenn ich ein Paket nicht mehr brauche deinstalliere ich es. Wenn ich mir nicht sicher bin bleibts halt drauf. Wenn ich eines vergesse: Mein Gott, einmal im Jahr kann man sich mal 2 Stunden frei nehmen und die Liste der installierten Pakete durchgucken. Das kann aber ganz schön in Arbeit ausarten Außerdem,.. ich fahr beispiel jeden Tag ein upgrade es kommt ja auch oft vor, dass bei ner neuen version, dependencies wegfallen,... des krieg ich ja so nicht direkt raus (es sei denn ich vergleich die dependencies der versionen = arbeit :- = gibts da ein tool für?) Ich verstehe nicht ganz, aber ich kann mich auch nicht wirklich erinnern was deborphan macht. War das dass welches Pakete findet auf die kein anderes eine Abhaengigkeit hat? Ja. Gibts irgendwie ein tool, dass graphisch den Paketbaum (aller installierten) und deren dependency/suggested/recommended Abhängigkeiten zeigt? Grafisch nicht, aber wenn obiges richtig ist koenntest du mal debfoster ausprobieren, das fragt dich welche Pakete du behalten willst und welche Abhaengigkeiten davon beruehrt werden. Hmm ja des kenn ich schon,.. taugt mir nicht so richtig. Oder was kann man sonst noch tun gegen Paketleichen? s.o. ab und zu hinsetzen und schauen was alles so rumfliegt. Ja des war mir schon auch klar,.. ich hatte halt auf eine automatisiertere Lösung gehofft. Insbesondere auch, was kann man tun gegen Dateileichen die bei der deinstallation nicht mitgelöscht wurden? rm -rf Da verschwinden aber auch falsche config-files Chris. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
Andreas Pakulat [EMAIL PROTECTED] wrote: [...] Wir sind uns über den Sinn von volatile einig, aber es irgendwo zwischen den Distris plazieren zu wollen, macht keinen Sinn. Vielleicht habe ich dich auch in der ursprünglichen Mail falsch verstanden. Die ganze Einsortierung des OP war nicht so richtig sinnig. Mehr als stable s.d.o testing unstable experimental macht keinen Sinn. Ja, hatte irgendwie im Hinterkopf, dass das von dir kam, sorry. Gruss, Frank -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
On 12.01.06 19:15:27, Christoph Anton Mitterer wrote: Andreas Pakulat wrote: 1) Ich laufe generell auf sid. Ist es sinnvoll security.debian.org in die sources.list einzufügen? Oder sind die Packages in unstable eh immer neuer? Wenn du diese Frage stellen musst, bist du bei sid falsch. Ach ich denk ich bin da schon ganz richtig,... Ehrlich: Wenn du die Frage nicht selbst beantworten kannst bist du mit sid nicht gut bedient, oder du hast zuviel Freizeit. 3) Zum Paketmanagement nehm ich meistens aptitude her (es sei denn es geht tieder ins System, dann halt apt/dpkg und zig tools wie grep-*) Da ist es ja so, dass oft durch upgrades/neuinstallationen, Packages automatisch deinstalliert werden (automatically deinstalled to satisfy dependencies). Da ist der status bei diesen dann dA. Ok d heißt ja löschen, dess Pakets ohne config-files wenn ich mich recht erinnere. Sollte man des abändern auf purge? Kommt drauf an ob du die Konfig-Dateien behalten willst. Da gibts ne Konfigurationsoption zu damit immer gepurged wird, wie die heisst steht in der Doku zu aptitude im Paket aptitude-doc-en. Ja das ist mir schon klar,.. es ging ja auch mehr darum,.. ob, wie zum Beispiel im udev/hotplug Fall des generell überhaupt was bringen würde, sprich dass udev Konfigsachen von hotplug übernehmen könnte und an sich anpassen. Keine Ahnung wie das beim hotplug-udev upgrade war, aber das sollte im changelog von udev dokumentiert sein. Insbesondere welche hotplug-Dateien immernoch ausgewertet werden (IIRC die blacklist z.B.) und welche Dateien wegfallen. Auch in die NEWS sollte man gucken. Aber das weisst du als sid-Nutzer ja alles schon ;-) Seh ich es richtig, dass ich folgendermaßen auf der richtigen seite bin: Immer purge auswählen (also in aptitude pA - automatisch gepurged to satisfy dependencies), es sei denn bei Paketen deren Konfiguration ich selber schon modifiziert habe. Ja, wobie ordentlich gemachte Ersetzungen sollten (soweit es moeglich ist) bestehende Konfigurationen uebernehmen oder eben in den NEWS darauf hinweisen das sich was grundlegendes aendert und man selbst mal schauen muss. Die changelogs die du ja bei jedem Upgrade liest geben auch Aufschluss ueber moegliche Aenderungen. Die kann ich dann manuell zurückspielen Und bei allem anderen müssten eventuelle Dateileichen verschwinden (wegen dem purge) und aber auch die neue Konfig vom Maintainer kommen = sollte alles sauber sein. Naja, sofern ne neue Config kommt, manchmal kann es auch passieren dass alte Verzeichnisse nicht geloescht werden koennen. Zum Beispiel weil man selbst dort ne Datei reingelegt hat... Dann muss man selbst Hand anlegen. Beispiel wäre als hotplug durch udev ersetzt wurde. udev unterstuetzt IIRC nur einen Teil von hotplugs Konfigurationsdateien. Ja wie gesagt,.. ich denke ich müsste auf jeden fall sicher dabei senn,.. wenn hotplug automatisch gepurged wird, weil dann muss udev halt alle config-files frisch und neu installen. Noe, insbesondere nicht die Dateien von hotplug. Da sind etliche Dateien weggefallen. Eventuelle manuelle Änderungen muss ich dann halt nach machen. Vor allem musst du die neuen Konfigurationsdateien dafuer finden, aber das sollte mit Hilfe von changelog+NEWS und der jeweiligen Paketdoku nicht soo problematisch sein. 4) last but not least Was ja immer wieder ein gewisses Problem ist, sind Paketleichen, also Pakages die nicht mehr gebraucht werden. Noe, wenn ich ein Paket nicht mehr brauche deinstalliere ich es. Wenn ich mir nicht sicher bin bleibts halt drauf. Wenn ich eines vergesse: Mein Gott, einmal im Jahr kann man sich mal 2 Stunden frei nehmen und die Liste der installierten Pakete durchgucken. Das kann aber ganz schön in Arbeit ausarten Noe, bei meinen 2137 Paketen dauert das ca. 2 - 4 Stunden - je nach dem wie oft ich mich durch Emails ablenken lasse. Aber ich kann ueber viele Dinge auch so hinweg gehen ohne genauer hinschauen zu muessen weil ich ziemlich genau weiss was wozu gehoert und ob ich das brauche oder nicht. Außerdem,.. ich fahr beispiel jeden Tag ein upgrade es kommt ja auch oft vor, dass bei ner neuen version, dependencies wegfallen,... des krieg ich ja so nicht direkt raus (es sei denn ich vergleich die dependencies der versionen = arbeit :- = gibts da ein tool für?) Aehm, wenn du aptitude benutzt werden die nicht mehr notwendigen Dependecies entfernt, sofern sie automatisch installiert wurden. Deswegen mag ich ja aptitude so. Gibts irgendwie ein tool, dass graphisch den Paketbaum (aller installierten) und deren dependency/suggested/recommended Abhängigkeiten zeigt? Grafisch nicht, aber wenn obiges richtig ist koenntest du mal debfoster ausprobieren, das fragt dich welche Pakete du behalten willst und welche Abhaengigkeiten davon beruehrt werden. Hmm ja des kenn ich schon,.. taugt mir nicht so richtig. Doch das taugt schon, ist halt reichlich
Re: Allgemeine Fragen zum Package System
Andreas Pakulat wrote: 1) Ich laufe generell auf sid. Ist es sinnvoll security.debian.org in die sources.list einzufügen? Oder sind die Packages in unstable eh immer neuer? Wenn du diese Frage stellen musst, bist du bei sid falsch. Ach ich denk ich bin da schon ganz richtig,... Ehrlich: Wenn du die Frage nicht selbst beantworten kannst bist du mit sid nicht gut bedient, oder du hast zuviel Freizeit. [1] Ja das ist mir schon klar,.. es ging ja auch mehr darum,.. ob, wie zum Beispiel im udev/hotplug Fall des generell überhaupt was bringen würde, sprich dass udev Konfigsachen von hotplug übernehmen könnte und an sich anpassen. Keine Ahnung wie das beim hotplug-udev upgrade war, aber das sollte im changelog von udev dokumentiert sein. Insbesondere welche hotplug-Dateien immernoch ausgewertet werden (IIRC die blacklist z.B.) und welche Dateien wegfallen. Auch in die NEWS sollte man gucken. Hmm ja aber wer hat schon die Zeit/Lust bei riesigen Updates (z.B. X) alles durchzulesen... Aber das weisst du als sid-Nutzer ja alles schon ;-) [1] Die kann ich dann manuell zurückspielen Und bei allem anderen müssten eventuelle Dateileichen verschwinden (wegen dem purge) und aber auch die neue Konfig vom Maintainer kommen = sollte alles sauber sein. Naja, sofern ne neue Config kommt, manchmal kann es auch passieren dass alte Verzeichnisse nicht geloescht werden koennen. Zum Beispiel weil man selbst dort ne Datei reingelegt hat... Dann muss man selbst Hand anlegen. Das ist klar,.. aber sollte apt ja auch melden wenn was nicht gelöscht werden konnte. Ja wie gesagt,.. ich denke ich müsste auf jeden fall sicher dabei senn,.. wenn hotplug automatisch gepurged wird, weil dann muss udev halt alle config-files frisch und neu installen. Noe, insbesondere nicht die Dateien von hotplug. Da sind etliche Dateien weggefallen. Dann sollte aber udev, sofern sie sie benötigt sie entweder selber mitbringen, oder predependen auf hotplug oder was ähnliches... Eventuelle manuelle Änderungen muss ich dann halt nach machen. Vor allem musst du die neuen Konfigurationsdateien dafuer finden, aber das sollte mit Hilfe von changelog+NEWS und der jeweiligen Paketdoku nicht soo problematisch sein. Klar, schlimmsten Fall sieht man sich die Package-Quellen an... Noe, wenn ich ein Paket nicht mehr brauche deinstalliere ich es. Wenn ich mir nicht sicher bin bleibts halt drauf. Wenn ich eines vergesse: Mein Gott, einmal im Jahr kann man sich mal 2 Stunden frei nehmen und die Liste der installierten Pakete durchgucken. Das kann aber ganz schön in Arbeit ausarten Noe, bei meinen 2137 Paketen dauert das ca. 2 - 4 Stunden - je nach dem wie oft ich mich durch Emails ablenken lasse. Aber ich kann ueber viele Dinge auch so hinweg gehen ohne genauer hinschauen zu muessen weil ich ziemlich genau weiss was wozu gehoert und ob ich das brauche oder nicht. Gut des weis ich in der Regel auch, aber trotzdem nimmt es Zeit in anspruch für niedere Arbeit,.. und die spar ich mir halt wenn es irgendwie geht Außerdem,.. ich fahr beispiel jeden Tag ein upgrade es kommt ja auch oft vor, dass bei ner neuen version, dependencies wegfallen,... des krieg ich ja so nicht direkt raus (es sei denn ich vergleich die dependencies der versionen = arbeit :- = gibts da ein tool für?) Aehm, wenn du aptitude benutzt werden die nicht mehr notwendigen Dependecies entfernt, sofern sie automatisch installiert wurden. Deswegen mag ich ja aptitude so. Ja,.. Problem ist nur folgendes,... manchmal passt mir das so wie sich der jeweilige Package maintainer das gedacht hat nicht und ich setzte des A flag in aptitude auch bei packages die nur suggested werden oder recommented. Gut für die gibts noch die optionen aptitude:keep-foo true; aber,... manchmal mach ich das auch bei Paketen die nicht mal dependet werden. Beispiel: Ich brauch card reader um mich im Sicherheitsnetz vom Cluster einloggen zu können: Deswegen hab ich pcscd installiert und auch pcsc-tools. Die pcscd dependet nicht auf den tools, suggested und recommendet sie auch nicht aber trotzdem setz ich sie auf automatic, dass ich drann denke sie auch zu löschen wenn ich mal pcscd löschen sollte btw: kennt jemand ne Möglichkeit ne liste aller Pakete ausgeben zu lassen mit ihrem status ob sie Automatic sind oder nicht? dpkg -l zeigt des leider net an Gibts irgendwie ein tool, dass graphisch den Paketbaum (aller installierten) und deren dependency/suggested/recommended Abhängigkeiten zeigt? Grafisch nicht, aber wenn obiges richtig ist koenntest du mal debfoster ausprobieren, das fragt dich welche Pakete du behalten willst und welche Abhaengigkeiten davon beruehrt werden. Hmm ja des kenn ich schon,.. taugt mir nicht so richtig. Doch das taugt schon, ist halt reichlich aufwaendig. Aber wenn du ihm das erstmal einmal beigebracht hast ist der Aufwand der Pflege geringer. Ich sagte
Re: Allgemeine Fragen zum Package System
Christoph Anton Mitterer [EMAIL PROTECTED] wrote: Das kann aber ganz schön in Arbeit ausarten Außerdem,.. ich fahr beispiel jeden Tag ein upgrade es kommt ja auch oft vor, dass bei ner neuen version, dependencies wegfallen,... des krieg ich ja so nicht direkt raus (es sei denn ich vergleich die dependencies der versionen = arbeit :- = gibts da ein tool für?) debfoster. Ist beim ersten Start Arbeitsintensiv, IMHO lohnt sich das aber. Rob -- Netter Versuch, das Weltklima durch übermäßige CPU-Zeit-Vergeudung zur Erzielung von meist eingebildeten Performance-Verbesserungen mittels vollkommen irrelevanter Optimierungen zu beeinflussen. --Sven Hartge über Gentoo -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Allgemeine Fragen zum Package System
On 12.01.06 21:17:45, Christoph Anton Mitterer wrote: Andreas Pakulat wrote: Ja das ist mir schon klar,.. es ging ja auch mehr darum,.. ob, wie zum Beispiel im udev/hotplug Fall des generell überhaupt was bringen würde, sprich dass udev Konfigsachen von hotplug übernehmen könnte und an sich anpassen. Keine Ahnung wie das beim hotplug-udev upgrade war, aber das sollte im changelog von udev dokumentiert sein. Insbesondere welche hotplug-Dateien immernoch ausgewertet werden (IIRC die blacklist z.B.) und welche Dateien wegfallen. Auch in die NEWS sollte man gucken. Sag mal kannst du das CC an mich bitte lassen. Ich lese die Liste mit. Hmm ja aber wer hat schon die Zeit/Lust bei riesigen Updates (z.B. X) alles durchzulesen... ?? Wenn X11 upgegraded wird ist das bei apt-listchanges 1 weitere changelog Eintrag. Denn gluecklicherweise stammen (noch) alle X11-Pakete aus demselben Source-Paket. Ich lese die changelogs auch nicht intensiv aber ich ueberfliege sie jedesmal um zu schauen ob was wichtiges bei ist. Mit der Zeit entwickelt man ein Gespuer dafuer. Wenn du das nicht machst: Na viel Glueck, da kann auch fix mal was kaputt gehen in Sid. Ich lese lieber mal 10 Minuten Changelogs anstatt mich ne Stunde mit irgendwelchen Problemen zu beschaefitgen. Die kann ich dann manuell zurückspielen Und bei allem anderen müssten eventuelle Dateileichen verschwinden (wegen dem purge) und aber auch die neue Konfig vom Maintainer kommen = sollte alles sauber sein. Naja, sofern ne neue Config kommt, manchmal kann es auch passieren dass alte Verzeichnisse nicht geloescht werden koennen. Zum Beispiel weil man selbst dort ne Datei reingelegt hat... Dann muss man selbst Hand anlegen. Das ist klar,.. aber sollte apt ja auch melden wenn was nicht gelöscht werden konnte. Jupp. Ja wie gesagt,.. ich denke ich müsste auf jeden fall sicher dabei senn,.. wenn hotplug automatisch gepurged wird, weil dann muss udev halt alle config-files frisch und neu installen. Noe, insbesondere nicht die Dateien von hotplug. Da sind etliche Dateien weggefallen. Dann sollte aber udev, sofern sie sie benötigt sie entweder selber mitbringen, oder predependen auf hotplug oder was ähnliches... Genau das ist passiert, udev kennt nur noch ein paar Configdateien in /etc/hotplug, das meiste wurde nach /etc/udev.d gelegt. Aber das stand alles in den NEWS, die solltest du mal lesen *wink* Eventuelle manuelle Änderungen muss ich dann halt nach machen. Vor allem musst du die neuen Konfigurationsdateien dafuer finden, aber das sollte mit Hilfe von changelog+NEWS und der jeweiligen Paketdoku nicht soo problematisch sein. Klar, schlimmsten Fall sieht man sich die Package-Quellen an... Also soweit kommts bei mir nur _aeusserst_ selten. Außerdem,.. ich fahr beispiel jeden Tag ein upgrade es kommt ja auch oft vor, dass bei ner neuen version, dependencies wegfallen,... des krieg ich ja so nicht direkt raus (es sei denn ich vergleich die dependencies der versionen = arbeit :- = gibts da ein tool für?) Aehm, wenn du aptitude benutzt werden die nicht mehr notwendigen Dependecies entfernt, sofern sie automatisch installiert wurden. Deswegen mag ich ja aptitude so. Ja,.. Problem ist nur folgendes,... manchmal passt mir das so wie sich der jeweilige Package maintainer das gedacht hat nicht und ich setzte des A flag in aptitude auch bei packages die nur suggested werden oder recommented. Gut für die gibts noch die optionen aptitude:keep-foo true; aber,... manchmal mach ich das auch bei Paketen die nicht mal dependet werden. Hmm, du installierst ein Recommends oder Suggests also manuell und setzt dann das A-Flag darauf? Beispiel: Ich brauch card reader um mich im Sicherheitsnetz vom Cluster einloggen zu können: Deswegen hab ich pcscd installiert und auch pcsc-tools. Die pcscd dependet nicht auf den tools, suggested und recommendet sie auch nicht aber trotzdem setz ich sie auf automatic, dass ich drann denke sie auch zu löschen wenn ich mal pcscd löschen sollte Hmm, aber will aptitude dass dann nicht bei jedem Upgrade entfernen, weil kein Paket darauf depended? Das waere mir naemlich zu muehselig. btw: kennt jemand ne Möglichkeit ne liste aller Pakete ausgeben zu lassen mit ihrem status ob sie Automatic sind oder nicht? dpkg -l zeigt des leider net an Mit aptitude und seinen Search Pattern sollte das gehen. aptitude-doc-en installieren und lesen. Ich sagte es taugt MIR nicht,... des tool mag schon gut sein,.. aber es passt nicht zu MEINEN persönlichen Gewohnheiten Deswegen musst du nicht gleich laut werden. Da verschwinden aber auch falsche config-files Ja und, wieso ist das ein Problem? Hmm ich glaub ich hatte nicht genau verstanden was Du meinst,.. meintest Du per Hand raussuchen und löschen? Ich meinte IIRC (hast ja den entscheidenden Teil abgeschnitten) das du die Dateien die dpkg
Re: Allgemeine Fragen zum Package System
Andreas Pakulat wrote: Sag mal kannst du das CC an mich bitte lassen. Ich lese die Liste mit. logo.. Ja,.. Problem ist nur folgendes,... manchmal passt mir das so wie sich der jeweilige Package maintainer das gedacht hat nicht und ich setzte des A flag in aptitude auch bei packages die nur suggested werden oder recommented. Gut für die gibts noch die optionen aptitude:keep-foo true; aber,... manchmal mach ich das auch bei Paketen die nicht mal dependet werden. Hmm, du installierst ein Recommends oder Suggests also manuell und setzt dann das A-Flag darauf? Ja,... ich mein du hast schon recht,... debfoster wär auch ne möglichkeit,.. aber mir _persönlich_ gefällt des net so... Beispiel: Ich brauch card reader um mich im Sicherheitsnetz vom Cluster einloggen zu können: Deswegen hab ich pcscd installiert und auch pcsc-tools. Die pcscd dependet nicht auf den tools, suggested und recommendet sie auch nicht aber trotzdem setz ich sie auf automatic, dass ich drann denke sie auch zu löschen wenn ich mal pcscd löschen sollte Hmm, aber will aptitude dass dann nicht bei jedem Upgrade entfernen, weil kein Paket darauf depended? Das waere mir naemlich zu muehselig Ja bei suggested und recommendet gibts da extra optionen für (siehe aptitude doc),... bei gar nix leider net,.. btw: kennt jemand ne Möglichkeit ne liste aller Pakete ausgeben zu lassen mit ihrem status ob sie Automatic sind oder nicht? dpkg -l zeigt des leider net an Mit aptitude und seinen Search Pattern sollte das gehen. aptitude-doc-en installieren und lesen. hmm muss ich wohl noch mal machen,.. habs vorher nur überfolgen... Ich sagte es taugt MIR nicht,... des tool mag schon gut sein,.. aber es passt nicht zu MEINEN persönlichen Gewohnheiten Deswegen musst du nicht gleich laut werden. Das war nicht als laut werden gedacht,.. sondern nur als Betonung,... hätte auch _mir_ nehmen können ;-) Ich meinte IIRC (hast ja den entscheidenden Teil abgeschnitten) das du die Dateien die dpkg nicht entfernen kann beim Purge von Hand loeschen musst damits sauber ist. Aso,.. ja aber ich meinte das generell,... weil es lassen ja viele Pakete ihren Müll übrig,.. auch wenn man sie purged... [1] @ Andreas also das mit dem freundlich sein bzw. ähnliches des hatten wir ja eigentlich vorher schon... Bin ich unfreundlich? Empfinde ich nicht so. Dann hatte ich das wohl falsch empfunden und nehme das vorher folgende zurück Vielleicht reagier ich ja nur über - dann entschuldige ich mich gleich im vorraus - aber so beiläufige Kommentare wie Aber das weisst du als sid-Nutzer ja alles schon kommen mir doch ein wenig verarschend vor Ich meinte das an den jeweiligen Stellen schon ernst, als Sid-Nutzer solltest du changelogs und NEWS lesen um mit Aenderungen klarkommen zu koennen. Wenn du das nicht tust solltest du dich nicht beschweren wenn was kaputt geht. Was das zuviel Freizeit anbelangt, auch das meinte ich so, sonst nutzt man wohl nicht Sid oder? Ich hab nie behaptet, dass ich changelogs/news nicht lese,... ich suchte ja nur nach ner für mich geeigneteren Methodik tote Pakete zu löschen... Und man kann sid auch recht gut verwenden ohne, dass man aufmerksam mitließt in der community und so,... Wenn ich des mal vergleiche mit suse aus dem RZ oder redhat von der uni,... da ist debian unstable immer noch so stable wie deren normales release... ;) Ich will hier keine Angst machen, Sid ist fuer eine in staendiger Entwicklung befindliche Distribution ziemlich stabil, aber dennoch gibts immer wieder Probleme und diverse Kleinigkeiten. Ja klar,.. seh ich auch so.. Noe, aber deine erste Frage ist eine Frage die man sofort beantworten kann wenn man sich etwas mit dem Paketsystem auskennt - was man als Sid Nutzer sollte - oder aber man sollte schleunigst mit dem lesen anfangen. Ok... ich geb ja zu, dass es nicht so helle war zu fragen, ob s.d.o bei sid sinnmacht,.. allein schon die dependencies machen einem da ja bald nen stric durch die Rechnung... Aber wenn Du meine Ursprüngliche email ansiehst,... da war es grad 03:00 oder so, und da war ich schon unstable ;-) Und da ich des 64bit deb hier grad aufgesetzt habe und per default noch ein s.d.o in der sources.list war... und mir aptitude dann tatsähclich bei lynx ein sec-update vorschlug,... hat mich des etwas verwirrt. aber das heißt nicht, dass ich dumm/ähnliches bin, Das wollte ich nicht unterstellen. Dann ist ja alles gut :-) sondern nur, dass ich mich in den Themenbereich (hier apt) noch nicht so eingearbeitet habe Also ich gehe mal davon aus dass du dabei bist dich einzuarbeiten ins Paketsystem, das ist wirklich wichtig um mit Sid auf Dauer klar zu kommen. Hmm sagen wir mal so,.. ich nutze debian seit,.. 2.0 weis gar nimmer den namen,.. hamm? egal,.. bisher kam ich immer ganz gut zurecht... ;-) Nein, ich wollte deine Intelligenz nicht anzweifeln, nur ob dein Wissensstand bzgl.
Re: Allgemeine Fragen zum Package System
On 12.01.06 23:44:24, Christoph Anton Mitterer wrote: Andreas Pakulat wrote: Sag mal kannst du das CC an mich bitte lassen. Ich lese die Liste mit. logo.. Danke. Hmm, du installierst ein Recommends oder Suggests also manuell und setzt dann das A-Flag darauf? Ja,... ich mein du hast schon recht,... debfoster wär auch ne möglichkeit,.. aber mir _persönlich_ gefällt des net so... Mir auch nicht, insbesondere weil ich erst die Anleitung waelzen muesste um zu verstehen was er mir da fuer jedes Paket auflistet... Neee, dann sortiere ich lieber mit aptitude ab und zu mal aus. Hmm, aber will aptitude dass dann nicht bei jedem Upgrade entfernen, weil kein Paket darauf depended? Das waere mir naemlich zu muehselig Ja bei suggested und recommendet gibts da extra optionen für (siehe aptitude doc),... bei gar nix leider net,.. Hab ich nicht gewusst, weil noch nicht gebraucht... Mit aptitude und seinen Search Pattern sollte das gehen. aptitude-doc-en installieren und lesen. hmm muss ich wohl noch mal machen,.. habs vorher nur überfolgen... Ist IMHO ziemlich gut, jedenfalls eines der besten User Manuals das ich bisher zu Systemtools gelesen habe. Wollte auch mal ne dt. Uebersetzung schreiben, hab aber recht schnell aufgegeben, wg. der Zeit... Ich sagte es taugt MIR nicht,... des tool mag schon gut sein,.. aber es passt nicht zu MEINEN persönlichen Gewohnheiten Deswegen musst du nicht gleich laut werden. Das war nicht als laut werden gedacht,.. sondern nur als Betonung,... hätte auch _mir_ nehmen können ;-) Also ich kenne _das_ als hervorheben und DAS als schreien... Sag mal, ist das eigentlich bei deinem MUA normal dass er ueberall ne extra Leerzeile einfuegt? Ich meinte IIRC (hast ja den entscheidenden Teil abgeschnitten) das du die Dateien die dpkg nicht entfernen kann beim Purge von Hand loeschen musst damits sauber ist. Aso,.. ja aber ich meinte das generell,... weil es lassen ja viele Pakete ihren Müll übrig,.. auch wenn man sie purged... Wenn du ein Paket findest dass nicht hinter sich aufraeumt (Dateien in /etc, /usr, /lib, /bin, /sbin u.U. auch /var), dann schreib nen Bugreport gegen das Paket. Das darf naemlich nicht sein, einzige Ausnahme sind Daten und Logs in /var. Ich kenn die Debian-Policy nicht genau aber IIRC duerfen Datenbanken ihre Datenbanken in /var liegen lassen und ebenso duerfen Logdateien in /var/log liegenbleiben. Kann natuerlich immer mal sein, das ein Paket ein nicht-leeres Verzeichnis nicht loeschen kann weil ein anderes Paket dort ne Datei reingelegt hat. Und man kann sid auch recht gut verwenden ohne, dass man aufmerksam mitließt in der community und so,... Mag sein, ich hab hier auf der ML viel Hilfe bekommen in der Anfangszeit (und bekomme die auf anderen ML's immernoch), da will ich auch was zurueckgeben. Monetaere Spenden kommen fuer mich leider (noch) nicht in Frage, also helfe ich mit RatTat soweit moeglich und mit Bugreports... Wenn ich des mal vergleiche mit suse aus dem RZ oder redhat von der uni,... da ist debian unstable immer noch so stable wie deren normales release... ;) :-) Kommt mir irgendwie bekannt vor... Noe, aber deine erste Frage ist eine Frage die man sofort beantworten kann wenn man sich etwas mit dem Paketsystem auskennt - was man als Sid Nutzer sollte - oder aber man sollte schleunigst mit dem lesen anfangen. Ok... ich geb ja zu, dass es nicht so helle war zu fragen, ob s.d.o bei sid sinnmacht,.. allein schon die dependencies machen einem da ja bald nen stric durch die Rechnung... Nee, der eigentliche Grund warum es keine security-Updates fuer sid gibt ist, dass die security-updates ganz einfach in einer neuen Paketversion aufgehen. Fuer Etch und Sarge gibts security-Updates damit moeglichst schnell (bzw. bei Sarg ueberhaupt) Sicherheitsloecher gestopft werden. Bei etch wuerde es sonst zwischen 2-10 und X Tagen dauern bis das Loch gestopft ist - auch nicht grade schoen. Aber wenn Du meine Ursprüngliche email ansiehst,... da war es grad 03:00 oder so, und da war ich schon unstable ;-) Nee, nee - nu such mal nicht nach Ausreden ;-) Und da ich des 64bit deb hier grad aufgesetzt habe und per default noch ein s.d.o in der sources.list war... und mir aptitude dann tatsähclich bei lynx ein sec-update vorschlug,... hat mich des etwas verwirrt. Oh, interessant. Nagut, es sei dir diese Frage verziehen ;-) sondern nur, dass ich mich in den Themenbereich (hier apt) noch nicht so eingearbeitet habe Also ich gehe mal davon aus dass du dabei bist dich einzuarbeiten ins Paketsystem, das ist wirklich wichtig um mit Sid auf Dauer klar zu kommen. Hmm sagen wir mal so,.. ich nutze debian seit,.. 2.0 weis gar nimmer den namen,.. hamm? egal,.. bisher kam ich immer ganz gut zurecht... ;-) Hmm, tja da hab ich von deinen Fragen leider etwas falsches gefolgert. Mein Fehler, passiert hoffentlich nicht wieder. Nein, ich wollte deine Intelligenz nicht
Re: Allgemeine Fragen zum Package System
Andreas Pakulat wrote: Sag mal kannst du das CC an mich bitte lassen. Ich lese die Liste mit. logo.. Danke. Des doofe an meinen client (TB,... wird Zeit dass ich auf was vernünfitges umsteige ;-) )... ist nur dass er bei Reply,.. nur an dich schickt und bei reply-all,.. auch an dich... Mir auch nicht, insbesondere weil ich erst die Anleitung waelzen muesste um zu verstehen was er mir da fuer jedes Paket auflistet... Neee, dann sortiere ich lieber mit aptitude ab und zu mal aus. Hmm ja,... eben,... ich will auch mein aptitude behalten,.. hmm evtl werd ich mein muster komplett umändern und des doch nur so machen, dass ich die auf A setzte die wirklich dependen... Auf jeden fall sollte es ein feature geben, dass -anzeigt wenn bei nem package update zwischen zwei versionen dependencies entfallen,... -und beim update sollten nicht nur recommendet packages angezeigt werden sondern auch suggested... Oder was noch besser wäre,.. wenn aptitude den A status selber nie überschreibt... (löscht) Ja bei suggested und recommendet gibts da extra optionen für (siehe aptitude doc),... bei gar nix leider net,.. Hab ich nicht gewusst, weil noch nicht gebraucht... d.h. Du machst es so, dass Du alles was suggested ist (wenn du es willst),... auch manuell reinsetzt? Mit aptitude und seinen Search Pattern sollte das gehen. aptitude-doc-en installieren und lesen. hmm muss ich wohl noch mal machen,.. habs vorher nur überfolgen... Ist IMHO ziemlich gut, jedenfalls eines der besten User Manuals das ich bisher zu Systemtools gelesen habe. Wollte auch mal ne dt. Uebersetzung schreiben, hab aber recht schnell aufgegeben, wg. der Zeit... Hmm,.. ja habs gesehen,.. geht recht einfach was ich wollte *g* Ich werd mich jetzt mal durch die ganzen APT/dpkg doku wälzen müssen *seufz* x apt-* packages voller nützlicher tools,... Das war nicht als laut werden gedacht,.. sondern nur als Betonung,... hätte auch _mir_ nehmen können ;-) Also ich kenne _das_ als hervorheben und DAS als schreien... hmm,.. man müsste mal ein RFC Standard für emoticons/etc aufsetzen,.. dass des mal homogenisiert wird... ich mein,.. wenns für brieftauben-tcp eins gibt,... Sag mal, ist das eigentlich bei deinem MUA normal dass er ueberall ne extra Leerzeile einfuegt? Ja,.. wie gesagt,.. der swtich wird wohl irgendwann fällig werden,.. es sei denn 1.5 macht alles besser,... aber mutt oder so taugt mir auch nicht, weil eigetlich nutze ich auch ganz gern MIME emails... Ich weis viele Leute wollen des net, aber ich finde es sollte komplett auf die umgestiegen werden... Wenn du ein Paket findest dass nicht hinter sich aufraeumt (Dateien in /etc, /usr, /lib, /bin, /sbin u.U. auch /var), dann schreib nen Bugreport gegen das Paket. Das darf naemlich nicht sein, einzige Ausnahme sind Daten und Logs in /var. Ich kenn die Debian-Policy nicht genau aber IIRC duerfen Datenbanken ihre Datenbanken in /var liegen lassen und ebenso duerfen Logdateien in /var/log liegenbleiben. Hmm var is klar,.. Was mir vorher grad auffiel,.. unter /etc/console/boottime.blah gibts ein .old ? Weis net ob des gerechtvertigt ist,... zumindest gehörts zu keinem Package.. Kann natuerlich immer mal sein, das ein Paket ein nicht-leeres Verzeichnis nicht loeschen kann weil ein anderes Paket dort ne Datei reingelegt hat. Ich find aber auch da sollte man sich was einfallen lassen,.. klar apt bzw. dpkg zeigt des an, aber wenn ich mal ein riesiges update fahre,.. kann man so schnell ja gar net guggen... Und man kann sid auch recht gut verwenden ohne, dass man aufmerksam mitließt in der community und so,... Mag sein, ich hab hier auf der ML viel Hilfe bekommen in der Anfangszeit (und bekomme die auf anderen ML's immernoch), da will ich auch was zurueckgeben. Monetaere Spenden kommen fuer mich leider (noch) nicht in Frage, also helfe ich mit RatTat soweit moeglich und mit Bugreports... Ja ist bei mir ähnlich,... will demnächst mal mit developen an debian,.. aber dazu fehlt mir noch zu viel Debian-internes wissen (z.B. apt ;-) ) Spenden tu ich schon immer gelgentlich,... wikipedia...jedit.. etc. Wenn ich des mal vergleiche mit suse aus dem RZ oder redhat von der uni,... da ist debian unstable immer noch so stable wie deren normales release... ;) :-) Kommt mir irgendwie bekannt vor... Des erste was ich gemacht hab war auf meinem Arbeitsnode ein deb zu installen,... da war der admin net so glücklich als der Rechner nimmer erreichbar war,... dann hab ich nen 2. Rechner bekommen *g* Ok... ich geb ja zu, dass es nicht so helle war zu fragen, ob s.d.o bei sid sinnmacht,.. allein schon die dependencies machen einem da ja bald nen stric durch die Rechnung... Nee, der eigentliche Grund warum es keine security-Updates fuer sid gibt ist, dass die security-updates ganz einfach in einer neuen Paketversion aufgehen. Ja gut,.. des war mir schon auch klar,... ABER wenn ein sec-hole da ist,.. dauer es evtl. bis
Re: Allgemeine Fragen zum Package System
Am Donnerstag 12 Januar 2006 02:59 schrieb Christoph Anton Mitterer: 1) Ich laufe generell auf sid. Ist es sinnvoll security.debian.org in die sources.list einzufügen? Oder sind die Packages in unstable eh immer neuer? Nein, macht keinen Sinn. Die Pakete von security.debian.org sind für stable gemacht. Das heißt sie bauen auch auf den Versionen aus stable auf (Bibliotheken, C-Compiler, ...). 2) Es gibt ja folgende mehr oder weniger offizielle trees: stable, testing, unstable, backports, volatile Seh ich des richtig, dass der Versionsaufbau immer so ist: stable = (security.debian.org =) backports = (security.debian.org security.debian.org wird wohl keine Backports unterstützen. Oder was kann man sonst noch tun gegen Paketleichen? Insbesondere auch, was kann man tun gegen Dateileichen die bei der deinstallation nicht mitgelöscht wurden? Regelmäßig aufräumen. Gruß Chris -- A: because it distrupts the normal process of thought Q: why is top posting frowned upon
Re: Allgemeine Fragen zum Package System
Hallo, Christoph Anton Mitterer [EMAIL PROTECTED] wrote: Hallo. Ich hätte mal ein paar Fragen zum Package System und allem was damit so zusammen hängt. Erst mal noch nicht aus der Sicht wie-macht-man-packages. Vorweg: Gibts da ne allgemeine allumfassende Doku zu? Ok, hier mal etwas konkretere Fragen: [...] Das sind ja jede Menge Fragen. Ich würde mich an deiner Stelle mal auf http://www.debian.org/doc/ begeben und mich durch die riesige Zahl von Manuals, Howtos und FAQs lesen. Danach sollte das meiste klar geworden sein. Wenn es dann doch um wie-macht-man-packages gehen sollte, bei deinen Interessen schau dir http://www.debian.org/devel/ und dort als Startpunkt insbesondere http://www.debian.org/doc/maint-guide/ und http://www.debian.org/doc/developers-reference/. Vieles der Dokumentation ist auch auf deutsch zu bekommen. Gruss, Frank -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
