Wie verwaltet ihr eure packete so?

[nubla]

Hi,
ich bin grad dabei debian (hier etch) ein wenig näher kennenzulernen. Leider ist stable ja nicht gerade sehr aktuell und ich blick bei den ganzen apt möglichkeiten noch nicht so ganz durch (mischen und so). Also was macht ihr, wenn ihr ein ein packet braucht, was im stable nicht drin ist bzw. zu alt ist? Selber kompilieren, stable/testing/unstable mischen (wenn ja wie am besten), ganz auf testing/unstable umstellen oder irgend eine andere methode? Also wer ein paar gute statements hat nur zu

[Strunz_1975]

Hallo,

ich habe zum Beispiel meine Sources.list auf Testing umgestellt!
Jetzt habe ich so ziehmlich die neuesten Programme am laufen.

Ein mischen der Liste würde ich nicht empfehlen.

cu
Strunz_1975

[nubla]

Naja, testing ist ja bei einigen packeten auch nicht sehr aktuell (bsp. snort2.3). Was ist z.b der beste weg, wenn ein packet/packetversion nur im unstable vorliegt? Auf nummer sicher und mit nem tgz und dem dreisatz oder existiert da ne elegantere methode? Weil in einigen situationen müssen ja auch neuere versionen von evtl. abhängigkeiten des eigentlich gewünschten packets berücksichtigt werden.

[rolo]

hi,
in den meisten fällen ist dies ein besserer weg software zu installieren, wenn mann kein packet aus dem debian repository installieren will oder kann.
gerade bei einer aktuellen snort installation hatte ich vor kurzem leider probleme damit, und hab es dann über dem "traditonellen" weg (make, make install) installiert.
bye

[nubla]

gerade bei einer aktuellen snort installation hatte ich vor kurzem leider probleme damit, und hab es dann über dem "traditonellen" weg (make, make install) installiert.

Ja auf den gedanken bin ich für produktionssysteme auch langsam wieder zurück. Aber ich bin ein wenig neugierig über den einsatz von debian als workstation geworden. Und da isses ja auch immer schön, packete so aktuell wie möglich zu haben, ohne ne menge zu riskieren. Da muss doch für debian irgendein guter spagat möglich sein, oder irr ich mich da?

z.B.: Eine neuere kde-version mit all ihren abhängigkeiten per hand zu installieren, kann mit konfiguration, patchen, usw. zu einer reinen installationsorgie ausarten (mal wieder eines der komplexesten beispiele ausgewählt )

[Mike1985]

Hallo!
Für eine Workstation eignet sich testing sicher am besten, aber gerade bei dist-upgrades muss man halt schon wissen, was passiert, und was man tun sollte, wenn der Paketmanager die Konflikte nicht mehr selbst auflösen kann.

Und wenn man eine aktuelle Version braucht, dann ist die beste Möglichkeit, den Source, wenn die neuere Version schon in unstable ist, diesen dort zu holen (mittels apt-get source xxx), und diesen dann mittels dpkg-buildpackage für den eigenen gebrauch kompilieren, danach hat man ein *.deb, welches man schön installieren kann

mfg mike

[uljanow]

Es gibt ja auch noch backports auf stable. Aber wenn es nur ein Paket mit wenig Abhängigkeiten ist, nehme ich direkt testing oder unstable Versionen (vorausgesetzt ich brauche ein aktuelleres Release ).

[comes]

Also was macht ihr, wenn ihr ein ein packet braucht, was im stable nicht drin ist bzw. zu alt ist?

warten

Selber kompilieren, stable/testing/unstable mischen (wenn ja wie am besten)

japp, selber kompilieren und paketieren

[FitzeFatze]

Für eine Workstation eignet sich testing sicher am besten

ist sid wirklich schon so weit, "produktiv" als workstation eingesetzt zu werden?

[herrchen]

Für eine Workstation eignet sich testing sicher am besten

ist sid wirklich schon so weit, "produktiv" als workstation eingesetzt zu werden?

1. SID ist nicht "testing", sondern "unstable".
2. mit *solider* kenntnis des paketmanagements und einiger übung kann man SID zwar als WKS betreiben, aber es kann eben immer passieren, dass das paket, was man gerade dringend braucht, einige unschöne fehler hat. dann geht das gefrickel los ...

herrchen

ps: so, wie deine frage formuliert war, nimm' (noch) nicht SID.

[FitzeFatze]

Für eine Workstation eignet sich testing sicher am besten

ist sid wirklich schon so weit, "produktiv" als workstation eingesetzt zu werden?

1. SID ist nicht "testing", sondern "unstable".
2. mit *solider* kenntnis des paketmanagements und einiger übung kann man SID zwar als WKS betreiben, aber es kann eben immer passieren, dass das paket, was man gerade dringend braucht, einige unschöne fehler hat. dann geht das gefrickel los ...

herrchen

ps: so, wie deine frage formuliert war, nimm' (noch) nicht SID.

ja, danke!

aber etch - > sid -> lenny. oder nicht?

ciao

