GELÖST:Metapakete erzeugen

[cartun]

Hey,

wenn ich nun mit dpkg ein lokales dummy*.deb Paket installiere weiß mein Paketmanager ja überhaupt nichts davon.
Pakete die aber vom dpkg eingerichteten Paket abhängen können somit ja nicht installiert werden obwohl das Paket im System vorhanden ist.

Ich habe gerade gelesen das man dem aus dem Weg gehen indem man "Metapackete" erstellen kann, dieses Paket dann installiert und schon weiß mein Paketmanager davon. Sehe ich das soweit richtig?

Was aber passiert wenn ich ein Paket zwar eingerichtet habe es aber nicht meinem Paketmanager mitteile?
Der zieht dann ja das Paket dummy.deb und installiert das (sowie die Anwendung die davon abhängt).

Dann zerschieß ich mir doch alles mögliche oder? Denn mein von Hand eingerichtetes Paket wird das einfach überschrieben oder was passiert dann?

*dummy= mir fällt nix bessere ein

[dawg]

Guckst du :

Code: Alles auswählen

# dpkg -i opera_10.10.4742.gcc4.qt3_i386.deb 
....

aber:

Code: Alles auswählen

...dpkg: dependency problems prevent configuration of opera:
 opera depends on libqt3-mt (>= 3.3.4); however:
  Package libqt3-mt is not installed...

also:

Code: Alles auswählen

# apt-get install -f

installiert opera +Abhängigkeiten. Und dann:

Code: Alles auswählen

# apt-cache policy opera
opera:
  Installed: 10.10.4742.gcc4.qt3

Und das klappt dann auch:

Code: Alles auswählen

# apt-get remove --purge opera

Code: Alles auswählen

# apt-cache policy opera
opera:
  Installed: (none)

Kann sein, dass Du die configure-make-make-install Prozedur meinst. Davon weiss der Paket-manager dann tatsächlich nichts. Das ist Mist, weshalb das Erstellen von deb-Paketen die bessere Vorgehensweise ist/sein soll (mit dpkg-buildpackage oder sonstigen Methoden: http://forums.debian.net/viewtopic.php? ... 76&start=0 und http://www.mepis.org/docs/en/index.php/ ... ding_Guide). Wenn denn das eigene Kompilieren wirklich notwendig ist. Ist es ja eigentlich nicht.
Von Metapaketen weiss ich nichts. Was nichts heisst.

[cartun]

Hey,

aha, also wenn dpkg Abhängigkeitsprobleme erkennt und eine Installation verweigert kann ich es apt weitergeben der das Problem dann löst?
Aber, ich dachte immer man soll das vermeiden dpkg und apt gleichzeitig zu verwenden?!?

Nehme es mir nicht ernst, ich habe mir ein fettes Debian-Buch gekauft und versuche alles zu verstehen doch irgendwie habe ich genau hier:
dpkg und apt Probleme.

dpkg installiert ein lokales Pakes was ich irgendwo her ab löst aber keine Abhängigkeiten >

>lieber nicht nutzen sondern nur apt

alles klar, was aber wenn ich ein programm habe das ich nur lokal installieren kann aber auch Abhängigkeit hat?

Da kann mir -was ich so alles gelesen habe- weder apt noch dpkg weiterhelfen?

Man... das packen meine grauen Zellen nicht mehr zu

[dawg]

alles klar, was aber wenn ich ein programm habe das ich nur lokal installieren kann aber auch Abhängigkeit hat?

Ich versuch's mal:
1)Wenn ich mit "dpkg -i paket.deb " installiere wird überprüft, ob die Abhangigkeiten gegeben sind.
Wenn von den Abhängigkeiten eine (oder mehrere) auf dem System nicht installiert sind,
gibt dpkg eine Fehlermeldun zu den entsprechenden Paketen.
Wenn die Abhängigkeiten gegeben sind wird das Paket installiert. Die Debian-Paket-Verwaltung weiss dann auch davon und alles ist prima.

2-)Wenn ein Paket nicht installiert werden kann, musst ich die Abhängigkeiten installieren.
Z.B. "apt-get install -f" installiert diese, und das entsprechende Paket in einem Rutsch mit.

