Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #137614 > unrolled thread

Archlinux: Paketierung

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Archlinux: Paketierung Peter Blancke <blancke@gmx.de> - 2024-02-10 12:21 +0000
    Re: Archlinux: Paketierung Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-02-10 15:49 +0100
      Re: Archlinux: Paketierung "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-02-10 16:30 +0100
    Re: Archlinux: Paketierung Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2024-02-10 16:04 +0100
      Re: Archlinux: Paketierung Peter Blancke <blancke@gmx.de> - 2024-02-10 17:54 +0000
      Re: Archlinux: Paketierung Peter Blancke <blancke@gmx.de> - 2024-02-10 19:57 +0000
        Re: Archlinux: Paketierung Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2024-02-11 00:18 +0100
          Re: Archlinux: Paketierung Peter Blancke <blancke@gmx.de> - 2024-02-11 13:07 +0000
            Re: Archlinux: Paketierung Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2024-02-11 16:49 +0100

#137614 — Archlinux: Paketierung

Erbitte einen kleinen Denkanstoß.

Gegeben sei ein Skript:

,----[ meldung.sh ]
| #!bin/sh
| gxmessage "Ein Text"
`----

Wenn Pacman "gxmessage" löscht, kann das Skript natürlich nicht mehr
ausgeführt werden. Sicherlich kann ich die Existenz von "gxmessage"
im Skript prüfen ("test -x"), aber das Skript wird NICHT erfolgreich
ausgeführt.

Da mir das in einem anderen Skript dieser Tage böse auf die Füße
fiel, wäre es doch das einfachste, aus o. a. Skript ein Paket zu
bauen, welches mit pacman dann installiert wird.

Wird dann versucht, "gxmessage" zu löschen, sollte sich pacman über
die Abhängigkeit beschweren und das Löschen verweigern.

Tja, da stehe ich vor einer neuen Aufgabe: Wir paketiere ich das o.
a. Skript?

Kann mir jemand einen Denkanstoß geben? Die Vielzahl von
Beschreibungen zur Paktierungen kompletter Programme überfordert
mich vermutlich -- Neuland für mich.

Danke.

Gruß,

Peter Blancke

-- 
Hoc est enim verbum meum!

[toc] | [next] | [standalone]

#137616

Peter Blancke <blancke@gmx.de> wrote:
>Wird dann versucht, "gxmessage" zu löschen, sollte sich pacman über
>die Abhängigkeit beschweren und das Löschen verweigern.

Die Lösung für Debian war zwar nicht gefragt, aber vielleicht hilft es
jemand anderem: In Debian gibt es das Paket "equivs", mit dem man ein
(leeres¹) Paket schnüren kann, das auf gxmessage dependet. Auf diese
Weise wird bei der Dinstallation von gxmessage immerhin gemeckert.

Grüe
marc

¹ wenn es wirklich nur _ein_ Skript ist, kann man mit einem geeigneten
equivs-Konfigurationsfile auch dieses Skript mit in das Dummypaket
packen, aber das wäre nach meiner Wahrnehmung schon Overkill und ein
Grund ein "richtges" Paket zu machen. Und diese Lernkurve ist auch für
Debian hoch

-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#137618

On 2024-02-10 14:49, Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> ¹ wenn es wirklich nur _ein_ Skript ist, kann man mit einem geeigneten
> equivs-Konfigurationsfile auch dieses Skript mit in das Dummypaket
> packen, aber das wäre nach meiner Wahrnehmung schon Overkill und ein
> Grund ein "richtges" Paket zu machen. Und diese Lernkurve ist auch für
> Debian hoch

Wobei allerdings das bauen von Paketen, die nur aus ein paar Files
bestehen, die nicht extra erzeugt werden müssen (also z.B. Scripts)
recht einfach ist - die muss man nur in das File debian/*.install
eintragen.

        hp

[toc] | [prev] | [next] | [standalone]

#137617

Am Sa, 10.02.2024 um 12:21 schrieb Peter Blancke:

> Tja, da stehe ich vor einer neuen Aufgabe: Wir paketiere ich das o.
> a. Skript?

| # Maintainer: Peter Blancke <blancke@gmx.de>
| pkgname=meldung
| pkgver=0.1
| pkgrel=1
| pkgdesc="Meldungsskript"
| arch=(any)
| depends=(bash gxmessage)
| source=($pkgname.sh)
| sha256sums=('bdf883df5218289ee3691cca34d7d3bb5453676251f5d30a7f986e7baabfc9ef')
| 
| package() {
| 	install -Dm 0755 $pkgname.sh $pkgdir/usr/bin/$pkgname.sh
| }

-- 
‣ Powered by Arch Linux x86_64 🐧 Kernel: 6.7.3-arch1-1
‣ Installed 3709 days ago, up 6 days, 6 hours, 18 minutes
‣ +++ Heruntergekommen: Obdachloser verlässt Baumhaus +++

[toc] | [prev] | [next] | [standalone]

#137619

Am 2024-02-10, Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> schrieb:
> Am Sa, 10.02.2024 um 12:21 schrieb Peter Blancke:

>> Tja, da stehe ich vor einer neuen Aufgabe: Wir paketiere ich das
>> o. a. Skript?

>| # Maintainer: P#### B###### <b######@gmx.de>
>| pkgname=meldung
>| pkgver=0.1
>| pkgrel=1
>| pkgdesc="Meldungsskript"
>| arch=(any)
>| depends=(bash gxmessage)
>| source=($pkgname.sh)
>| sha256sums=('bdf883df5218289ee3691cca34d7d3bb5453676251f5d30a7f986e7baabfc9ef')
>| 
>| package() {
>| 	install -Dm 0755 $pkgname.sh $pkgdir/usr/bin/$pkgname.sh
>| }

Danke für so schnelle Hilfe!

Und schon etwas, womit man morgen den Sonntag füllen kann. Ich werde
das ausgiebig studieren.

Gruß,

Peter Blancke

-- 
Hoc est enim verbum meum!

[toc] | [prev] | [next] | [standalone]

#137626

Am 2024-02-10, Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> schrieb:
> Am Sa, 10.02.2024 um 12:21 schrieb Peter Blancke:

>> Tja, da stehe ich vor einer neuen Aufgabe: Wir paketiere ich das
>> o. a. Skript?

>| # Maintainer: P#### Blancke <b######@###.##>
>| pkgname=meldung
>| pkgver=0.1
>| pkgrel=1
>| pkgdesc="Meldungsskript"
>| arch=(any)
>| depends=(bash gxmessage)
>| source=($pkgname.sh)
>| sha256sums=('bdf883df5218289ee3691cca34d7d3bb5453676251f5d30a7f986e7baabfc9ef')
>| 
>| package() {
>| 	install -Dm 0755 $pkgname.sh $pkgdir/usr/bin/$pkgname.sh
>| }

Mit diesen Denkanstößen findet man plötzlich alles, was erforderlich
ist. Danke.

Eine gute Beschreibung nebst Lösung _exakt_ meiner Frage findet sich
unter

  https://itsfoss.com/create-pkgbuild/#arch

Dann halfen mir:

- https://wiki.archlinux.org/title/PKGBUILD

sowie die manpages zu "namcap" und "makepkg".

Es ist alles einfacher, als ich befürchtete.

Ich tendiere dazu, alles, was meine eigenen lokalen Arbeitsskripte
anbelangt, unter /usr/local installieren zu lassen, vor allem dort
unter ./bin und ./etc -- mehr brauche ich nicht. Irgendwie will ich
das aus dem sonstigen System raushalten. Außerdem ist /usr/local
hier auch ein eigenes ZFS-Dataset. Mache ich das richtig so?

Gruß,

Peter Blancke

-- 
Hoc est enim verbum meum!

[toc] | [prev] | [next] | [standalone]

#137630

Am Sa, 10.02.2024 um 19:57 schrieb Peter Blancke:

> Es ist alles einfacher, als ich befürchtete.

Das ist eben die Arch-Philosophie, nach dem KISS-Prinzip eine Aufgabe
möglichst einfach zu lösen. Dazu gehört dann konsequenterweise auch das
Erstellen von Installationspaketen.

Idealerweise erstellt man die Pakete in einem clean chroot, dazu gibt es
auch eine gute Beschreibung:
https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

Das hat den Vorteil, dass die Pakete in einer eigenen und neutralen Umgebung
gebaut und die nötigen Abhängigkeiten erkannt werden. Das wäre für eine
Weitergabe der Pakete wichtig, auch wenn das nicht dein Anwendungsfall sein
dürfte. 

Außerdem werden die für das Bauen der Pakete nötigen Abhängigkeiten auch in
dieser Umgebung installiert und damit nicht das produktive System belastet.
Wenn ich beispielsweise 'gxmessage' als Abhängigkeit setze, würde das
Bauen des Pakets in der produktiven Umgebung für mich als KDE-Anwender einen
Rattenschwanz an Installationen zusätzlicher Pakete nach sich ziehen,
obwohl ich sie eigentlich gar nicht brauche. 

In einem clean chroot gibt es nur ein Basissystem, aus dem für das Bauen
der Pakete ein Arbeitsverzeichnis erstellt und um die zusätzlich Pakete
ergänzt wird. Danach wird es wieder verworfen, so dass ich immer eine
saubere Umgebung für das nächste zu bauende Paket vorfinde.

Wenn du es noch perfekter haben möchtest, kannst du für deine eigenen
Pakete auch ein lokales Repository erstellen und das in die
pacman-Konfiguration als zusätzliche Installationsquelle aufnehmen. Dann
kannst du die Pakete wie jedes andere "offizielle" Paket installieren, es
wird in den Suchen oder auch bei einer Aktualisierung berücksichtigt. Das
ist vor allem interessant, wenn du Abhängigkeiten eines eigenen Pakets auf
ein anderes eigenes Paket setzt, die werden dann auch automatisch
aufgelöst. Vor allem erscheinen sie bei der Suche auch nicht mehr als
lokales sondern zu einem Repo zugehörigen Paket. 
 
> Ich tendiere dazu, alles, was meine eigenen lokalen Arbeitsskripte
> anbelangt, unter /usr/local installieren zu lassen, vor allem dort
> unter ./bin und ./etc -- mehr brauche ich nicht. Irgendwie will ich
> das aus dem sonstigen System raushalten. Außerdem ist /usr/local

Eine Trennung ist eigentlich nicht nötig. Die Hierarchie ist für lokale,
also am Paketmanagement vorbei installierte Anwendungen vorgesehen.
namcap gibt dazu auch eine Warnung heraus, dass es sich dabei um ein
Nicht-Standard-Verzeichnis handelt. 

In dem Moment, in dem die Dateien als Paket installiert und damit dem
Paketmanagement bekannt sind, kann man sie als zum System zugehörig
betrachten. Du musst nur etwas aufpassen, dass deine Paket- und Dateinamen
nicht mit den offiziellen Paketen kollidieren. Entweder lässt sich dann
dein Paket wegen des Konflikts nicht installieren, oder ein später aus dem
offiziellen Repo geholtes Paket lässt sich nicht installieren oder
aktualisieren. Das kann man aber vorher prüfen und ggfls. musst du dann
dein Paket oder die im Konflikt stehenden Dateien ändern. Solange du bei
deutschen Bezeichnungen bleibst, dürfte aber nichts anbrennen. 

> hier auch ein eigenes ZFS-Dataset. Mache ich das richtig so?

Du Kannst ja noch die Meinungen anderer Mitlesenden abwarten und dann die
finale Entscheidung treffen, wie du es machen möchtest. Ich habe
mittlerweile und seit Jahren schon etliche eigene Pakete ins System
integriert und bisher kam es noch nie zu irgendwelchen Kollisionen. 

-- 
‣ Powered by Arch Linux x86_64 🐧 Kernel: 6.7.3-arch1-1
‣ Installed 3709 days ago, up 6 days, 13 hours, 51 minutes
‣ +++ Bandenwerbung: Hell's Angels werben neue Mitglieder in 
  Fußballstadien +++

[toc] | [prev] | [next] | [standalone]

#137633

Am 2024-02-10, Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> schrieb:
> Am Sa, 10.02.2024 um 19:57 schrieb Peter Blancke:

>> Es ist alles einfacher, als ich befürchtete.

> Das ist eben die Arch-Philosophie, nach dem KISS-Prinzip eine
> Aufgabe möglichst einfach zu lösen. Dazu gehört dann
> konsequenterweise auch das Erstellen von Installationspaketen.

Nochmals tausend Dank für alle geduldigen Erklärungen. Jetzt ist mir
alles sonnenklar und alles funktioniert gem. KISS auf Anhieb und
einwandfrei.

> Idealerweise erstellt man die Pakete in einem clean chroot, dazu
> gibt es auch eine gute Beschreibung:
> https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

Das habe ich auch studiert und sofort verstanden und umgesetzt.

Es verwunderte mich schon, daß in dem gebauten Paket die Datei
".BUILDINFO" meine gesamte Intimität durch Verweis aller meiner
installierter Pakete offenlegte. Der Spuk war im chroot latürnich
sofort vorbei. Gut zu wissen, auch wenn ich hier erst mal nur für
mich alleine paketiere.

>> Ich tendiere dazu, alles, was meine eigenen lokalen
>> Arbeitsskripte anbelangt, unter /usr/local installieren zu
>> lassen,

> Eine Trennung ist eigentlich nicht nötig.
> [...]

Ja, auch das leuchtet mir ein.

Die strikte Trennung von Distribution und eigenem Kram stammt
eigentlich aus der Zeit, da ich noch nicht Archlinux nutzte, ergo
also noch kein Rolling-System.

"namcap" beschwert sich bei mir im übrigen NICHT, wenn ich als
Installationspfade auf /usr/local verweise.

Vielen Dank für die Geduld!

Gruß,

Peter Blancke

-- 
Hoc est enim verbum meum!

[toc] | [prev] | [next] | [standalone]

#137636

Am So, 11.02.2024 um 13:07 schrieb Peter Blancke:

> "namcap" beschwert sich bei mir im übrigen NICHT, wenn ich als
> Installationspfade auf /usr/local verweise.

Wenn ich 

| install -Dm 0755 $pkgname.sh $pkgdir/usr/local/bin/$pkgname.sh

setze, steht in meldung-0.1-2-any.pkg.tar.zst-namcap.log unter anderem 

| meldung W: File (usr/local/) exists in a non-standard directory.
| meldung W: File (usr/local/bin/) exists in a non-standard directory.
| meldung W: File (usr/local/bin/meldung.sh) exists in a non-standard directory.

Das ist aber nur eine Warnung und das Paket wird trotzdem erstellt. 

-- 
‣ Powered by Arch Linux x86_64 🐧 Kernel: 6.7.4-arch1-1
‣ Installed 3710 days ago, up 7 hours, 15 minutes
‣ +++ Einen an der Klatsche: Psychotiker behauptet, Elefanten mit 
  Fliegenfänger töten zu können +++

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web