Archlinux.fr [Forums]

Je soumets mon test de PKGBUILD à votre régard : Il s'agit d'un PKGBUILD pour l'installation personnalisée par utilisateur de dwm, avec patchage maison :
– dépend du paquet dwm pour les licences, man et README
– les patches « utilisateur » sont appliquer automatiquement en chercher les .diff dans un répertoire qui va bien
– un paquet dwm-bobo-$pkgver.tar.xz est créé

Je me suis arrêté quand j'ai réalisé que l'installation via pacman dans le home de l'utilisateur n'était peut-être pas souhaitable. Je ne sais pas ce que vous en pensez.

Verriez-vous un workflow qui permettrait de distribuer ce PKGBUILD "dwm-custom" dans AUR ?

bobo a écrit :Je me suis arrêté quand j'ai réalisé que l'installation via pacman dans le home de l'utilisateur n'était peut-être pas souhaitable. Je ne sais pas ce que vous en pensez.

Qu'une telle installation est totalement à proscrire.

C'est bien ce que je me disais En tout cas, ça a été drôle de jouer avec makepkg.

La configuration utilisateur de dwm passe par la recompilation du binaire après modification des sources. Du coup le mieux c'est d'avoir le binaire dans le home de l'utilisateur. Comme j'ai pu l'expérimenter, le PKGBUILD peut prendre en charge toutes les manips' de compilation de dwm. Je me demande s'il est possible en l'état de détourner du pacman/yaourt pour gérer les binaires utilisateurs avec un système à base de PKGBUILD.

Édition:
Le plus simple serait sans doute de documenter une méthode d'installation à partir de makepkg directement

Disons que de manière générale, un gestionnaire de paquets NE DOIT PAS toucher au répertoire personnel de l'utilisateur (donc un PKGBUILD ne doit pas contenir de références vers /home).
Mais après, rien interdit de mettre lesdits fichiers dans un répertoire tel /usr/share/blablabla. Et puis, chose qui n'est pas impossible de faire, c'est de créer un script qui permet de copier ces fichiers depuis /usr/share/blablabla vers le répertoire personnel, script qui peut être ajouté au paquet. Après il faut garder en tête qu'il faut avertir l'utilisateur qu'un tel script n'est pas officiel et qu'il l'utilise à ses risques et périls. Il faut que la personne qui écrit le script prenne toutes les précautions nécessaires (comme ne pas effacer des fichiers de l'utilisateur, écraser des fichiers qui existent déjà sans les sauvegarder, ...).
Enfin, il y a toujours moyen de bricoler quelque chose quand on veut automatiser une tâche.

Merci Xorg !!

Ça ça pourrait être marrant : un PKGBUILD fourni par un paquet, avec script makepkg pour compiler est installer le binaire dans le /home/$USER/bin, en appliquant patches et config.h à partir de la structure de fichier de /home/$USER/.config/dwm

Non, cela reste une mauvaise idée. Par contre tu peux très bien faire un script reprenant l'idée du PKGBUILD mais ne créant pas de paquet ni utilisant makepkg.

bobo a écrit :script makepkg pour compiler est installer le binaire dans le /home/$USER/bin

Je pense que tu n'as pas compris ce que j'ai dit plus haut. Ton PKGBUILD décrit à makepkg tout ce dont il a besoin pour créer le paquet binaire. Donc toutes références vers /home est à proscrire d'un paquet.

L'idée c'est de faire un script qui copie ce que tu as à copier dans le $HOME, mais ce script ne doit pas intervenir dans le création d'un paquet (genre l'exécuter directement depuis le PKGBUILD ou bien depuis un fichier .install).

OK, je retiens que makepkg est dédié à la création de paquet système (à utiliser avec les droits administrateurs, pour le suivi centralisé du contenu des dossiers systèmes). Un script d'installation automatisé ne doit pas utiliser makepkg. Il peut être rendu dispo dans un paquet .tar.xz en l'installant dans l'arborescence qui va bien "/usr/share/…". Et serait à exécuter par l'utilisateur lui-même.

Merci pour m'avoir aidé à mettre au point ce scénario (en espérant que j'ai bien compris). Ce serait bien que je m'y colle : je verrais bien un dépôt git pour centralisé les patches, en pushant les sources dwm dedans.

Si tu veux, pour détailler mes propos, j'avais été confronté à un problème presque similaire une fois : je voulais pouvoir utiliser MemTest86 (car depuis la version 5.0, c'est un exécutable EFI), mais il n'y avait pas de paquet le distribuant dans ArchLinux.
Ainsi, j'ai créé le paquet memtest86-efi, qui au final ne fait qu'installer ses fichiers dans /usr/share/memtest86-efi/. Bien entendu, ce n'est pas un répertoire d'amorce, mais je ne peux pas me permettre de mettre le fichier dans l'ESP pour plusieurs raisons (l'ESP est-il monté ? Si oui où ça ? Où le placer dans l'ESP ? Comment amorcer ce fichier ? Etc...).
J'ai donc écrit un script, memtest86-efi, que j'ai intégré au paquet. Ce script aide les utilisateurs à installer les fichiers dans l'ESP (plusieurs méthodes sont proposées, ils prennent celle qui correspond le plus à leurs attentes), ils l'utilisent à leurs risques et périls, rien ne les oblige à utiliser ce script (ils peuvent très bien faire les manipulation à la main après tout).
En bref, c'est pour dire que le paquet en lui-même fait rien, il place des fichiers dans un répertoire, mais ça n'a pas d'incidence sur le système.

Tu parles de faire un script d’installation automatisée qui utiliserait makepkg. Si tu veux tu ne peux pas faire ça car ça revient en fin de compte à créer un paquet qui installera dans fichiers dans le /home dans tous les cas. Tu peux faire un script d’installation automatisée, mais oublie makepkg pour toucher au /home (autant écrire un script qui fonctionnera sur toutes les distributions, ça sera sans doute plus utile ).

Je t'invite à jeter un œil ici, pour te monter qu'on ne te dit pas ça pour t'embêter mais que c'est un standard de paquetage.

Merci pour le lien !

Je ne l'avais pas pris mal, si ça peut te rassurer. C'est justement pour obtenir ce type de retour que j'ai soumis mon approche. Je voyais bien que quelque chose clochait, mais n'arrivais pas à mettre le doigt dessus, tant j'étais sous le charme de la hackabilité des PKGBUILDs.

Je viens de créer un fil sur le script d'install perso que j'ai créé :
viewtopic.php?f=13&t=17807#p150171