Re: automake alternatives
Am Montag, den 11.04.2005, 13:14 +0200 schrieb Thomas Jahns:
> Daniel Leidert <daniel.leidert.spam@gmx.net> writes:
> > Am Donnerstag, den 07.04.2005, 00:17 +0200 schrieb Thomas Jahns:
> > > Daniel Leidert <daniel.leidert.spam@gmx.net> 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
> > > > >
> > > > > tjahns@mercury:~ > 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
Reply to: