stable mit einzelnen testing-Paketen ?

[daddel]

Hallo,

wie ich gelesen habe, gab es ähnliche Fragen schon etliche Male hier im Forum, aber meist ging es mehr um die generelle Frage, ob nun stable oder testing das Richtige für den entsprechenden Anwendungsfall ist. Ich würde aber gerne stable installieren und, weil ich Software entwickle, einige Pakete aus testing benutzen (keine ganzen Repos). Es würde mich auch interessieren, ob etwas dagegen spricht, ggf. auch einen anderen Kernel als den aus den aus den stable-Repos zu benutzen.

Meine "Gesinnungs"-Änderung resuliert aus der Tatsache, dass ich unter Manjaro/AUR mit Python Probleme bekommen habe, weil irgendwelche AUR-Pakete fehlerhaft waren und ich nicht weiter kam. Dann habe ich das Ganze einmal unter Debian-testing ausprobiert und es gab keinerlei Probleme. Auf der anderen Seite möchte ich aber, dass mein Betriebssystem selbst eine halbwegs feste Größe ist (stable), für meine Entwicklung es mir aber möglich ist, mit neueren Paketen zu arbeiten.

Mit APT kenne ich mich aber noch nicht so gut aus (mit pacman schon besser) und ich würde mich freuen, wenn Ihr mir dazu etwas sagen könntet.

Grüße
d

[ottonormal]

Hallo,
ich weiß nicht ob das für Dich hilfreich ist, aber ich habe nach dieser Anleitung:

http://www.linuxforme.de/2013/10/aktuel ... tallieren/

auf meinem Crunchbang (ist ja auch ein Debian Stable) den Kernel aktualisiert auf 3.13
Funktionierte super. Auch in einer VBox-Testinstallation mit wheezy.

[niesommer]

Hallo,
Also ein Stable mit Testing paketen habe ich noch nicht probiert, sofern Backports nicht als Testingpakete gelten. Aber deine Frage hat mich an einen Artikel erinnert: http://www.pro-linux.de/news/1/20798/de ... licht.html
http://tanglu.org/en/download/ Vielleicht ist das ja was du suchst.

[daddel]

@ottonormal
Also mit "apt-get install -t wheezy-backports xyz" installiert man Pakete, die aus Testing für "stable" erklärt wurden, wenn ich das noch richtig in Erinnerung habe ? Wie oft ändern sich denn die Backport-Repos ? Ist das ein ständiger Prozess ? Guter Link !

Kann man denn auch "apt-get install -t wheezy-testing xyz" machen ? Dann wäre meine Frage eigentlich schon fast beantwortet....

@niesommer
Tanglu 1.0 wäre auch eine gute Idee ! Das war mich jetzt noch garnicht über den Weg gelaufen. Momentan liebäugele ich mit SolydKBE. Werde mir aber direkt mal Tanglu anschauen. Danke für den Tip !

[smutbert]

