[makepkg] modifs zé autres pensées.

Mise à jour / Création /debug de paquetages
Répondre
Avatar de l’utilisateur
mimas
Elfe
Messages : 559
Inscription : sam. 30 sept. 2006, 22:30
Localisation : Toulouse

[makepkg] modifs zé autres pensées.

Message par mimas »

J'ai persévéré avec mes modifications de makepkg. Ci-joint un patch permettant de :
- de compiler dans /tmp. Si vous êtes comme moi avec un /tmp en tmpfs, la vitesse de compilation est très largement augmentée.
- ajout d'un mot clef 'all' permettant de se passer de la liste des architectures sur lequel le paquet compile (arch=()).

Le mot clef all permet de compiler sur une architecture et de générer les paquet qui va bien en fonction de l'architecture sur laquelle il a été compilé. C'est différent de any qui génère un paquet pour l'architecture 'any' (hum... j'aurais vu noarch pour préciser l'indépendance vis-à-vis d'une architecture, et any* à la place de mon malheureux all (*as any architecture)). All permet de compiler un paquet i586 sur une machine avec le CARCH définit à i586 sans avoir à modifier la liste arch=() du PKGBUILD.

Il convient de préciser que l'on passe outre la vérification et si un paquet ne compile vraiment pas, car testé sur cette architecture, pour des raisons x ou y alors ça va merdoyer. All est donc à réserver pour ses paquets à soi afin d'éviter de faire de longues modifications sur les PKGBUILD. Du genre quand on a une longue liste de PKGBUILD perso et des machines aux architectures hétérogènes, comme moi. :)

Code : Tout sélectionner

--- scripts/makepkg.sh.in	2008-02-27 20:14:02.000000000 +0100
+++ scripts/makepkg-modif	2008-05-25 15:42:58.000000000 +0200
@@ -141,7 +141,7 @@
 		# If it's a clean exit and -c/--clean has been passed...
 		msg "$(gettext "Cleaning up...")"
 		cd "$startdir"
-		rm -rf pkg src
+		rm -rf pkg src /tmp/$pkgname/
 		if [ "$pkgname" != "" ]; then
 			# Can't do this unless the BUILDSCRIPT has been sourced.
 			rm -f "${pkgname}-${pkgver}-${pkgrel}-${CARCH}.log*"
@@ -1328,6 +1328,10 @@
 	CARCH='any'
 fi
 
+if [ "$arch" = 'all'  -o "$arch" = "" ]; then
+	arch=$CARCH
+fi
+
 if ! in_array $CARCH ${arch[@]}; then
 	if [ "$IGNOREARCH" = "0" ]; then
 		error "$(gettext "%s is not available for the '%s' architecture.")" "$pkgname" "$CARCH"
@@ -1346,6 +1350,11 @@
 	exit 1
 fi
 
+mkdir -p /tmp/$pkgname/{src,pkg}
+rm -rf $startdir/{src,pkg}
+ln -fs /tmp/$pkgname/src $startdir/src
+ln -fs /tmp/$pkgname/pkg $startdir/pkg
+
 # We need to run devel_update regardless of whether we are in the fakeroot
 # build process so that if the user runs makepkg --forcever manually, we
 # 1) output the correct pkgver, and 2) use the correct filename when
@@ -1464,6 +1473,7 @@
 	if [ -d "$pkgdir" -a "$REPKG" = "0" ]; then
 		msg "$(gettext "Removing existing pkg/ directory...")"
 		rm -rf "$pkgdir"
+		rm -rf "/tmp/$pkgname/pkg"
 	fi
 	mkdir -p "$pkgdir"
 	cd "$startdir"

Le patch est prévu pour le script de l'archive de pacman mais il devrait aussi fonctionner sur le makepkg installé.
Anarchy for the triple A.
Avatar de l’utilisateur
wain
Maître du Kyudo
Messages : 1854
Inscription : ven. 11 août 2006, 19:15
Localisation : Nancy (54)

Message par wain »

Très astucieux :D J'ai bien envie de tester le montage dans tmpfs. C'est pas trop embêtant quand le tmpfs arrive à saturation ? J'ai pas énormément de mémoire sur ma bécanne.

Pour makepkg, le truc sympas serait d'avoir une option --force qui correspondrait la somme de plusieurs switch. Example:

makepkg --replacefile (pour écraser un package déjà existant)
makepkg --anyarch (ton mot clef "all")
makepkg --force (somme des deux options précédentes).
Avatar de l’utilisateur
mimas
Elfe
Messages : 559
Inscription : sam. 30 sept. 2006, 22:30
Localisation : Toulouse

Message par mimas »

Ouaip pour l'option force et les autres.

Je suis actuellement en train de décider de la forme d'une option dans le PKGBUILD pour que gcc optimise autrement qu'avec le C(XX)FLAGS par défaut. Pour l'instant c'est de la forme options=(optimizeX) pour compiler avec le drapeau d'optimisation -OX* (avec X compris dans s,0,1,2,3,4), je ne sais pas encore si je dois transformer ça en optimize=1 (ou un autre mot clef).

