staging.inyokaproject.org

deb-Paket für eigene Python-Anwendung

Status: Gelöst | Ubuntu-Version: Lubuntu 14.04 (Trusty Tahr)
Antworten |

MoonKid

Anmeldungsdatum:
9. Februar 2012

Beiträge: 1379

Da die Suchfunktion des Forums weiterhin unbenutzbar ist und scheinbar sogar irgendwas mit Goolge zu tun hat, muss ich leider hier so fragen, obwohl es dazu sicherlich schon etwas gibt.

Das Wiki ist zum Thema Paketbau sehr ertragreich. Aber wiki-typisch schlecht strukturiert, teils veraltet oder sogar fehlerhaft. Hilfreich fand ich neben dem Grundlagenartikel aber auch die Anleitung, wie man eigenen Skripte verpackt.

Verwirrt bin ich insbesondere durch verschiedenen front-ends (dpkg-packagebuilder, debbuild, pbuilder, ...). Evtl. sind einige veraltet und gar nicht mehr zu empfehlen?

Also ich möchte einfach meinen eigenen Python-Anwendung für den Eigenbedarf (also ohne Veröffentlichung) in ein deb-Paket stecken, um es sauber (de)installieren zu können. Den Bau und Test mache ich gerne auch in einer VirtualBox - was für den Anfang vielleicht erstmal das einfachste für mich ist. chroot hab ich teilweise auch gelesen. Aber wie soll mir das beim Paketbau helfen, wenn ich ein anderes root-Verzeichnis habe? Nebenbei will ich das ja auch gar nicht als root machen. Mir ist auch nicht ganz klar, warum ich (in meinem Fall) beim Paketbau eine abgeschottete Umgebung benötigen sollte.

Nun stellt sich jedoch die Frage, auf welches Tool ich mich jetzt spezialisieren bzw. einarbeiten sollte. debuild?

tomtomtom Team-Icon

Supporter
Avatar von tomtomtom

Anmeldungsdatum:
22. August 2008

Beiträge: 52312

MoonKid schrieb:

Da die Suchfunktion des Forums weiterhin unbenutzbar ist und scheinbar sogar irgendwas mit Goolge zu tun hat, muss ich leider hier so fragen, obwohl es dazu sicherlich schon etwas gibt.

Du bist, wie jeder andere, herzlich eingeladen, diese "unbenutzbare" Suche zu verbessern, statt destruktiv zu meckern.

Das Wiki ist zum Thema Paketbau sehr ertragreich. Aber wiki-typisch schlecht strukturiert, teils veraltet oder sogar fehlerhaft.

Du bist, wie jeder andere, herzlich eingeladen, daran etwas zu ändern. Denn es ist ja ein Wiki...

Verwirrt bin ich insbesondere durch verschiedenen front-ends (dpkg-packagebuilder, debbuild, pbuilder, ...). Evtl. sind einige veraltet und gar nicht mehr zu empfehlen?

Nein, die sind alle gebräuchlich und können alle genutzt werden.

Nun stellt sich jedoch die Frage, auf welches Tool ich mich jetzt spezialisieren bzw. einarbeiten sollte. debuild?

Das ist mehr oder weniger Geschmackssache.

Hilfreich kann aber durchaus https://www.debian.org/doc/manuals/maint-guide/build.de.html sein.

seahawk1986

Anmeldungsdatum:
27. Oktober 2006

Beiträge: 10978

Hilfreich könnte auch die Anleitung zum Paketieren von Python-Programmen und -Modulen im Debian-Wiki sein: https://wiki.debian.org/Python/Packaging

MoonKid

(Themenstarter)

Anmeldungsdatum:
9. Februar 2012

Beiträge: 1379

tomtomtom schrieb:

Du bist, wie jeder andere, herzlich eingeladen, diese "unbenutzbare" Suche zu verbessern, statt destruktiv zu meckern.

Wie sollte das möglich sein? Gibts dazu n Wiki-Artikel? 😉

tomtomtom schrieb:

Du bist, wie jeder andere, herzlich eingeladen, daran etwas zu ändern.

Woher deine Annahme, dass ich das nicht getan habe? Habe diverse Details bereits editiert. Aber wie soll ich Artikel überarbeiten zu einem Thema, von dem ich noch gar keine Ahnung habe?

tomtomtom Team-Icon

Supporter
Avatar von tomtomtom

Anmeldungsdatum:
22. August 2008

Beiträge: 52312

MoonKid schrieb: 😇

Wie sollte das möglich sein? Gibts dazu n Wiki-Artikel? 😉

