staging.inyokaproject.org

Ich hatte gerade versucht, mittels checkinstall ein Programm von eimem PC auf einen anderen zu übertragen. Ich wollte damit vermeiden, jedesmal den kompletten Quelltext zu übertragen und dann auf den Ziel-PC neu übersetzen zu müssen.

Leider funktioniert das nicht so, wie gedacht. Das Programm funktioniert zwar, aber etliche zusätzliche Dateien fehlen hinterher.

In der Datei makefile steht unter anderem:

...
PROGDIR    := /usr/local/bin/
ICONDIR    := /usr/share/pixmaps/
DESKTOPDIR := /usr/share/applications/
FILESDIR   := /usr/local/share/vted/
...
install:
	install $(TARGET) ${PROGDIR}
	@cp -u $(TARGET).png ${ICONDIR}
	@cp -u $(TARGET).desktop ${DESKTOPDIR}
	@mkdir -p $(FILESDIR)
	@cp -u frame_mask.png $(FILESDIR)
	@cp -u vted_splash.png $(FILESDIR)
	@cp -u $(TARGET).cfg $(FILESDIR)
...

Die Installation und der erste Start:

manfred@samurai:~$ sudo dpkg -i vted_20220521-1_amd64.deb 
[sudo] Passwort für manfred: 
Vormals nicht ausgewähltes Paket vted wird gewählt.
(Lese Datenbank ... 308473 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von vted_20220521-1_amd64.deb ...
Entpacken von vted (20220521-1) ...
vted (20220521-1) wird eingerichtet ...
manfred@samurai:~$ vted
Warning: No frame mask found!
manfred@samurai:~$ 

Das Programm kann also gestartet werden, taucht aber nicht im Menü des Desktops/Dateimanagers auf. Es sieht so aus, dass alle zusätzlich zu kopierende Dateien ignoriert werden, als da sind:

• vted.png

• vted.desktop

• frame_mask.png

• vted_splash.png

• vted.cfg

Die erste Überraschung war, dass das Programm nicht im Memnü auftaucht. Da stellt sich die Frage, was ich da in der Desktop-Datei angeben muss, falls sie berücksichtigt wird. Aktuell steht da:

Categories=Video;AudioVideo;

das gibt es aber wohl nicht mehr.

p.s. Für echte Debian Pakete fehlt mir das Wissen. Außerdem würde das in diesem Fall nicht funktionieren, da ich für meine Programme immer eine möglichst aktuelle Version von FLTK verwende. Die sind dann nicht gegen die öffentliche libfltk gelinkt, sondern statisch in das Binary eingebunden.

Dakuan schrieb:

mittels checkinstall ein Programm von eimem PC auf einen anderen zu übertragen.

Du meinst, Du hast mit checkinstall ein .deb-File erzeugt, das Du mit "dpkg -i" installierst. etwaige Paketabhängigkeiten mußt Du natürlich lösen, sprich installieren. checkinstall kann man entsprechende Optionen mitgeben oder bei der Konfiguration direkt nach dessem Start diese Abhängigkeiten eintragen, diese werden berücksichtigt, als Option z.B.

--requires="libc6 \(\>= 2.31\)"

Wie Du siehst, das Maskieren beachten! Mehrere Optionen trennt man mit Komma.

was ich da in der Desktop-Datei angeben muss, falls sie berücksichtigt wird.

Zwei funktionierende Beispiele:

• vlc.desktop

  Categories=AudioVideo;Player;Recorder;

• mpv.desktop

  Categories=AudioVideo;Audio;Video;Player;TV;

Gleichnamige .desktop-Files in "~/.local/share/applications/" haben Priorität vor "/usr/share/applications/".

Pfade darin müssen ausgeschrieben werden, also bspw.

Icon=/home/manfred/.icons/vted.png

~ für "/home/manfred/" ist unzulässig. Das Beispiel funktioniert natürlich nur für den User manfred.

Bei Änderungen sollte man sich neu einloggen. Das dauert sonst.

Hallo Dakuan,

Und was passiert wenn du den kompletten Quelltext nimmst und dann auf den Ziel-PC mit checkinstall neu übersetzt ?

Gruss Lidux

Lidux schrieb:

Und was passiert wenn du den kompletten Quelltext nimmst und dann auf den Ziel-PC mit checkinstall neu übersetzt ?

Checkinstall macht nur ein make install bzw. leitet das in ein .deb-Paket um, dazu erstellt es die Konfigurationsdatei debian/control (in der z.B. die Abhängigkeiten eingetragen werden müssen).

Wegen den Abhängigkeiten installiert man ein lokal vorliegendes Debian-Paket nicht mehr mit dpkg sondern mit apt

siehe auch: https://wiki.ubuntuusers.de/apt/apt/#Ein-einzelnes-Paket-installieren

Lidux schrieb:

auf den Ziel-PC mit checkinstall neu übersetzt ?

Das will er verständlicherweise ja gerade nicht.

Ubunux, kann "man" machen, muß man aber nicht.

Checkinstall ist generell suboptimal, wenn man das Ergebnis auf andere Rechner bringen will - für den Anwendungsfall würde ich dann ein ordentliches Debian-Paket erstllen (wenn man das auf Launchpad in einem PPA bauen lässt, kann man dann gleich noch Pakete für armhf und arm64 mit erstellen lassen, wenn man das will) - und die debhelper-Skripte haben auch den Vorteil, dass dann so Dinge wie der Aufruf von update-desktop-database automatisch im postinst-Skript passieren können.

Ubunux schrieb:

Wegen den Abhängigkeiten installiert man ein lokal vorliegendes Debian-Paket nicht mehr mit dpkg sondern mit apt

Schon, aber sowohl die Fehlermeldung von dpkg, was da so fehlt, als auch die Installation mit apt, dass etwaige Abhängigkeiten auflöst, basieren darauf, was der Ersteller des Pakets bei checkinstall als Abhängigkeiten eingibt. Standardmäßig steht dort: Nichts.

Es geht mir im Moment nicht um die Abhängigkeiten von anderen Libs. Da fehlt ja nichts. Alle "Besonderheiten" sind statisch eingebunden.

Es geht mir erstmal darum, einige zusätzliche Dateien an die richtigen Orte zu kopieren.

@seahawk1986

... für den Anwendungsfall würde ich dann ein ordentliches Debian-Paket erstllen ...

Das ist mir zu kompliziert. Das scheitert schon am verstehen der Debian Anleitung. Habe schon zwei Versuche hinter mir.

Dakuan schrieb:

Es geht mir erstmal darum, einige zusätzliche Dateien an die richtigen Orte zu kopieren.

Das hat aber wenig bis gar nichts mit checkinstall zu tun, das kriegt die Info auch nur aus dem makefile.

Das hat aber wenig bis gar nichts mit checkinstall zu tun, das kriegt die Info auch nur aus dem makefile.

Da bin ich dann wohl von falschen Voraussetzungen ausgegangen. Die Kopieranweisungen stehen im Makefile aber drinn, wie man im ersten Post sehen kann.

Aber wenn checkinstall das nicht erkennen kann, sollte ich wohl besser ein Archiv und ein Shellscript einsetzen.

Sagen wir mal so: checkinstall sollte das aus dem Makefile erkennen. Scheint allerdings nicht so zu funktionieren, wie es soll, wenn es das nicht tut.

Nun, du könntest auch einfach einen Arbeitsordner anlegen, die Ordnerstruktur erstellen und die Dateien dorthin legen, in der obersten Ebene des Ordners noch den Ordner debian erstellen und dorthin die control schreiben und dann aus der Ebene über dem Ordner heraus mit

dpkg -b ./ORDNERNAME PAKETNAME_ARCH.deb

quasi "quick and dirty" Das Paket bauen. Vorteil: Ist dann über die Paketverwaltung auch wieder komplett entfernbar.

Da hast Du mir aber eine schöne Hausaufgabe mitgegeben 😉

Das mit der Ordnerstruktur war ja recht einfach, aber an der control Datei musste ich ziemlich lange rumbasteln, weil das Beispiel im Wiki nicht ganz passt.

So wie es aussieht, wird bei Leerzeilen Abgebrochen. Außerdem wird Versionsnummer verlangt und der "Empfänger" will als Architektur unbedingt amd64 sehen. Und der Link zur "Ubuntu Policy" funktioniert nicht mehr.

... quasi "quick and dirty" Das Paket bauen.

So "quick and dirty" scheint das gar nicht zu sein:

manfred@samurai:~/test$ sudo dpkg -i vted-0.75_amd64.deb 
[sudo] Passwort für manfred: 
Vormals nicht ausgewähltes Paket vted wird gewählt.
(Lese Datenbank ... 308473 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von vted-0.75_amd64.deb ...
Entpacken von vted (0.75) ...
vted (0.75) wird eingerichtet ...
Trigger für gnome-menus (3.36.0-1ubuntu1) werden verarbeitet ...
Trigger für desktop-file-utils (0.24-1ubuntu3) werden verarbeitet ...
Trigger für bamfdaemon (0.5.3+18.04.20180207.2-0ubuntu2) werden verarbeitet ...
Rebuilding /usr/share/applications/bamf-2.index...
Trigger für mime-support (3.64ubuntu1) werden verarbeitet ...
manfred@samurai:~/test$ 

Da wird mit dem Paket eine ganze Menge gemacht und alle Dateien sind da, wo sie hingehören. Da komme ich leicht in Versuchung, das bei meinen größeren Projekten auch so zu machen. Allerdings sind da noch eine richtige Abhängigkeit drin.

Dakuan schrieb:

Das mit der Ordnerstruktur war ja recht einfach, aber an der control Datei musste ich ziemlich lange rumbasteln, weil das Beispiel im Wiki nicht ganz passt.

Ich weiß jetzt nicht, welches Beispiel du konkret meinst. 😉

Eigentlich ist es so umfangreich nicht:

Package: blafoo
Version: 0.0.1-1
Architecture: amd64
Maintainer: dingens <adresse@host.tld>
Depends: libc6
Section: utils
Priority: extra
Homepage: https://example.org
Description: dingens
 With dingens you can Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

So "quick and dirty" scheint das gar nicht zu sein:

Na ja, nach der reinen Debian-Lehre ist es gerantiert nicht. 😉

Da komme ich leicht in Versuchung, das bei meinen größeren Projekten auch so zu machen. Allerdings sind da noch eine richtige Abhängigkeit drin.

Für die Abhängigkeiten gibt es ja die Zeile Depends: in der control-Datei.

Ich weiß jetzt nicht, welches Beispiel du konkret meinst.

Ich meinte folgenden Block: Grundlagen der Paketerstellung (Abschnitt „control“).

Da fehlt mindestens "Version:", wobei ich natürlich nicht weiß, ob die anderen Tools, die bei quick and dirty nicht zu Einsatz kommen, da noch etwas verändern.

Na ja, nach der reinen Debian-Lehre ist es gerantiert nicht. 😉

Die würden mir meine Programme noch wegen ganz anderer Dinge um die Ohren hauen, auch wenn sie funktionieren. Allein schon dass ich das ganze FLTK Zeugs statisch einbinde ...

Für die Abhängigkeiten gibt es ja die Zeile Depends: in der control-Datei.

Ja, da werde ich mich wohl bald drum kümmern müssen. Im gestrigen Versuch hatte ich die Zeile komplett weg gelassen, weil diese Abhängigkeiten bisher immer bereits erfüllt waren. Mit einer Ausnahme allerdings, aber wenn man etwas extra installiert hat, weiß man das ja vorher.

Ich habe mir die Abhängigkeiten gerade mal angesehen. Da taucht doch einiges auf. Irgendwann werde ich mich wohl darum ernsthaft kümmern müssen:

manfred@samurai:~/prog/img/vted-0.75/usr/local/bin$ readelf -d vted | grep lib
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libpng16.so.16]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libXrender.so.1]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libXfixes.so.3]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libXext.so.6]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libXft.so.2]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libfontconfig.so.1]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libdl.so.2]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libX11.so.6]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libglib-2.0.so.0]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libm.so.6]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Gemeinsame Bibliothek [libc.so.6]
manfred@samurai:~/prog/img/vted-0.75/usr/local/bin$ 

Wissentlich eingebaute Abhängigkeiten sind libpng, glib2 und libm. Der Rest ist vom Toolkit oder vom Compiler.