[Snoopy]

aber etch - > sid -> lenny. oder nicht?

???

Stand 31.08.2007 (und die nächsten paar Monde auch noch):
Etch => Stable
Lenny => Testing
SID => Unstable

SID ist SID und wird immer SID bleiben, soll heissen SID wird den Unstable-Status nie verändern.
Testing bekommt bei jedem Debian-Release einen neuen Namen und wandert somit durch die Releases.

[FitzeFatze]

Stand 31.08.2007 (und die nächsten paar Monde auch noch):
Etch => Stable
Lenny => Testing
SID => Unstable

ok, ich hab lenny und sid verwechselt. sorry, kommt nie wieder vor.

(daher auch oben meine wirren post;))

ciao

[garibaldi]

Apt Pinning ist hier sicher auch interessant. Gerade das erste Beispiel von mir deckt eine Mischung aus Testing und unstable ab.

Wenn die Pakete noch aktueller sein sollen als die .debs aus Unstable und daher selbst kompiliert werden müssen, ist immer vorzuziehen, selbst ein .deb. Ausser den schon aufgeführten Methoden kann man auch mit checkinstall vorgehen. Gegenüber der klassischen Dreisatzmethode hat dies den Vorteil, dass APT bescheid weiß und man mit evtl. Abhängigkeitsproblemen besser umgehen kann. Auch lässt sich das System so besser aufräumen.

Gruß, garibaldi

[nubla]

Hi,
erstmal danke für die vielen antworten. Das wird ne menge zum lesen
Hab mich für den anfang für die untere methode von Mike1985 entschieden. Nur leider wirft das mal wieder ein kleines problem auf. Wie kann ich am besten steuern, von welchen zweig er die sourcen runterlädt. Weil apt-get source foobar holt bei entsprechendem deb-src eintrag immer die sourcen aus unstable. Erst ein apt-get -t stable source foobar holt mir das entsprechende aus dem stable-zweig. Hab bei pinning nix zu src-pkgs gefunden und apt-cache policy zeigt mir auch keine src-quellen an. Weiß da wer was?

[garibaldi]

Weiß da wer was?

Salut,

Die Antwort steht in meinem link direkt über deinem

Gruß, garibaldi

[nubla]

z.B.:

Package: *
Pin: release a=testing
Pin-Priority: 990

Package mit Source ersetzen?

[garibaldi]

Package mit Source ersetzen?

Hmm, bin mir jetzt nicht sicher...

Was hast du überhapt jetzt vor, stable oder testing als Grundlage?

ps: siehe auch

Code: Alles auswählen

man apt_preferences

[nubla]

Für jetzt erstmal nur eine src aus unstable holen und dann eben auf stable backporten. Dabei soll das apt verhalten für die sourcen so sein, dass wenn ich ein apt-get source foobar mache ich die stable sourcen bekomme. Und erst bei einem apt-get -t unstable source foobar die unstable sourcen geladen werden. Zur zeit funzt es genau umgekehrt. Ist zwar nur ne kleine schönheitssache, aber wär halt schön wenn

[EDIT] Also stable als grundlage

[garibaldi]

Da musst du den Pin für die Pakete aus unstable niedriger als den von stable setzen, sicherheitshalber unter 100.

Probiers mal so:

Code: Alles auswählen

Package: *
Pin: release a=testing
Pin-Priority: 990

Package: *
Pin: release a=unstable
Pin-Priority: 90

Aber vor dem richtigen Einsatz die Ausgabe von

Code: Alles auswählen

apt-cache policy

überprüfen und mit "-s" simulieren

[nubla]

Funzt nicht. In apt-cache policy zeigt er wie gesagt auch keine sourcen an, nur die packages. Hab jetzt einfach mal noch Package mit Source ausgetauscht, aber da bockt er.

[garibaldi]

Ich hab's bisher nur mit "echten" Paketen gemacht, also da kann ich dir dann leider nicht weiterhelfen.

Sorry, viel Erfolg noch
garibaldi

[nubla]

Naja, vielleicht findet sich ja noch was. Aber eine frage tut sich grad noch bei mir auf. Gibt es einen unkomplizierten weg die packete, die apt-get build-dep installiert hat wieder loszuwerden? Oder ist der einzige weg, sich die packete aufschreiben und diese dann wieder gezielt mit apt-get remove zu deinstallieren?

[garibaldi]

Oder ist der einzige weg, sich die packete aufschreiben und diese dann wieder gezielt mit apt-get remove zu deinstallieren?

Och, die Pakete mit diesem Befehl zu deinstallieren, finde ich gar nicht kopliziert; und mit einem "--purge" werden dann auch die Konfigurationsdateien entfernt. Es ist jedenfalls einfacher, als im ganzen Wurzelverzeichnis die einzelnen libs und Co herauszusuchen, wenn man kein .deb baut.

Um die Übersicht zu behalten, läßt sich übrigens auch das Paket popularity-contest verwenden, durch welches man herausfinden kann, welche Pakete schon längere Zeit nicht mehr benutzt worden sind.