Nein, einen Ikhaya-Artikel → http://ikhaya.ubuntuusers.de/2014/08/15/inyoka-der-lange-weg-zum-open-source-projekt/#Bei-der-Entwicklung-mithelfen

Woher deine Annahme, dass ich das nicht getan habe?

Dein Schreibstil sagte "alles Scheiße". 😇

Aber wie soll ich Artikel überarbeiten zu einem Thema, von dem ich noch gar keine Ahnung habe?

Nun, du suchst ja gerade nach Lösungen. Das heißt nach der Lösungsfindung dürftest du ja in der Lage sein. Stellt sich allerdings die Frage, wie du festgestellt hast, dass veraltet und fehlerhaft ist, wenn du "keine Ahnung" hast.

MoonKid

(Themenstarter)

Anmeldungsdatum:
9. Februar 2012

Beiträge: 1379

tomtomtom schrieb:

Stellt sich allerdings die Frage, wie du festgestellt hast, dass veraltet und fehlerhaft ist, wenn du "keine Ahnung" hast.

Weil ich entgegen der meisten User nicht einfach unbekannte und im Artikel undokumentierte Befehle aus einem Wiki übernehme, sondern mir vorher die manpage anschaue.

MoonKid

(Themenstarter)

Anmeldungsdatum:
9. Februar 2012

Beiträge: 1379

seahawk1986 schrieb:

Hilfreich könnte auch die Anleitung zum Paketieren von Python-Programmen und -Modulen im Debian-Wiki sein: https://wiki.debian.org/Python/Packaging

Ah, sehr nice.

Aber bevor das klappt, sollte man das hier kennen. https://docs.python.org/3.5/distutils/introduction.html#distutils-simple-example

MoonKid

(Themenstarter)

Anmeldungsdatum:
9. Februar 2012

Beiträge: 1379

So es klappt noch nicht so ganz. Kurz: Beim Lauf von debutils scheint es ein Problem mit pyversion zu geben.

Hab das jetzt mal mit einer ganz simplen hello-world app getestet. Hab dabei die oben genannten Anleitung verwendet und dabei berücksichtigt, dass ich hier nicht Debian (sondern Lubuntu) habe und dass ich Python3 verwende.

Ich fange mal mit dem Ende an. Hier also die Dateien control und rules und der debutils-Lauf.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
debtest/myapp/dist/deb_dist/myapp-0.1a$ cat debian/control
Source: myapp
Maintainer: MoonKid <moonkid@posteo.org>
Section: python
Priority: optional
Build-Depends: python3, debhelper (>= 7)
Standards-Version: 3.9.1

Package: myapp
Architecture: all
Depends: python3
Description: UNKNOWN

debtest/myapp/dist/deb_dist/myapp-0.1a$ cat debian/rules
#!/usr/bin/make -f

# This file was automatically generated by stdeb 0.6.0+git at
# Thu, 04 Jun 2015 00:59:29 +0200

%:
        dh $@ --with python3

override_dh_auto_install:
        python3 setup.py install

override_dh_auto_build:


debtest/myapp/dist/deb_dist/myapp-0.1a$ debuild
 dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: Quellpaket myapp
dpkg-buildpackage: Quellversion 0.1a-1
dpkg-buildpackage: Quelldistribution unstable
dpkg-buildpackage: Quellen geändert durch MoonKid <moonkid@posteo.org>
 dpkg-source --before-build myapp-0.1a
dpkg-buildpackage: Host-Architektur i386
dpkg-source: Information: Optionen aus myapp-0.1a/debian/source/options werden verwendet: --extend-diff-ignore=\.egg-info
 fakeroot debian/rules clean
dh clean --with python3
   dh_testdir
   dh_auto_clean
dh_auto_clean: pyversions -d failed [1]
make: *** [clean] Fehler 1
dpkg-buildpackage: Fehler: Fehler-Exitstatus von fakeroot debian/rules clean war 2
debuild: fatal error at line 1364:
dpkg-buildpackage -rfakeroot -D -us -uc failed

So sieht die eigentlich App im Detail aus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
debtest/myapp$ cat myapp.py
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
if __name__ == '__main__':
    print('Hello World!')

debtest/myapp$ cat setup.py
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from distutils.core import setup
setup(name = 'myapp',
      version = '0.1a',
      py_modules = ['myapp'])

