DebianPakete.AgaidaTipps

DebianPakete

[2015-12-09 19:13:46] <agaida> vor genau diesem Problem stand ich im November 2009, als ich mein erstes Paket mit einem Patch versehen wollte - war auch nur ein ganz kleines einfaches, xorg :D
[2015-12-09 19:14:09] <agaida> und ich wusste noch sehr viel weniger als Du
[2015-12-09 19:20:12] <bluelupo> ersten Fehler gefunden: in der control arbeitet man mit Tabulatoren
[2015-12-09 19:27:34] <agaida> nö - is egal
[2015-12-09 19:28:42] <agaida> nur in den rules ist das nicht egal, da die rules ein make-file sind
[2015-12-09 19:33:35] <bluelupo> format ist das Problem
[2015-12-09 19:34:20] <bluelupo> da stand "3.0 (quilt)" drin. Mit 1.0 wie im inxi-Paket baut es 
[2015-12-09 19:34:35] <agaida> \o/
[2015-12-09 19:34:40] <bluelupo> hast du eine Ahnung warum?
[2015-12-09 19:34:43] <agaida> ja
[2015-12-09 19:34:47] <agaida> Grundlagen
[2015-12-09 19:34:59] <bluelupo> das denke ich mir ;-))
[2015-12-09 19:35:16] <bluelupo> man soll doch laut Doku 3.0 nehmen
[2015-12-09 19:35:25] <agaida> fuck the doku
[2015-12-09 19:35:32] <agaida> und die haben recht
[2015-12-09 19:36:12] <agaida> wäre ja auch kein problem - und nu nehmen wir mal 3.0 (quilt) auseinander
[2015-12-09 19:36:29] <agaida> was will man damit erreichen?
[2015-12-09 19:36:42] <bluelupo> "3.0 (native)" wäre eine Variante, hab ich irgendwo gelesen
[2015-12-09 19:37:23] <agaida> ja, für ein natives Paket - ist aber genau so dumpf, weil einfach dumpf :)
[2015-12-09 19:37:39] <agaida> die Frage ist: was macht das source-Format
[2015-12-09 19:38:15] <agaida> Antwort: dat legt eigentlich nur fest, wei sourcen zusammengeschnürt und verarbeitet werden
[2015-12-09 19:39:04] <agaida> 1.0 - ganz primitiv - is kein Tarball da, wird einer gemacht. patches und so was werden nicht automatisch verarbeitet - wenn ich das richtig im kopf habe
[2015-12-09 19:39:13] <agaida> 2.0 - vergessen
[2015-12-09 19:39:42] <agaida> 3.0 (native) macht einen tarball, wenn keiner da und verarbeitet patches
[2015-12-09 19:40:17] <agaida> doof ist nur, dass man nur ein resultierenden Tar-ball hat, das ist ungünstig, wenn man nicht genau weiss, was man tut
[2015-12-09 19:40:57] <agaida> 3.0 (quilt) - patches werden gepflegt - da bist Du mit deinem zeuch in tmp reingelaufen
[2015-12-09 19:41:12] <bluelupo> d.h. 1.0 ist für ein zu paketierendes Shellscript genau richtig
[2015-12-09 19:41:42] <agaida> es wird ein orig.tar.xz (oder anderer ball vorausgesetzt) und die debian-Paketierung landet in debian.tar.{packerendung}
[2015-12-09 19:42:23] <agaida> 1.0 ist ganz geil für quick and dirty, wenn Du Dein eigener Upstream bist und volle Kontrolle über die Sourcen hast
[2015-12-09 19:42:43] <agaida> weil patches brauchst Du dann eh nicht, Du malst das in deine Sourcen und gut
[2015-12-09 19:43:48] <agaida> wenn Du andere Quellen verarbeitest und keine Zeit hast: 3.0 (native) eventuell, es wird dir auf die Füsse fallen auf Dauer
[2015-12-09 19:44:29] <agaida> oder halt 3.0 (quilt) - ein wenig mehr Aufwand, dafür aber geil für fremde Quellen
[2015-12-09 19:44:46] <agaida> ok, für Dein script ist 1.0 genau richtig
[2015-12-09 19:45:07] <agaida> nächste Datei: compat - da steht 9 drin und nichts anderes
[2015-12-09 19:45:22] <bluelupo> das passt bei mir
[2015-12-09 19:45:46] <agaida> dat bedeutet nur, dass Du mit den debhelpern (>= 9) kompatibel bist - passt
[2015-12-09 19:46:22] <agaida> changelog - bitte nur mit dch bearbeiten - ausser, Du hast das Format verinnerlicht
[2015-12-09 19:46:48] <agaida> control
[2015-12-09 19:46:59] <agaida> genereller Aufbau
[2015-12-09 19:48:28] <agaida> Feld: Liste von werten, erste Zeile der Paketname und Typ
[2015-12-09 19:49:05] <bluelupo> okay passt bei mir
[2015-12-09 19:49:18] <agaida> wichtig: Nur Felder stehen am Anfang
[2015-12-09 19:49:37] <agaida> alles andere ist mindestens ein Leerzeichen eingerückt
[2015-12-09 19:50:08] <agaida> kommentare sind erlaubt - auch vom anfang an, bitte nur eine #
[2015-12-09 19:50:25] <agaida> ## hat schon wieder eine andere bedeutung
[2015-12-09 19:50:43] <bluelupo> okay, man lernt nie aus
[2015-12-09 19:50:46] <bluelupo> Priority hatte ich gelesen sei noch sehr wichtig
[2015-12-09 19:50:58] <agaida> später, erst mal Format
[2015-12-09 19:51:15] <agaida> Description: short description
[2015-12-09 19:51:30] <agaida>   long description
[2015-12-09 19:51:54] <agaida>  . (keine leerzeilen, würde fehler machen, eingerückter Punkt)
[2015-12-09 19:52:26] <agaida> dito werden formatiert Comment: short
[2015-12-09 19:52:28] <agaida>  long
[2015-12-09 19:52:33] <bluelupo> eingerückt die "long description" mit 1 LZ
[2015-12-09 19:52:42] <agaida> und License: Bezeichner
[2015-12-09 19:52:46] <agaida>  Lizenztext
[2015-12-09 19:53:17] <agaida> pakete werden durch leerzeilen getrennt, ansonsten sind keine leerzeilen zulässig
[2015-12-09 19:53:40] <agaida> Felder: 
[2015-12-09 19:54:18] <agaida> Source: Name (kennzeichnet das Source-Paket, Name _muss_ mit dem Namen im changelog übereinstimmen)
[2015-12-09 19:54:36] <agaida> Section: passende Section
[2015-12-09 19:54:59] <agaida> Priority: optional/extra - Beschreibung lesen
[2015-12-09 19:55:12] <bluelupo> okay
[2015-12-09 19:56:19] <agaida> Maintainer: Dein Name <deinname@boo.tkd> - wichtig, nur einer zulässig, sollte die selbe Adresse sein wie im Changelog, ansonsten viel freude
[2015-12-09 19:57:22] <agaida> Uploaders: liste im Format name <addi>, name <addi> - ist optional, wenn mehrzeilig einrücken
[2015-12-09 19:57:33] <agaida> liste ist kommasepariert
[2015-12-09 19:58:33] <agaida> Build-Depends: debhelper (>= 9 ) - mindestens das sollte drin stehen 
[2015-12-09 19:58:49] <agaida> Standards-Version: aktuelle Standards
[2015-12-09 19:59:05] <agaida> VCS-Felder, Homepage sind optional
[2015-12-09 19:59:25] <agaida> Binär-Pakete:
[2015-12-09 19:59:32] <agaida> Package: Name
[2015-12-09 20:00:06] <bluelupo> "Standards-Version" von was?
[2015-12-09 20:00:28] <agaida> von den Standards, nach denen Du genau dieses File aufbaust :)
[2015-12-09 20:00:57] <bluelupo> okay also das Fileformat dieser Datei
[2015-12-09 20:01:01] <agaida> aktuell ist 3.9.6 - Das regelt u.a. gültige Syntax und Semantik
[2015-12-09 20:01:19] <bluelupo> bei inxi steht 3.9.5
[2015-12-09 20:01:44] <agaida> lange nich mehr angepasst - sollte ich mal ändern
[2015-12-09 20:01:50] <bluelupo> ;-)
[2015-12-09 20:02:56] <agaida> Architecture: all, any, same ... - Doku lesen, all sollte glaube ich für das Paket passen :)
[2015-12-09 20:04:04] <bluelupo> ja, habe zum Teil schon gemacht
[2015-12-09 20:04:36] <agaida> Depends: ${misc:Depends} - dat sind die minimalen Dependencies, die aus dem Bausystem kommen - die Zeile sollte drin sein, sonst nörgelt lintian
[2015-12-09 20:05:01] <agaida> weitere pakete, die das paket zur laufzeit unbedingt braucht
[2015-12-09 20:05:55] <agaida> Recommends: Empfohlen, um die Funktionalität zu erweitern, aber für einen Basisbetrieb nicht unbedingt erforderlich
[2015-12-09 20:06:38] <bluelupo> eine Frage: wenn ich nochmal etwas an der control ändere zB depends hinzufüge, muss dann nur nochmal einmal "dpkg-buildpackage -us -uc" anstossen oder gibts's noch was zu beachten?
[2015-12-09 20:06:50] <agaida> über das unbedingt erforderlich scheiden sich die Geister, bei debian und ubuntu werden Recommends als Soft-Dependencies missbraucht, da die in o.a. Distributionen mitinstalliert werden - bei uns nicht
[2015-12-09 20:07:15] <bluelupo> also weglassen
[2015-12-09 20:07:19] <agaida> kome
[2015-12-09 20:07:22] <agaida> grr
[2015-12-09 20:07:38] <agaida> Wenn Du nichts empfehlen willst ja
[2015-12-09 20:08:05] <agaida> same for Suggests: ist schwächer, wird nicht automatisch mitinstalliert, halt Vorschläge
[2015-12-09 20:08:40] <agaida> Description: zweiteilig short/long
[2015-12-09 20:08:48] <agaida> zwingend erforderlich
[2015-12-09 20:09:05] <agaida> alles andere wirst Du früh genug merken
[2015-12-09 20:09:35] <bluelupo> einzig "lvm2" wäre als Depends noch interessant für mein Paket, das Script läuft ja nur auf einem LVM-System
[2015-12-09 20:10:05] <agaida> wenn es lvm2 voraussetzt, dann ist es eine Dependency
[2015-12-09 20:10:58] <agaida> hat mehrere Vorteile: apt-get install script würde lvm2 gleich mitinstallieren, wenn nicht da
[2015-12-09 20:11:16] <agaida> script wird gepurged, wenn lvm2 entfernt wird
[2015-12-09 20:11:32] <bluelupo> macht ja auch Sinn
[2015-12-09 20:12:16] <agaida> So - das war die Control - für den Anfang würde ich mich auf Source und ein Binary beschränken, spart Tipperei
[2015-12-09 20:13:07] <agaida> ok - copyright brauchen wir noch, den source-Teil kannste so übernehmen, 
[2015-12-09 20:13:51] <agaida> wichtig: Format, Upstream-Name und Source sollten schon drin stehen
[2015-12-09 20:14:32] <agaida> Files: Wildcards zulässig, auflistung ohne komma
[2015-12-09 20:15:24] <bluelupo> Upstream-Name ist quasi das Original
[2015-12-09 20:15:31] <agaida> genau
[2015-12-09 20:15:39] <agaida> Copyright: Jahr name mail - ist Freitext, aber bitte nicht kreativ sein
[2015-12-09 20:16:17] <agaida> jahr oder jahre _leer_ name <addi so vorhandne>, einer pro zeile
[2015-12-09 20:16:59] <agaida> License: short/long oder nur license: short
[2015-12-09 20:17:10] <agaida> und license: short
[2015-12-09 20:17:15] <agaida>  und dann den langtext
[2015-12-09 20:17:44] <agaida> die wichtigsten findest Du fertig, wenn Du dh-make installierst
[2015-12-09 20:18:04] <agaida>  wenn man so was macht, Boilerplates rausnehem
[2015-12-09 20:18:44] <bluelupo> Platzhalter?
[2015-12-09 20:19:33] <agaida> cat /usr/share/debhelper/dh_make/licenses/gpl2
[2015-12-09 20:19:41] <agaida> die dinger mit den rauten
[2015-12-09 20:20:42] <bluelupo> okay verstanden
[2015-12-09 20:20:59] <agaida> #PACKAGE# könnteste Du drin lassen, das würden dann die debian-helper mit dem Paketnamen ersetzen, wenn paketname==upstreamname
[2015-12-09 20:21:46] <bluelupo> jo hat bei mir gemacht
[2015-12-09 20:22:07] <bluelupo> +er
[2015-12-09 20:22:28] <agaida> docs - hier würden dokumentations-Files reinkommen, wenn vorhanden (die werden dann mit dh_installdocs installiert, glaub ich)
[2015-12-09 20:23:30] <agaida>  manpages dito, wenn dh dat nich von allen als manpage findet
[2015-12-09 20:26:46] <agaida> install - ab hier wirds böse
[2015-12-09 20:27:11] <agaida> foo - installiert (projekt)/foo nach foo
[2015-12-09 20:27:45] <agaida> foo bar - installiert foo nach bar
[2015-12-09 20:28:08] <agaida> bar ist immer nur ein Pfad, dateien werden damit nicht umbenannt
[2015-12-09 20:28:38] <bluelupo> okay
[2015-12-09 20:29:21] <agaida> foo kann auch relativ viel sein, das ist mit vorsicht zu geniessen
[2015-12-09 20:29:48] <bluelupo> bei inxi ist es ein Dreizeiler
[2015-12-09 20:30:05] <agaida> foo bar - foo landet in bar/foo
[2015-12-09 20:30:25] <agaida> foo/* bar - * landet in bar
[2015-12-09 20:30:58] <bluelupo> ^der ist gemein ;-)
[2015-12-09 20:31:21] <agaida> und es wird in passende Ziele installiert - witzig bei multiarch
[2015-12-09 20:31:55] <bluelupo> d.h. die Pfade müssen vorhanden sein
[2015-12-09 20:32:19] <agaida> usr/lib/*/foo* passt für beide Architekturen, da wird das genommen, was gefunden wird und halt installiert
[2015-12-09 20:32:46] <agaida> nö, der macht die sich schon - dokumentiert ist da in dh_install
[2015-12-09 20:33:21] <agaida> und das - der macht die sich schon ist das Problem :)
[2015-12-09 20:34:27] <bluelupo> las mich raten - Rechte ;-)
[2015-12-09 20:34:33] <agaida> preinst postinst und andere scripte: bitte die Vorlagen nehmen und anpassen, bitte nicht selbst kreativ werden, wenn notwendig
[2015-12-09 20:34:59] <agaida> bluelupo: nö, aber schreibst Du da mistige Pfade rein, dann installiert der dahin
[2015-12-09 20:35:46] <agaida> ganz beliebte Fehlerquelle
[2015-12-09 20:36:54] <agaida> so - was du hoffentlich am anfang nicht brauchst: *.conf *.init *.service und andere spezielle Files werden natürlich von den helfern auch automatisch behandelt
[2015-12-09 20:37:18] <agaida> und automagisch an die richtige Stelle verschoben und mit den hoffentlcih passenden Rechten versehen
[2015-12-09 20:37:31] <bluelupo> ne die brauche ich nicht für den Anfang ;-)
[2015-12-09 20:37:40] <agaida> sei froh
[2015-12-09 20:37:50] <agaida> ok - links 
[2015-12-09 20:38:13] <agaida> source target
[2015-12-09 20:38:34] <agaida> der macht da irgendwas von - dokumentiert in dh_links
[2015-12-09 20:38:42] <agaida> wenn mans mal braucht
[2015-12-09 20:38:54] <bluelupo> wie beim Kommando "ln"
[2015-12-09 20:39:15] <agaida> so ähnlich
[2015-12-09 20:40:23] <agaida> und damit sind wir bei debian/rules
[2015-12-09 20:40:31] <bluelupo> die rules sieht bei inxi komplett anders aus
[2015-12-09 20:40:43] <agaida> nö, nich komplett
[2015-12-09 20:40:57] <agaida> rules ist immer ausführbar!
[2015-12-09 20:41:17] <bluelupo> okay
[2015-12-09 20:41:31] <agaida> und rules ist eine reinrassige make-Datei - das sollte man nie vergessen und immer im Hinterkopf haben
[2015-12-09 20:45:26] <agaida> #!/usr/bin/make -f
[2015-12-09 20:45:26] <agaida> # DH_VERBOSE=1
[2015-12-09 20:45:26] <agaida> %:
[2015-12-09 20:45:26] <agaida>         dh $@
[2015-12-09 20:45:35] <agaida> sollte für Dich reichen
[2015-12-09 20:46:50] <agaida> wenn Du die Raute bei DH_VERBOSE rausnimmst, spammt er Dich damit zu, was er aud dem einen Target %:
[2015-12-09 20:47:03] <agaida> und dem befehl dh $@ macht
[2015-12-09 20:48:10] <agaida> die Targets maintainer-clean und checkout werden nicht von %: angesprungen
[2015-12-09 20:48:35] <agaida> die könnte man mit debian/rules $target direkt erreichen
[2015-12-09 20:48:51] <agaida> halt die normale make syntax
[2015-12-09 20:49:40] <agaida> und ich empfehle ausdrücklich debuild zum Bauen der Pakete, ist einfach bequemer
[2015-12-09 20:50:06] <agaida> und nach dem Bauen setzt man zum Saubermachen ein debuild clean ab
[2015-12-09 20:51:05] <agaida> upps - und wir haben noch was vergessen: das sources-Verzeichnis
[2015-12-09 20:51:25] <bluelupo> debuild statt dpkg-buildpackage meinst du?
[2015-12-09 20:51:36] <agaida> die glorreichen Auswirkungen von debian/source/format hast Du schon kennengelernt
[2015-12-09 20:52:04] <bluelupo> jo ;-))
[2015-12-09 20:52:12] <agaida> da kann man dann auch noch allerhand andere neckische Sachen reinpacken, wie zum Beispiel options
[2015-12-09 20:52:33] <agaida> um Einfluss auf den Bau des Source-pakets zu nehmen
[2015-12-09 20:53:00] <agaida> oder andere Steuerungen - sollte man sich dann drüber informieren, wenn man es braucht
[2015-12-09 20:53:57] <agaida> was Du automatisch installiert hast ist ein elementares Hilfsmittel: lintian - Du wirst es hassen
[2015-12-09 20:54:47] <agaida> das ist das, was Dich nach dem Build auf Ungenauigkeiten und Fehler im Paket hinweist
[2015-12-09 20:55:08] <agaida> diese Hinweise sollte man ernst nehmen - erspart Ärger
[2015-12-09 20:55:20] <agaida> ich empfehle dazu einen Alias:
[2015-12-09 20:55:42] <agaida> alias evil=' lintian -EvIL +pedantic *changes'
[2015-12-09 20:56:07] <bluelupo> evil ist gut ;-))
[2015-12-09 20:56:41] <agaida> frei nach https://nthykier.wordpress.com/2012/02/23/some-sponsors-are-evil-and-pedantic/
[2015-12-09 20:56:52] <agaida> Niels weiss, wovon er schreibt
[2015-12-09 20:58:22] <bluelupo> oha hab' schon ein paar rote Zeilen
[2015-12-09 20:58:27] <agaida> :)
[2015-12-09 20:59:25] <agaida> wenn es um fehlende man-pages geht: man lege eine datei lintian-overrides an und male die Fehler da rein, die wirklich unwichtig sind
[2015-12-09 20:59:38] <agaida> den Rest sollte man tunlichst beheben
[2015-12-09 20:59:47] <bluelupo> ich nehm mal an das wird man als angehender Debian-Maintainer öfters nutzen müssen als einen lieb ist
[2015-12-09 21:00:41] <bluelupo> E: lvmsnap: subdir-in-usr-bin usr/bin/bin/ 
[2015-12-09 21:00:54] <agaida> das Tool ist eine sehr wertvolle Hilfe, wenn man nach ein-zwei Jahren den Wunsch überwunden hat, Niels Tykier vom Leben zum Tode zu befördern
[2015-12-09 21:01:20] <agaida> dann mach halt deine install ordentlich 
[2015-12-09 21:01:32] <agaida> dat ding mit dem foo bar :)
[2015-12-09 21:01:39] <agaida> :)
[2015-12-09 21:01:50] <agaida> bin usr/bin is doof
[2015-12-09 21:01:56] <bluelupo> ja, muss ich nochmal überarbeiten ;-)
[2015-12-09 21:02:03] <agaida> bin/* würde passen
[2015-12-09 21:02:28] <agaida> bin usr auch, glaube ich
[2015-12-09 21:03:06] <agaida> bäh - bin/* usr
[2015-12-09 21:04:29] -*- agaida denkt: und das geht jetzt genau so lange gut, wie nur ein binäres Paket aus der Source gebaut wird - wenn es denne mal mehr werden, dann werden die Karten neu gemischt
[2015-12-09 21:08:04] <bluelupo> okay, Danke agaida. War sehr hilfreich deine "Erklärungsstunde" zum Paketbau
[2015-12-09 21:08:46] <agaida> bluelupo: und das mit lintian haben wir bei lxqt eigentlich™ ganz gut hinbekommen :)
[2015-12-09 21:08:51] <agaida> https://lintian.debian.org/maintainer/pkg-lxqt-devel@lists.alioth.debian.org.html
[2015-12-09 21:10:01] <agaida> hat eventuell auch damit zu tun, dass ich immer noch der festen Überzeugung bin, dass unsere Pakete strikt primitiv gehalten werden und vor allem auch nicht gepatched werden sollten