Am Montag, den 11.04.2005, 13:14 +0200 schrieb Thomas Jahns: > Daniel Leidert <[EMAIL PROTECTED]> writes: > > Am Donnerstag, den 07.04.2005, 00:17 +0200 schrieb Thomas Jahns: > > > Daniel Leidert <[EMAIL PROTECTED]> writes: > > > > Am Mittwoch, den 06.04.2005, 22:40 +0200 schrieb Thomas Jahns: > > > > > > > > > ich habe derzeit das Problem, da� in Debian Sid i386 die Dateien > > > > > /usr/bin/aclocal und /usr/bin/automake nicht existieren (das sollten > > > > > eigentlich symlinks nach /etc/alternatives sein). Installiert sind > > > > > > > > > > [EMAIL PROTECTED]:~ > dpkg -l 'automake*' > > > > [snip] > > > > > Die symlinks in /etc/alternatives hingegen existieren. > > > > > > > > > > Wei� zuf�llig einer der Mitlesenden, mit welcher Version der > > > > > automake-Pakete die Eintr�ge in /usr/bin verschwunden sind? > > > > > > > > K�nnte evtl. mit dem Entfernen von automake oder automake1.5 passiert > > > > sein (stehen ja beide auf p=purged - du hattest sie offenbar irgendwann > > > > installiert). Das sind AFAIK die einzigen Pakete, die /usr/bin/automake > > > > als Datei oder Symlink enthalten - vgl.: > > > > > > automake ist ein virtuelles Paket, > > > > Nein. > > > > > da� von allen automake1.?-Paketen zur > > > Verf�gung gestellt wird. > > > > Das ist automaken. > > Doch. ;-)
JFTP: Nein. > $ apt-cache show automake1.4 | grep ^Provides: | uniq > Provides: automaken, automake, automake1.4-doc > ^^^^^^^^ JFTP: Da steht, dass das Paket automake1.4 die selbe Funktionalit�t wie das Paket automake bietet. Der Blick auf die Versionsnummern offenbart auch den Grund. Das �ndert doch nichts daran, dass das Paket automake existiert (wenn auch nur noch in stable). Es ist kein virtuelles Paket. > apt-cache show automake hingegen liefert null output, weil eben kein > solches .deb in unstable enthalten ist. Deswegen ist automake nicht virtuell. Es existiert doch. Und wenn es irgendwann nicht mehr existiert, dann braucht man auch nicht mehr den 'automake'-Eintrag in "Provides:", denn das virtuelle Paket f�r automake ist 'automaken'. > > > automake1.5 ist in unstable nicht verf�gbar > > > (und inkompatibel mit automake1.4). > > > > Richtig. Mir ging es darum, dass automake und automake1.5 diese Datei > > anlegen und diese Pakete offensichtlich einmal bei dir installiert > > waren. Ich hatte vergessen, dass update-alternatives den/die Link(s) > > selbst�ndig wieder anlegen sollte. > > Das mag in Zeiten von woodys Release mal so gewesen sein, ich kann aber > nicht sehen, wie mir automake1.5 jetzt helfen soll. ?? Wie sollte es? automake und automake1.5 (welche du installiert hattest, sonst w�rde dpkg nicht 'pn' als Status anzeigen) nutzen nicht update-alternatives, sondern stellen /usr/bin/automake bzw. aclocal direkt zur Verf�gung. Beim Entfernen dieser beiden Pakete muss daher zwangsl�ufig auch /usr/bin/automake bzw. aclocal entfernt worden sein. Ich verga� nur, dass update-alternatives die Links wieder anlegen m�sste. Jetzt verstanden? Genau der Punkt hat aber offensichtlich bei dir nicht funktioniert, wenn ich [..] > Ich nehme an, da� ich irgendwann folgende Situation hatte (die Kiste ist > seit etwa 2002 auf sid), wenn ich von /usr/bin/automake schreibe, sind > /usr/bin/aclocal und andere genauso gemeint: > > - automake 1.4 ist installiert, /usr/bin/automake sind Dateien aus > automake 1.4, die von dpkg verwaltet werden > - automake1.7 wird installiert, update-alternatives l�uft, ersetzt aber > die Datei /usr/bin/automake nicht > - irgendwann sp�ter wird automake durch automake1.4 ersetzt, dabei > wird die Datei /usr/bin/automake gel�scht, aber weil bereits ein > Eintrag in den Daten von update-alternatives existiert nicht neu > angelegt. folge. Evtl. wurde dadurch /var/lib/dpkg/alternatives/automake auf manuell gesetzt. Dann wird IIRC der Link auch nicht angelegt. In dem Punkt k�nnte ich mich aber auch irren. MfG Daniel