(wheezy-testing gibt's nicht, aber die Pakete in wheezy-backports kommen, wie du selbst schon geschrieben hast, zumeist aus testing und werden extra für stable neu gebaut. Weil die Software für stable schon recht stabil sein sollten, ist Debian meiner Meinung nach auch bei den Backports sehr vorsichtig, aber das heißt nicht, dass es dort keine Update gibt: beim Kernel sind die Backports momentan zB updatedate mit testing, darktable hängt dagegen in der dritten Stelle der Versionsnummer um 1 hinterher... sehr viele Pakete dagegen schaffen es nie in die Backports weil die Abhängigkeiten zu umfangreich wären oder es aus irgendeinem Grund zu viel Arbeit oder sowieso sinnlos wäre)

Man kann jedenfalls beliebig viele Repositories und Zweige zur sources.list hinzufügen, also wheezy (stable), jessie (testing), unstable und experimental. Apt installiert normalerweise immer die neueste verfügbare Version, nur experimental und die Backports (wheezy-backports) haben von Haus aus eine niedrigere Priorität und müssen explizit installiert werden.

Abgesehen davon muss man den vorzugten Zweig selbst festlegen, damit man nicht grundsätzlich bei unstable landet. Ich habe das zB mit einer /etc/apt/preferences.d/debian-unstable (der Dateiname ist nicht wichtig) mit folgendem Inhalt gemacht:

Code: Alles auswählen

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 300

Will man eigentlich bei stable bleiben braucht man einen weiteren Absatz, um auch die Priorität von testing zu verringern, etwa

Code: Alles auswählen

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 310

Aber das geht nicht wirklich gut, weil Pakete aus testing Abhängigkeiten zu viel neueren Versionen haben, als sie in stable zur Verfügung stehen (zumindest mit fortgeschrittenerem Entwicklungszustand von testing, wie man ihn jetzt schon vorfindet) - da ist es wesentlich einfacher gleich zu testing zu wechseln.

Installieren kann man Pakete aus einem speziellen Zweig mit

Code: Alles auswählen

# apt-get -t unstable install Paket1 Paket2...
# apt-get install Paket1/unstable Paket2/testing Paket3/wheezy-backports...

Bei der ersten Variante erhalten die Pakete aus dem angegebenen Zweig eine höhere Priorität als alle anderen und das bei allen Paketoperationen (also auch bei automatisch installierten Abhängigkeiten), bei der zweiten Variante erzwingt man nur die Version für einzelne Pakete, für den Rest gilt immer noch die normale Konfiguration von apt.

Die beiden Varianten lassen sich auch kombinieren:

Code: Alles auswählen

apt-get -t unstable install Paket5/testing

um etwa wie hier ein Paket aus testing zu installieren, desssen Abhängigkeiten aber möglichst mit Paketen aus unstable zu erfüllen.

Hier im Wiki gibt's auch einen Artikel über Pinning http://wiki.debianforum.de/Pinning (so nennt man das)

[Apfelmann]

Ich habe es folgendermaßen gemacht

wheezy installiert, wobei ich nur ein Minimalsystem aufsetze,
alle notwendigen Programme einspielen
apt-get install xxx xxx die Pakete werden durch ein Leerzeichen getrennt

ich habe auch alte und Lieblingsprogramme als deb-dateien, zB. aus kde 1
dpkg -i xxx
mit apt-get -f install werden fehlende Abhängigkeiten aufgelöst

danach in der sources.list als root mit einem Texteditor testing eingetragen, zB.
deb http://cdn.debian.net/debian/ sid main contrib non-free
apt-get update
danach
apt-get install xxx xxx -d
für die gewünschten Pakete zum herunterladen
oder auch direkt installieren, dann ohne -d

die sources.list wieder auf stable setzen
apt-get update nicht vergessen
die heruntergeladenen Programme einspielen
und mit apt-get -f install die Abhängigkeiten auflösen

Wenn Pakete gehalten werden sollen, nach der Installation nicht mehr verändert werden sollen
echo xxx hold|dpkg --set-selections

Bei solchen Aktionen macht es Sinn die Testing Pakete nur herunterzuladen
und im Textmodus die Installation anschließend durchzuführen
manchmal gibt es erhebliche Änderungen und Abhängigkeiten die bei laufender Grafik gefährlich sind

Frohes Schaffen

[daddel]

@smutbert
Ok ! Danke für die Mühe, die Du Dir gemacht hast ! Jetzt habe ich es halbwegs kapiert. D.h., mit den Prioritäten kann ich im Prinzip alle Repos in die sources.list schreiben und ihnen dann entsprechende Reihenfolge geben oder halt direkt ("unbetreut" von den Repos) aus den entsprechenden Repos installieren. Eine priorisierte und ausgeklügelte sources.list hat aber den riesigen Vorteil, dass man vor einer Installation mit einem Paketmanager erst mal "recherchieren" kann.

Früher hatte ich dieses Problem noch nicht, aber da habeń mich diese Prios schon ein wenig abgeschreckt, weil ich nicht rausbekommen hatte, was die Zahlen genau bedeuten (300...). Also hatte ich immer eine "Standard-APT-Repo-Einrichtung benutzt.

Aber allzu viel turnen möchte ich ja gar nicht, es geht mir nur drum, wenn es z.B. ein bestimmtes Python-Paket gibt, dass ich es auch bekomme, auch, wenn es neuer ist. Und ich möchte auch gerne in den Genuss von Updates kommen, wenn es sie gibt, weil in neueren Paketen häufig noch an den Bugs gearbeitet wird. Für mein ganzes Rest-System ist es mir wichtig, dass alles läuft und ich nicht dauernd updaten muss. Ich denke mal, dass Security-Updates bei Debian regelmässig erfolgen, bzw. dann, wenn Sicherheitslücken in Paketen gefixt wurden.

Ansonsten geht mir das ständige Updaten wie bei einer Rolling Release oder Windings eigentlich nur auf die Nerven. Bei Linux kann man immer noch zusätzlich das "Glück" haben, dass man danach wieder rumfrickeln muss und aus der Arbeit rausgerissen wird...

@Apfelmann
das ist ja auch mal ne geckige Methode ! Behält APT denn die Abhängigkeiten auch von lediglich heruntergeladenen Paketen oder kann es sein, dass durch eine reguläre Installation eines anderen Paketes diese verloren gehen können ?

APT ist ja ganz schön kompliziert im Vergleich zu z.B. pacman, aber jetzt will ich es doch mal richtig lernen, obwohl ich immer noch ein paar Ängte vor der Kommandozeile habe (deshalb nenne ich mich auch Daddel, wegen Ex-Win-Klicker ).

[peschmae]

Meine Einschätzung ist, dass ein Mischsystem stable/testing oft schwieriger zu händeln und updaten ist als ein reines testing-System. Insbesondere erfordert es viel mehr Einblick in die ganzen Mechanismen zur Paketpriorisierung (die erwähnten /etc/apt/preferences.d, dpkg --set-selections, etc). Ausserdem ziehen die Abhängigkeiten gerne mal viele grundlegenden Bibliotheken (libc, etc) in neueren Versionen nach.

Der einzige Ort wo ich das bisher für Sinnvoll gehalten habe und dementsprechend auch mache, ist auf einem Server auf dem ich ein neueres dnsmasq benötige, als bei Debian Stable mit dabei ist. Das hat dann aber auch praktisch keine Abhängigkeiten und ist somit sehr gut unabhängig vom Rest aktualisierbar...

Ich habe zum Entwickeln - auch beruflich - im Moment sogar nur Debian unstable-Systeme am laufen. Klar geht da zwischendurch mal was kaputt (typischerweise der Nvidia-Treiber, der Rest ist sehr stabil), aber wenn man sichs mal nicht leisten kann, dann macht man halt eine Woche oder zwei keine Updates...

MfG Peschmä

[daddel]

Ja, gar nicht mischen, genau das ist meine Conclusion für dieses Problem. Ich kann mir eigentlich auch gar nicht vorstellen, dass Mischungen von unterschiedlichen stages nicht doch irgendwann schiefgehen. Deshalb habe ich jetzt auch testing installiert, weil ich auch an vielen anderen Stellen gelesen habe, dass Testing weitestgehend stabil ist. Und vielleicht habe ich ja mit AMD, was den Grafik-Treiber angeht, da jetzt mit meinem neuen Rechner weniger Probleme.

Für meine momentane Python-Entwicklung (Qt, erst mal für Desktop, mit DB und Grafik) ist Debian übrigens echt ne gute Sache. Einige Sachen laufen auf Anhieb, bei denen ich bislang ziemlich fummeln musste.

Ich danke Euch für den Mega-Support !

[rendegast]

... auf einem Server auf dem ich ein neueres Debiandnsmasq benötige, als bei Debian Stable mit dabei ist.
Das hat dann aber auch praktisch keine Abhängigkeiten und ist somit sehr gut unabhängig vom Rest aktualisierbar...

?
In dnsmasq die Konfig, in dnsmasq-base das binary, welches von höherer libc abhängt.
Keine gravierende Abhängigkeit?

[peschmae]

Naja, hab ja nicht gesagt dass mein dnsmasq das letzte ist was jemals in testing aufgetaucht ist
Hab auch nicht gesagt dass ich das nicht selber kompiliert hätte damit die Abhängigkeiten passen. Insofern ist libc kaum je gravierend, das Interface ändert sich ja im Normalfall nicht.
Hab noch weniger gesagt dass ich mich an solche Kleinigkeiten jeweils genau erinnere. Ist ja ein Illustrationsbeispiel und nicht eine Anleitung zum ewigen Glück mit dnsmasq.

MfG Peschmä

[Apfelmann]

Hallo,

Die Abhängigkeiten werden beim Herunterladen mit aufgelöst,
wichtig ist aber immer dabei die Kontrolle über Pakete, die entfernt oder aktualisiert werden sollen

LG

[peschmae]

Natürlich, aber das macht die Idee einfach mal schnell die libc bei einem Stable-System auszutauschen nicht zu einer guten solchen

[daddel]

Ist es denn kritisch, ab und zu mal ein deb-Paket aus vertrauenswürdiger Quelle zu installieren ? Einige Programme konnte ich nämlich in den Testing-Repos nicht finden, wie z.B. so harmlose (?) Sachen wie TV-Browser oder RssOwl. Die habe ich dann (mit schlechtem Gewissen ) direkt von den Projekt-Websites runtergeladen und installiert.

Was mich auch noch interessiert ist, wie das mit Tarballs bei Debian aussieht (z.B. aus Git oder Sourceforge). Sollte man sich das komplett verkneifen ? Unter Manjaro/Arch mit Pacman konnte ich das ohne Probleme machen (wenn sie nicht buggy waren ).

[peschmae]

Das ist nicht per se ein Problem. Allerdings ist das mit dem Desinstallieren meist nicht so einfach, wenn du Programme aus den Quellen installiert hast.

checkinstall hilft und erstellt ein "billiges" Debian-Paket was man dann auch wieder loswird. Ich mach das meist aber eher von Hand - pro Programm ein Ordner in /opt oder auch bei mir im Homeverzeichnis nach ~/local

Deb-Pakete aus "vertrauenswürdigen" Quellen wäre ich sehr vorsichtig. Ist meist problemlos wenns nur um ein einzelnes Programm geht (z.B. Qgis oder so), aber schwieriger wenns um Systembibliotheken geht (wie z.B. die Debian-Multimedia Sachen die oft zu Bugs geführt haben die dann im Debian-Bugtracker aufschlagen und gar nicht aus Debian kommen...)

MfG Peschmä