dselect, kein Raum fuer individualitaet?

[treo]

Hi,

so, dselect ist ja ein nettes tool, aber es geht mir gewaltig auf den Wecker... normalerweise habe ich stable eintragen, nun moechte ich aber MySQL 4.0.13 aus testing installieren (ich will mit den neuen Features experimentieren)... wenn ich die Quelle aendere geht das soweit auch ganz gut, nur das Problem ist das nun versucht wird bewaerte Programme zu ersetzen (z.B. gcc 3.3 etc.)... das will ich aber nicht, das einzige was ich erreichen will ist das ich MySQL 4.0.13 installiere und danach zurueck auf stable wechsle...
Gibt es da eine Moeglichkeit dselect von solchem Mist abzuhalten?

Ich kann mir MySQL auch als Source ziehen und das dann selber kompilieren... nur wuerde ich schon gerne Einheitlich zusammen mit dselect arbeiten...

Wuerde mich auch mal interesieren wie ihr das so geloest habt, besonders auch auf Arbeitsservern (nur .deb Pakete, Mischung oder sehr vieles selbst kompiliert?)

CU Treo

[captaincrunch]

Wuerde mich auch mal interesieren wie ihr das so geloest habt, besonders auch auf Arbeitsservern (nur .deb Pakete, Mischung oder sehr vieles selbst kompiliert?)

1. Ausschließlich original stable-Debs verwendet (bis auf Horde / IMP)
2. Sofern es unbedingt Pakete aus testing / unstable sein sollen, erstelle ich einen Backport des Pakets
3. dselect komplett außen vor lassen, und nur per apt-get apt-cache arbeiten ... ;)

[jtb]

warum ein Backport erstellen?
per apt-get installieren reicht doch auch..

[dea]

Treo: Lies Dir die Doku zu apt und dpkg durch (auf debian.org und die manpages), das Zeug ist wunderbar flexibel. So kannst Du beispielsweise ein "Default-Release" (z.B. stable) festlegen und bleibst dann auch bei einem apt-get upgrade von unsinnigen Aktualisierungen verschont trotzdem die Sourcen für testing und unstable in Deiner sources.list stehen.

Allerdings, und das ist bei rpm nicht anders, funktioniert das nur, solange das gewünschte Paket aus testing oder unstable nicht mit Abhängigkeiten auf Pakete in testing oder unstable belegt ist. In solchen Fällen hilft Dir nur ein Backport weiter (http://www.apt-get.org ist so ziemlich die beste Adresse für sowas)

Nette Oberflächen für apt/dpkg sind übrigen auch noch aptitude (ncurses/CLI) und synaptic (GUI), auch KPackage f. KDE tut ganz gut ...

[captaincrunch]

@Jtb :

warum ein Backport erstellen?
per apt-get installieren reicht doch auch..

Da ich keine große Lust habe, erst massig Pinning-Angaben zu machen, um nicht wegen eines dösigen Pakets eine neue glibc und zwanzig weitere neue Pakete auf der Kiste zu haben, erstelle ich mir halt einen kleinen Backport der testing / unstable-Pakete, was auch nicht viel schwieriger ist, als das Pinning reichtig zu konfigurieren.

[jtb]

äähm, ich weiß nicht, aber ich installiere immer mit apt-get install package/testing falls ich ein Packet aus Testing benötige..

Wie löst du den die Probleme mit glic? Installieren musst du es doch trotzdem..

[captaincrunch]

äähm, ich weiß nicht, aber ich installiere immer mit apt-get install package/testing falls ich ein Packet aus Testing benötige..

In dem Fall wirst du aber zumindestens dein Default-Release festgelegt haben, ansonsten ziehen die meisten Pakete aus testing / unstable massive Abhängigkeiten (meistens in Form einer neuen glibc) nach sich, weshalb selbst die Debian-Maintainer momentan davon abraten, ein gemischtes System zu fahren.

Wie löst du den die Probleme mit glic? Installieren musst du es doch trotzdem..

Bei einem Backport wird gegen die alte glibc kompiliert, wodurch sich das Problem da gar nicht stellt ... ;)

[jtb]

ok..
ich überlege z.Z. den Server zu wechseln (Hetzner wg. mehr RAM) und dann will ich auch das neue libc, so dass ich dann das Problem nicht mehr habe..

Nervt mich z.Z. nämlich sehr (neue SA-Version, Apache2, Subversion usw)

[captaincrunch]

ich überlege z.Z. den Server zu wechseln (Hetzner wg. mehr RAM) und dann will ich auch das neue libc, so dass ich dann das Problem nicht mehr habe..

So lange du dabei "nur" von testing redest, sollte das auch nicht das Problem sein, im unstable war die glibc aber vor nicht allzu langer Zeit ziemlich lange broken, was zu teilweise massiven Problemen geführt hatte.

Nervt mich z.Z. nämlich sehr (neue SA-Version, Apache2, Subversion usw)

Wie schon gesagt : Backports wären da wohl die einfachere Lösung ... ;)

[jtb]

dafür habe ich doch AFAIK nicht mehr die Vorteile von apt-get und automatischen Updates?

[captaincrunch]

dafür habe ich doch AFAIK nicht mehr die Vorteile von apt-get und automatischen Updates?

OK, das nicht, auf der anderen Seite aber auch nicht den Ã?rger, wenn dann doch mal etwas nicht so rund läuft, wie man es von Debian gewohnt ist ... ;)

Ist halt größtenteils eine Einstellungssache, und wenn du bei testing bleibst, kannst du trotz allem davon ausgehen, dass keine größeren Probleme auftreten werden. Bei dir mache ich mir da ohnehin keine großen Sorgen ... ;)

[phil]

Ein Grund mehr Debian zu lieben:

wollte MySQL 4 ausprobieren, speziell wegen Caching.

mysql und apache gestopt.
apt-get remove mysql-server, client php4 php4-mysql etc.
deb http://debian.moolfreet.com ./ in sources.list rein. apt-get update.
was ich gerade deinstalliert hatte wieder per apt-get installiert.
apache und mysql neugestartet.

bisher läuft alles wunderbar und aktueller phpmyadmin ist auch dabei.

Merci an Capt. Crunch für das Stichwort Backports ;-)