Pour la mémoire j'ai 496MO dispo (tiens, il faut que je regarde combien j'ai alloué à cette mémoire partagée) et ça va assez bien. Le plus gros que je compile est wesnoth, il rentre très largement dans les 650MO du tmpfs.

Tmpfs prend sur le swap quand il n'y a pas assez de mémoire.

* http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html .
Anarchy for the triple A.
Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03

Message par tuxce »

intéressant :)
une proposition pour rendre le chemin paramétrable avec STARTDIR de la même facon que pour les répertoires de destinations SRCDEST et PKGDEST (en variable d'environnement, non dans le /etc/makepkg.conf)

Code : Tout sélectionner

--- /usr/bin/makepkg	2008-04-02 05:22:35.000000000 +0200
+++ makepkg	2008-05-25 19:56:50.000000000 +0200
@@ -36,6 +36,12 @@
 myver='3.1.4'
 confdir='/etc'
 startdir="$PWD"
+if [ $(id -u) != 0 ]
+then
+	startdir=${STARTDIR:-$startdir}
+	[ "$startdir" != "$PWD" ] && ln -sf "$(pwd)"/* "$startdir"
+	cd "$startdir"
+fi
 srcdir="$startdir/src"
 pkgdir="$startdir/pkg"
Dernière modification par tuxce le lun. 26 mai 2008, 16:12, modifié 1 fois.
Avatar de l’utilisateur
mimas
Elfe
Messages : 559
Inscription : sam. 30 sept. 2006, 22:30
Localisation : Toulouse

Message par mimas »

Intéressante cette modification avec STARTDIR, ça simplifie largement l'intégration du code.
Anarchy for the triple A.
Avatar de l’utilisateur
mimas
Elfe
Messages : 559
Inscription : sam. 30 sept. 2006, 22:30
Localisation : Toulouse

Message par mimas »

[MAJ]

tuxce, je n'ai pas intégré ta modification car il me faut réfléchir un plus plus pour trouver une solution afin d'avoir un répertoire de travail définissable du genre startdir=$workdir/$pkgname pour conserver un sous répertoire correspondant au nom du paquet à compiler.

J'ai fait un nouveau patch pour intégrer un flag --local-arch (l'utilisation de any est problématique avec la leur) et -O pour définir le niveau d'optimisation dans CFLAGS et CXXFLAGS (choix facile pour l'option ;)).

Plus un flag --force-all qui met --force et --local-arch.

http://mimasgpc.free.fr/libs/makepkg.diff
Anarchy for the triple A.
Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03

Message par tuxce »

mimas a écrit : tuxce, je n'ai pas intégré ta modification car il me faut réfléchir un plus plus pour trouver une solution afin d'avoir un répertoire de travail définissable du genre startdir=$workdir/$pkgname pour conserver un sous répertoire correspondant au nom du paquet à compiler.
oui c'était une modif pour moi, j'avais pas besoin de repertoire par paquet, j'utilise PKGDEST et SRCDEST pour garder les résultats...
j'ai voulu la modifier vite fait avant de te la proposer, le souci est que makepkg utilise $startdir avant de lire le $BUILDSCRIPT, c'est pour ca d'ailleurs que j'utilise STARTDIR direct des variables d'environnement sans utiliser le {/etc/,~/.}makepkg.conf, je verrais plus tard s'il y a possibilité de faire autrement ;)
Avatar de l’utilisateur
BadPotato
archer
Messages : 127
Inscription : dim. 26 août 2007, 19:57
Localisation : Canada - Québec

Message par BadPotato »

bonjour, je me demandais simplement si vous avez fait de nouveaux changements par rapport à ceci...

en attendant, j'essais encore de me documenter sur le fonctionnement de makepkg et ses possibilité.
Avatar de l’utilisateur
mimas
Elfe
Messages : 559
Inscription : sam. 30 sept. 2006, 22:30
Localisation : Toulouse

Message par mimas »

BadPotato a écrit :bonjour, je me demandais simplement si vous avez fait de nouveaux changements par rapport à ceci...
Absolument pas. De plus mon archlinux est en croix suite à une altération du système de fichiers que je suppose provoquée par la chaleur et une fluctuation dans la régulation de l'alimentation (satanés boitiers compacts qui ne supportent pas de vivre dans le sud et qui brassent autant d'air qu'un pet de mouche).

Bref je suis en train de préparer l'installation de mon amour de toujours : slackware. J'en avais assez des modifications majeures qui cassent le socle de la distro et empêchaient d'avoir ses propres outils stables ; l'incident a été une bonne raison pour ce changement.

Mais je suppose que je vais rester avec un système comme makepkg en adaptant buildpkg de chez zenwalk.
Anarchy for the triple A.
Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03

Message par tuxce »

mimas a écrit :J'en avais assez des modifications majeurs qui cassent le socle de la distro et empêchaient d'avoir ses propres outils stables ;
à ce point :shock:, c'est vrai que certaines modifs demandent certaines précautions, mais rien qui ne soit déjà documenté...
Avatar de l’utilisateur
mimas
Elfe
Messages : 559
Inscription : sam. 30 sept. 2006, 22:30
Localisation : Toulouse

Message par mimas »

tuxce a écrit :à ce point :shock:, c'est vrai que certaines modifs demandent certaines précautions, mais rien qui ne soit déjà documenté...
Le problème n'est pas la documentation mais l'apparente tendance à donner des coups de volant à gauche et à droite.

J'ai passé quelques années sur Archlinux et j'en arrive à la conclusion qu'il ne s'agit pas d'une distribution que l'on peut considérer comme mature mais d'une distribution laboratoire. J'ai envie de développer mes outils et de les améliorer pour mon propre confort d'utilisation, pas de devoir les retoucher lourdement tout les 6 mois parce qu'un changement majeur est passé par là, ou pire, de m'en passer parce que la motivation ou le temps n'est pas là.
Anarchy for the triple A.
Avatar de l’utilisateur
mélodie
Maître du Kyudo
Messages : 2784
Inscription : lun. 30 oct. 2006, 02:06
Localisation : Pyrénées

Message par mélodie »

mimas a écrit :...et j'en arrive à la conclusion qu'il ne s'agit pas d'une distribution que l'on peut considérer comme mature mais d'une distribution laboratoire.
Je crois que comprends maintenant pourquoi ton logo est plein de trous ? Ce sont les souris qui sont passées par là... :roll:

Bon bon, je sors ! →[]
Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03

Message par tuxce »

le seul souci que j'ai vu, depuis que j'utilise arch est celui du module loop pour tout ceux qui utilisait pacman-cage (qui n'est pas supporté), mais bon, je dois pas utiliser trop de paquets peut etre :)
Avatar de l’utilisateur
mimas
Elfe
Messages : 559
Inscription : sam. 30 sept. 2006, 22:30
Localisation : Toulouse

Message par mimas »

@mélodie, je ne sais pas ce qu'il font avec leurs fromages. Ils les vendent déjà avec des trous. Vive le comté au moins là bas on ne vend pas des aliments troués.

@tuxce, ce n'est pas une histoire de nombre de paquet, ma distro tient (tenait) dans 800 Mo et des inodes. C'est juste que j'avais pour coutume d'adapter les outils fournis avec le système pour en faire d'autres qui convenaient mieux à mon usage. Lorsque j'ai fait un binding pour la librairie de pacman et que pas mal de choses ont changer dedans entre deux numéros de version mineurs, j'étais super content. Idem pour makepkg.

Bref à l'utilisation ça ne change pas grand chose mais lorsqu'on va plus loin on se rend compte que les outils ne sont pas stables (dans le sens figé).
Anarchy for the triple A.
Avatar de l’utilisateur
wain
Maître du Kyudo
Messages : 1854
Inscription : ven. 11 août 2006, 19:15
Localisation : Nancy (54)

Message par wain »

mimas a écrit :Bref à l'utilisation ça ne change pas grand chose mais lorsqu'on va plus loin on se rend compte que les outils ne sont pas stables (dans le sens figé).
Je plussoie malheureusement. Il y a de quoi dégouter toute tentative de contribution :cry:
Visiblement la donne est peut-être en train de changer car les devs ont compris le besoin qu'on les gens d'avoir rapidement une stabilisation de libalpm (pour shaman par exemple). Une chose est sûre, les développements pour archlinux sont fait pour améliorer l'existant des utilisateurs, au détriments des développeurs "non officiels".
Je ne sais pas si d'autres distributions font un réel effort pour faciliter le travail des contributeurs. Si c'est le cas, je pense plutôt qu'il s'agit de distributions qui évoluent peu, soit parceque le projet est ralenti, soit parceque l'objectif initial est atteint. C'est probablement le cas de slackware. On ne peut pas en attendre autant d'une distribution bleeding edge comme archlinux.
Avatar de l’utilisateur
warnaud
Maître du Kyudo
Messages : 1640
Inscription : ven. 11 août 2006, 17:05
Localisation : Rolle (CH)

Message par warnaud »

Je pense surtout qu'il est difficile pour les devs de permettre des contribution sur les fondements d'archlinux (malheureusement). Car pour tout le reste y'a pas trop de soucis
Plus ça rate, plus ça a de chance de réussir. En somme, un succès n'est qu'une erreur qui a finit par réussir (même par erreur). Ne déséspérez donc pas et perseverez. Utilisez La Rache™
Patientia quod lard quod barrus planto diligo ut licentia
—¤÷(`[¤*Powered By *¤]´)÷¤—
Archlinux ~ Fvwm ~ Irssi ~ URxvt
Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03

Message par tuxce »

j'ai pas de soft utilisant libalpm, mais je pense que la question serait de savoir si le changement que font les devs apportent un plus ou pas, si c'est le cas, ca vaut surement le coup de la modifier...
maintenant, si la compatibilité pour une fonctionnalité "documentée" est cassée, ils devraient effectivement changer de versions majeur, mais si c'est une question de parser la sortie ou autre, ca arrive dans tous projets, quelque soit la distribution.

pour slackware, en meme temps, une personne décide ;)
Répondre