So hab ich das Python-Release-Paket (nennt man das so?) erzeugt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
debtest/myapp$ ./setup.py sdist
running sdist
running check
warning: check: missing required meta-data: url
warning: check: missing meta-data: either (author and author_email) or (maintainer and maintainer_email) must be supplied
warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list)
warning: sdist: standard file not found: should have one of README, README.txt
writing manifest file 'MANIFEST'
creating myapp-0.1a
making hard links in myapp-0.1a...
hard linking myapp.py -> myapp-0.1a
hard linking setup.py -> myapp-0.1a
creating dist
Creating tar archive
removing 'myapp-0.1a' (and everything under it)

debtest/myapp$ ls
dist  MANIFEST  myapp.py  setup.py
debtest/myapp$ ls dist
myapp-0.1a.tar.gz

So wird das debian-Verzeichnis angelegt zur Vorbereitung auf die Paketierung.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
debtest/myapp$ cd dist
debtest/myapp/dist$ py2dsc -m 'MoonKid <moonkid@posteo.org>' myapp-0.1a.tar.gz
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
running the following command in directory: deb_dist/tmp_py2dsc/myapp-0.1a
/usr/bin/python setup.py --command-packages stdeb.command sdist_dsc --dist-dir=/home/user/share/work/debtest/myapp/dist/deb_dist --use-premade-distfile=/home/user/share/work/debtest/myapp/dist/myapp-0.1a.tar.gz --maintainer=MoonKid <moonkid@posteo.org>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
running sdist_dsc
CALLING dpkg-source -b myapp-0.1a (in dir /home/user/share/work/debtest/myapp/dist/deb_dist)
dpkg-source: Information: Optionen aus myapp-0.1a/debian/source/options werden verwendet: --extend-diff-ignore=\.egg-info
dpkg-source: Information: Quellformat »3.0 (quilt)« wird verwendet
dpkg-source: Information: myapp wird unter Benutzung des existierenden ./myapp_0.1a.orig.tar.gz gebaut
dpkg-source: Information: myapp wird in myapp_0.1a-1.debian.tar.gz gebaut
dpkg-source: Information: myapp wird in myapp_0.1a-1.dsc gebaut
dpkg-source: Warnung: unsigniertes Quellpaket wird extrahiert (myapp_0.1a-1.dsc)
dpkg-source: Information: myapp wird nach myapp-0.1a extrahiert
dpkg-source: Information: myapp_0.1a.orig.tar.gz wird entpackt
dpkg-source: Information: myapp_0.1a-1.debian.tar.gz wird entpackt

MoonKid

(Themenstarter)

Anmeldungsdatum:
9. Februar 2012

Beiträge: 1379

Es sind einfach zu viele Möglichkeiten/Wege, Tools, etc. Viele Quellen zeigen die Wege, aber erklären nicht deren Background, weshalb es wiederum schwierig ist auftrettende Fehler zu verstehen und abzuarbeiten.

Interessante Quelle (die bei mir aber auch nicht funktioniert): http://askubuntu.com/questions/90764/how-do-i-create-a-deb-package-for-a-single-python-script

Tatsächlich funktioniert bei mir nach einem ersten Test das GUI-Frontend (Python2 + wxPython) Debreate erschreckend gut. Eigentlich schade, für so ne schöne scriptige Aufgabe ne GUI ranzuziehen. Aber sie läuft.

MoonKid

(Themenstarter)

Anmeldungsdatum:
9. Februar 2012

Beiträge: 1379

Ja, es lässt mich nicht los. Hab es jetzt nochmal nach dem Grundlagen-Artikel probiert, weil mir der dortige Weg am low-level mäßigsten erscheint. Hier werden nicht irgendwelche Zwischenschichten oder Zusatztools verwendet, die den eigentlichen Prozess "verschleiern" würden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
~/share/work/debtest/myapp$ ll
insgesamt 4
-rw-rw-r-- 1 user user 253 Jun  4 22:11 myapp-0.1a.tar.gz

user@MONSTER:~/share/work/debtest/myapp$ tar -xvf *tar.gz
myapp-0.1a/
myapp-0.1a/myapp.py