3) Falls das Paket Abhängigkeiten hat, die in den Repositorien nicht zu finden sind, muss ich diese manuell herunterladen und ebenfalls mit "dpkg -i name_der_abhängigkeit.deb" installieren. Danach wieder "apt-get install -f"

4) Das kann schon mal bisschen Frickelei werden. Einfach, bei Paketen mit besonders vielen Abhängigkeiten, nach und nach alles installieren und -vor allem- Ruhe bewahren.


Lange Rede, kurzer Sinn:
Da die Debian-Repo's Pakete in grosser Zahl anbieten ist die Wahrscheinlichkeit ein deb-Paket mit "dpkg -i" installieren zu müssen eher gering. Gleiches gilt, wie gesagt, für's Kompilieren/Pakete selber bauen.
Du brauchst Dir darüber also eigentlich -erstmal- gar keine grossen Gedanken machen.

Falls Du tatsächlich in diese Lage kommst würde ich es einfach versuchen (läuft recht geschmeidig) und im Zweifelsfall nochmal nachfragen. Oder einfach spasseshalber mal ein kleines deb-Paket runterladen und installieren
(http://www.debian.org/distrib/packages). VirtualBox, opera, sowas in die Richtung geht auch.
Ich selber brauche das (dpkg) eigentlich so gut wie nie.
Das gesamte Paketmanagement mit dem automatischen Auflösen von Abhängigkeiten ist ja der eigentliche "Knaller" von Debian überhaupt. Zitat: "Jetzt was für Feinschmecker: das Debian-Paket-Management"

Das ist natürlich alles bloss meine Meinung, und kann unter Umständen anders gesehen werden.

[dawg]

Leider auf Englisch:
http://www.youtube.com/watch?v=lFzPrzY2KFM
und vieleicht auch ein bisschen viel des Guten. Klick einfach mal rein.

[KBDCALLS]

Mit gdebi läßt sich etwas vereinfachen. Man installiert das locale Paket, eventuelle Abhängigkeiten werden aus dem Netz gezogen. Metapakete haben den Zweck nur die Abhängigkeiten zu installieren. Das Paket KDE wäre so eins. Als Abhängigkeiten werden unter anderem kdegames ua. aufgeführt.

[cartun]

Hey,

danke, eure Antworten sind echt Gold wert!
Also, erkennt apt mit -f das mit dpkg versucht wurde ein Programm zu installieren was aber nicht geschah da die Abhängigkeiten nicht aufgelöst werden konnten und macht die Arbeit dann selbst? Sehe ich das so richtig? Welches ursprüngliche Paket nutzt Apt dann, das Lokale (was ich mit dpkg versucht habe zu installieren) oder zieht der selbst eins aus dem Netz?
Wenn erstes der Fall ist, dann hat APT echt super Kuh-Kräfte ... wie kommunizieren die beiden (dpkg und apt) so schön miteinander?

Langsam begreife ich es...
Zudem finde ich es so geil wenn man ein "fremdes" Paket aus dem Netz holt man es mit der MD5 Summe überprüfen kann ob die Prüfsumme mit deren aus apt-cache show paketname übereinstimmt. Was die leute sich alles dabei gedacht habe... Respekt.
Zwar kapiere ich den ganzen kram wie das mit dem Verschlüsseln (gpg usw.) funktioniert aber das ist echt ein anderes Thema

[Clio]

Nochmal, da wir das Thema hier schon sehr oft besprochen haben und auch ein Eintrag im Wiki vorliegt:

Der eigentliche Paketmanager ist dpkg.
Alles andere, wie apt, aptitude, dselect, synaptic, kpackage, smartpm oder adept (um mal die gebräuchlichsten zu nenen) sind nur wrapper bzw. grafische oder ncurses GUI's, die alle ausnahmslos auf dpkg aufsetzen.
Um es vereinfacht darzustellen:
Wenn Du mit dpkg -i ein Paket installierst, sprichst Du den Paketmanager direkt an. Hier werden dann keine evtl. abhängigen Pakete nachgeladen, sondern es erfolgt nur ein Hinweis auf die fehlenden Pakete.
Alle anderen Wrapper oder "Aufsätze" prüfen auf Abhängigkeiten und laden diese nach, sofern vorhanden.

[cartun]

Hey,

ja, das habe ich soweit verstanden
Mir war nur neu das ich die nicht aufgelösten Abhängigkeiten (die dpkg nicht lösen kann) mit apt-get install -f an apt weiterreichen kann.
Ich dachte, wenn ich mit dpkg versuche etwas zu installieren und es nicht klappt es nirgendwo vermerkt wird, aber apt kann es wohl aufgreifen und lösen. Sehe ich das soweit richtig?

Wenn ja, dann habe ich soweit alles verstanden

[Clio]

Nein, das bewirkt ein -f nicht.
Diese Option wird benutzt, um evtl. Fehler aufzulösen, die aus den unterschiedlichsten Gründen bei der Paketinstallation aufgetreten sind.
Mit einfachen Worten: Diese Option "entsperrt" das Paketmanagement, damit zur weiteren Fehlerbehebung andere Befehle ausgeführt werden können.
Die Manpage sagt:

-f, --fix-broken
Fix; attempt to correct a system with broken dependencies in place. This option, when used with install/remove, can omit any packages to permit APT to deduce a likely solution. If packages are specified, these have to completely correct the problem. The option is sometimes necessary when running APT for the first time; APT itself does not allow broken package dependencies to exist on a system. It is possible that a system's dependency structure can be so corrupt as to require manual intervention (which usually means using dselect(1) or dpkg --remove to eliminate some of the offending packages). Use of this option together with -m may produce an error in some situations. Configuration Item: APT::Get::Fix-Broken.

Immer mal wieder die manpage aufrufen, die vielen Optionen kann man nicht alle im Kopf behalten.

Was Du meinst, leistet das Programm Gdebi, das lädt einfach abhängige Pakete nach.
Könnte es aber auch nicht, wenn nach einem Fehler nicht vorher ein apt-get -f install ausgeführt worden wäre......

Jetzt klarer?

[KBDCALLS]

Vereinfacht kann man sagen dpkg ist das Backend, man kann es direkt nutzen, muß sich dann aber um die eventuelle Auflösung von Abhängigkeiten selbst kümmern. Wenn man das macht kann es locale Pakete installieren, Also was direkt auf der Festplatte sich befindet und man braucht dan den vollen Paketnamen. Apt, aptitude und was es sonst noch an Paketmanagern gibt sind die Frontends, mit denen braucht man sich nicht um die Auflösung von Abhängikeiten kümmern, beim installieren wie deinstalieren. Und sie instalieren immer aus dem Netz . Während das von mir genannte gdebi ein Zwitter ist. Mit ihm kann man locale Pakete von der Festplatte installieren, eventuelle Abhängigkeiten werden aus dem Netz gezogen. Und was die Metapakete anbetrifft, die braucht man nicht zwingend. Die sind nur dazu da wenn man zum Beispiel den KDE komplett installieren, dann gibt man das Metapaket KDE an und alles benötigte wird installiert. Ansonsten müßte man sich Pakete mühsam zusammen suchen.

[cartun]

Hey,

okay, jetzt schlagt mich bitte mal
ich habe ein versucht gewagt und mir ein Paket heruntergeladen, ein kleines Spielchen namens "late".

Das habe ich versucht mit dpkg zu installieren, wie erwartet gab es Abhängigkeitsprobleme.
Also habe ich apt-get install -f eingegeben und schwups hat apt die Abhängigkeiten gelöst und "late" installiert.

Also kann apt doch einen fehlgeschlagenen installationsversuch mit dpkg zum Erfolg bringen oder nicht, es geht doch so?!

[Clio]

Ich habe dieses late mal heruntergeladen und mit dpkg -i installiert. Tatsächlich wurden die fehlenden abhängigen Pakete durch ein apt-get -f install nachgeladen und installiert. Das hat mich nun sehr verwundert. Ich sehe das aber eher als Zufall, da die Funktion usprünglich nicht so gedacht war.
Ich habe mich an eine apt-Anleitung erinnert, unter Fehlerbehebung findet sich dies:

Wenn eine Installation mitten im Prozeß abbricht und Sie merken, daß es nicht länger möglich ist, Pakete zu installieren oder zu entfernen, versuchen Sie diese zwei Befehle auszuführen:
# apt-get -f install
# dpkg --configure -a

Der Rest ist für Dich sicher auch interessant:
http://www.debian.org/doc/manuals/apt-h ... ns.de.html

[dawg]

Das hat mich nun sehr verwundert. Ich sehe das aber eher als Zufall, da die Funktion usprünglich nicht so gedacht war.

Mhh... Also wenn ich denn überhaupt mal deb-Pakete mit dpkg installiere und es zu Abhängigkeitsproblemen kommt, hilft mir ein "apt-get install -f " immer weiter.
Davor habe ich mir die Fehlermeldungen von "dpkg -i *.deb" angeschaut und alle fehlenden Pakete einzeln mit "apt-get install packet_name" installiert. Unter Umständen war das recht zeitaufwendig, und "apt-get install -f" macht's in einem Rutsch.

Ich denke auch, dass gdebi das richtige tool für den Job ist. Ich mach's halt mit dpkg. Eigentlich nur, weil ich nicht an gdebi denke.

[cartun]

Hey Clio,

genau das war damit gemeint!!! Ob das absicht ist oder eher Zufall, denn auch so habe ich Google-Chrome installiert, das Paket runtergeladen und mit dpkg -i versucht zu installieren (was nicht ging) und einfach apt aufgerufen, der hat mir Google-Chrome installiert und alle abhängigkeiten gelöst (also anders herum).

Ist das schädlich für das System?

Nun die allerletzte Frage wo das nun geklärt ist:

angenommen ein Freund von mir ist Programmierer hat mir eine Anwendung erstellt und ein .deb geschnürrt, auch sein Programm hat gewisse Abhängigkeiten. Wie installiert man dann sowas? Muss ich dann selbst alle Abhängigkeiten mit der "Hand" lösen, also ich lasse mir eine Liste geben (oder schau mir die Abhängigkeiten im Paket selbst an), überprüfe ob es das ein oder andere schon im System gibt und was nicht installiere ich selbst nach mit dpkg und zuletzt die Anwendung meines Freundes?

Wenn ja, weiß dann auch Apt davon? Weil wenn ich nun wiederum ein Paket mit apt installiere weiß der doch garnichts von den manuell installierten Paketen wo eines evtl. eine Abhängigkeit ist und schon auf dem System ist.

Oder?

[Clio]

Bei Fremdpaketen mußt Du selbst alle Abhängigkeiten auflösen. Wenn es ein ordentlicher Programmierer ist, hat er alle benötigten Libs bereits in das Paket eingefügt, wenn es die Libs schon im Repository gibt, braucht er es nicht. Das ist bei fremder Software aber eher nicht der Fall.
Sobald ein Paket mit dpkg installiert wird, ist es anschließend auch mit apt oder aptitude auffindbar.
KBDCALLS und auch ich haben es doch mehrfach erwähnt: dpkg ist der Paketmanager,
alles andere ist nur schmückendes Beiwerk.

Schädlich für das System?
Das stellt sich heraus, wenn es Fehlermeldungen gibt.
Aber Du weißt ja sicher, daß man ohne aktuelle Backups nicht am System herumschraubt.

[cartun]

Hey,

okay, ich muss mich wirklich bei euch bedanken, mit mir ist es wirklich nicht einfach aber ich habe es nun verstanden!
Das war für mich -wie für euch- echt eine schwere Geburt aber nun wurde soweit alles geklärt und das apt-get install -f hatte mich halt total in schleudern gebracht.

Ich wünsche euch ein schönes WE und stelle diesen Thread auf gelöst

Danke und lg

[KBDCALLS]

Code: Alles auswählen

install -f

ist eigentlich für vertracke Situationen gedacht, in denen ein install oder

Code: Alles auswählen

dist-upgrade/full-upgrade

nicht weiterkommt. Das -f steht für force. Wobei es Sitiuationen gibt wo selbst das nicht weiterhilft. Das passiert in seltenen Fällen bei Testing/Sid oder man hat Pakete aus Fremquellen installiert. debian-unofficial als Beispiel. War so ein Kandidat.

[dawg]

Auch wenn grundsätzlich gdebi die geschmeidigere Variante ist, ganz so ungewöhnlich ist die "apt-get -f install"-Methode 'nu auch wieder nicht. z.B hier:
http://wiki.ubuntuusers.de/Paketinstallation_DEB
http://www.linuxquestions.org/questions ... ly-472911/
http://www.thinkplexx.com/learn/snippet ... ith-dpkg-i

Wenn man jetzt nicht gdebi benutzt, aus welchem Grund auch immer, ist es immer noch wesentlich schneller als eine Abhängigkeit nach der anderen "manuell" zu installieren.

[cartun]

Hey,

sehr sehr interessant, also war mein Weg doch nicht ganz so falsch... wieso steht davon nichts in meinem schlauen Buch?
Diese frage hat mich schon fast zum Wahnsinn getrieben...... warum das geht obwohl fast keiner was davon weiß.....

[gmax]

@KBDCALLS
die -f Option bei apt-get install steht für "fix-broken" (wurde in dem Thread aber auch schon erwähnt )

bei dpkg gibt es die Option --force, da werden dann auch Sachen "erzwungen", z.B. ein Paket zu installieren, was zur Systemarchitektur eigentlich nicht passt. Ist glaube der gebräuchlichste Grund, warum man --force benutzt, grundsätzlich sollte man jedoch wissen man da tut (in der man page dazu steht nicht ohne Grund "für den Einsatz durch Experten gedacht")

[KBDCALLS]

Ich war etwas ungenau wenn wenn man richtig sieht -f steht bei aptitude und apt-get für --fix-broken korrekter Weise . Ist Prinzipiell ein force, denn ich will ja etwas erzwingen. Die Repatur von Abhängikeiten.

--force ist eigentlich eine Option von DPKG, die aber so für sich alleine nicht gibt.

Die dazugehörige Hilfe .

Code: Alles auswählen

matthias@svetlana:~$ dpkg --force-help
dpkg-Optionen zum Erzwingen - Verhalten steuern, wenn Probleme gefunden werden:
  Warnen aber fortsetzen: --force-<Ding>,<Ding>,...
  Mit Fehler anhalten:    --refuse-<Ding>,<Ding>,... | --no-force-<Ding>,...
 Dinge erzwingen:
  all [!]                Alle Optionen zum Erzwingen setzen
  downgrade [*]          Paket durch eine niedrigere Version ersetzen
  configure-any          Jedes Paket konfigurieren, das diesem helfen könnte
  hold                   Bearbeite nebensächliche Pakete, auch wenn auf »halten«
  bad-path               Wichtige Programme nicht in PATH, Probleme wahrsch.
  not-root               Versuche, Dinge zu (de)installieren, selbst wenn
                           nicht root
  overwrite              Datei eines anderen Pakets überschreiben
  overwrite-diverted     Umgeleitete Datei mit einer nicht umgeleiteten
                           Version überschreiben
  bad-verify             Paket installieren, selbst wenn Authentizitäts-
                           überprüfung misslingt
  depends-version [!]    Versionsabhängigkeitsprobleme in Warnungen umwandeln
  depends [!]            Alle Abhängigkeitsprobleme in Warnungen umwandeln
  confnew [!]            Immer neue Konf.-dateien verwenden, nicht nachfragen
  confold [!]            Immer alte Konf.-dateien verwenden, nicht nachfragen
  confdef [!]            Benutze Vorgabe für neue Konf.-Dateien, wenn es eine
                           gibt, nicht nachfragen. Wenn Vorgaben nicht
                           gefunden werden können, nachfragen, außer confold
                           oder confnew ist auch angegeben.
  confmiss [!]           Immer fehlende Konf.-dateien installieren
  breaks [!]             Installieren, selbst wenn es andere Pakete
                           beschädigt.
  conflicts [!]          Installation kollidierender Pakete erlauben
  architecture [!]       Selbst Pakete mit falscher Architektur bearbeiten
  overwrite-dir [!]      Verzeichnis eines Pakets mit Datei eines
                           anderen überschreiben
  remove-reinstreq [!]   Pakete entfernen, die Installation erfordern
  remove-essential [!]   Ein essenzielles Paket entfernen

WARNUNG - Anwenden der mit [!] markierten Optionen kann Ihre Installation
schwer beschädigen. Mit [*] markierte Optionen sind per Vorgabe aktiviert.
matthias@svetlana:~$                                                         

Was aber mit Vorsicht anzuwenden ist, vor allem die Optionen die mit einem Ausrufezeichen versehen sind.