user@MONSTER:~/share/work/debtest/myapp$ cd myapp-0.1a
user@MONSTER:~/share/work/debtest/myapp/myapp-0.1a$ dh_make -f ../*tar.gz

Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
 [s/i/m/l/k/n] s

Maintainer name  : user
Email-Address    : user@unknown 
Date             : Thu, 04 Jun 2015 22:23:34 +0200
Package Name     : myapp
Version          : 0.1a
License          : blank
Type of Package  : Single
Hit <enter> to confirm: 
Currently there is no top level Makefile. This may require additional tuning.
Done. Please edit the files in the debian/ subdirectory now. You should also
check that the myapp Makefiles install into $DESTDIR and not in / .

Sieht schon mal gut aus, oder?

Aber hier schon mal ne Frage: Warum brauch ich da n tar.gz-Archiv? Kann der das nicht selber backen?

Ohne etwas an den Datein in debian/ verändert zu haben,bauen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
user@MONSTER:~/share/work/debtest/myapp/myapp-0.1a$ dpkg-buildpackage -us -uc
dpkg-buildpackage: Quellpaket myapp
dpkg-buildpackage: Quellversion 0.1a-1
dpkg-buildpackage: Quelldistribution unstable
dpkg-buildpackage: Quellen geändert durch user <user@unknown>
dpkg-buildpackage: Host-Architektur i386
 dpkg-source --before-build myapp-0.1a
 fakeroot debian/rules clean
dh clean 
   dh_testdir
   dh_auto_clean
   dh_clean
 dpkg-source -b myapp-0.1a
dpkg-source: Information: Quellformat »3.0 (quilt)« wird verwendet
dpkg-source: Information: myapp wird unter Benutzung des existierenden ./myapp_0.1a.orig.tar.gz gebaut
dpkg-source: Information: myapp wird in myapp_0.1a-1.debian.tar.gz gebaut
dpkg-source: Information: myapp wird in myapp_0.1a-1.dsc gebaut
 debian/rules build
dh build 
   dh_testdir
   dh_auto_configure
   dh_auto_build
   dh_auto_test
 fakeroot debian/rules binary
dh binary 
   dh_testroot
   dh_prep
   dh_auto_install
   dh_installdocs
   dh_installchangelogs
   dh_perl
   dh_link
   dh_compress
   dh_fixperms
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
   dh_installdeb
   dh_gencontrol
dpkg-gencontrol: Warnung: Feld Depends von Paket myapp: unbekannte Substitutionsvariable ${shlibs:Depends}
   dh_md5sums
   dh_builddeb
dpkg-deb: Paket »myapp« wird in »../myapp_0.1a-1_i386.deb« gebaut.
 dpkg-genchanges  >../myapp_0.1a-1_i386.changes
dpkg-genchanges: kompletter Quellcode beim Hochladen hinzufügen
 dpkg-source --after-build myapp-0.1a
dpkg-buildpackage: Alles hochzuladen (Originalquellen enthalten)

Zwischenfrage: Wie kann ich mir den Inhalt eines deb-files (bzw. das was dann installiert werden würde) auf der bash anzeigen lassen? Mit den Kommandos in der manpage bekomme ich nur Metainfos zum Paket, aber nicht den Inhalt selbst.

Öffne ich das Ding mit einem Archivmanager sehe ich eindeutig, dass mein py-File dort gar nicht mit drin ist. Ok, ich hab ja auch nix an den Dateien im debian-Ordner verändert. Aber hier geht mir eben das Verständnis flöten: Ich bastle das tar.gz Archiv (mit dem py-File drin!) zusammen. Das wird beim deb-Bau aber ignoriert? Versteht ihr meine Logik? Desweiteren sehe ich im Grundlagenartikel keine Info darüber, wo und wie ich meine eigentlichen Dateien zur Installation (z.B. das py-file) angeben kann/soll/muss. Was hab ich überlesen?

seahawk1986

Anmeldungsdatum:
27. Oktober 2006

Beiträge: 10978

MoonKid schrieb:

Zwischenfrage: Wie kann ich mir den Inhalt eines deb-files (bzw. das was dann installiert werden würde) auf der bash anzeigen lassen? Mit den Kommandos in der manpage bekomme ich nur Metainfos zum Paket, aber nicht den Inhalt selbst.

dpkg --contents paket.deb

vgl. http://debiananwenderhandbuch.de/dpkg.html#dpkg-c

Öffne ich das Ding mit einem Archivmanager sehe ich eindeutig, dass mein py-File dort gar nicht mit drin ist. Ok, ich hab ja auch nix an den Dateien im debian-Ordner verändert. Aber hier geht mir eben das Verständnis flöten: Ich bastle das tar.gz Archiv (mit dem py-File drin!) zusammen. Das wird beim deb-Bau aber ignoriert? Versteht ihr meine Logik?

Es wird nicht ignoriert, sondern überprüft, ob die Datei im build-Verzeichnis mit der aus dem Source-Tarball übereinstimmt. Die Idee dahinter ist, dass du das ganze nicht nur für einen Lokalen Build machst, sondern ausgehend von einem Source-Tarball ein Paket baust und eventuelle Patches sauber einpflegst statt die Sourcen direkt zu verändern (der Spezialfall, dass man Autor und Verpacker in Personalunion ist, tritt ja nicht allzu oft auf). Wenn man das nicht möchte, kann man den Schalter -b für dpkg-buildpackage nutzen (vgl. http://debiananwenderhandbuch.de/paketeerstellen.html#dpkg-buildpackage), dann braucht es keinen Source-Tarball.

MoonKid

(Themenstarter)

Anmeldungsdatum:
9. Februar 2012

Beiträge: 1379

Grundsätzlich ist mir natürlich klar, dass bei offizielen deb-Paketen zich Leute involviert sind und da ganz andere Bestimmungen und workflows herrschen. Genau das bilden die deb-tools ja auch ab. Für so eben mal schnell ein deb für den Eigenbedarf bauen, sind die eigentlich gar nicht da.

seahawk1986 schrieb:

Es wird nicht ignoriert, sondern überprüft, ob die Datei im build-Verzeichnis mit der aus dem Source-Tarball übereinstimmt. Die Idee dahinter ist, dass du das ganze nicht nur für einen Lokalen Build machst, sondern ausgehend von einem Source-Tarball ein Paket baust

Was ist "die Date im build-Verzeichnis"? Was ist der "Source-Tarball"?

Im engeren Sinne gibt es bei Python keine Unterscheidung zwischen Binary und Source.

Mein tar.gz (Source-Tarball?) enthält das py-file. Das eigentliche Verzeichnis enthält das py-file auch.

Hab den gesamten Prozess nochmal wiederholt und mit -b gebaut. Das py-file ist wieder nicht drin.

Mir viel auf, dass es im debian-Verzeichnis einen Ordner myapp gibt. Da ist auch kein py-file drin, sondern nur die autogenerated doc-files.

Ich denke an meinen Fragen wird deutlich, dass gewisse Grundlagen bisher noch nicht verstanden habe bzw. dass ich gewisse falsche Grundannahmen treffe.

djcj

Avatar von djcj

Anmeldungsdatum:
28. August 2013

Beiträge: 240

Ein einzelnes Python-Skript oder ein Programm, dass aus mehreren Python-Skripten besteht kannst du doch auch manuell nach /usr/local installieren. Mit einem einfachen "sudo rm /usr/local/bin/MeinSkript" wäre das dann doch deinstalliert. Warum sich da die Mühe machen ein Paket zu bauen, wenn du es eh nicht vor hast zu veröffentlichen?

MoonKid

(Themenstarter)

Anmeldungsdatum:
9. Februar 2012

Beiträge: 1379

Bitte keine Grundsatzdiskussion über die Notwendigkeit der Aufgabe - das is OffTopic.

Selbstverständlich steht am fernen Ende ein ordentliches Projekt, mit Debian Guideliens, so perfekt, dass ein Mr. Stallman mich doch glatt adoptieren würde.

Aber wenn ich eines in der Unix-Welt gelernt habe, dann das man einen Schritt vor dem anderen macht und Minibeispiele liefert.

Was ich hier als Beispiel anbringe ist natürlich nicht das originalprojekt. Das ist schon etwas größer - keine Sorge.

Hier ein deb zu machen gehört auch zum Lerneffekt. Diese Fähigkeit hilft mir bei mehreren (evtl. auch fremden) Projekten.

Also wieder zurück zur Technik: Wie soll ich die Sache nun verstehen? Das py-File ist im tar.gz-Archiv und im Verzeichnis - jedoch im deb-file taucht es nicht auf. Sehr merkwürdig und für mich völlig unlogisch.

seahawk1986

Anmeldungsdatum:
27. Oktober 2006

Beiträge: 10978

MoonKid schrieb:

Also wieder zurück zur Technik: Wie soll ich die Sache nun verstehen? Das py-File ist im tar.gz-Archiv und im Verzeichnis - jedoch im deb-file taucht es nicht auf. Sehr merkwürdig und für mich völlig unlogisch.

Was im Paket landet entscheidet der Paketersteller, nicht derjenige, der die Sourcen liefert. Wenn man eine einzelne Datei an eine bestimmte Stelle installieren lassen möchte, das Build-Skrip das aber nicht erledigt, kann man sie in debian/install eintragen oder in debian/rules mit einem Makefile-artigen Skript, das man in einem override für dh_install platziert, kopieren lassen. Wenn man Python-Module sauber an die richtigen Stellen installieren lasse möchte, ist das mit dh_python sehr einfach möglich - schau dir z.B. mal das Paket hier an, das python-uinput in ein Paket steckt: https://launchpad.net/~yavdr/+archive/ubuntu/unstable-main/+sourcepub/5122784/+listing-archive-extra

Antworten |