J'ai écris des PKGBUILDs pour abiword, abiword-extra (contient principalement des modèles) et abiword-plugins. N'ayant qu'un pc sous archlinux x86_64, je n'ai pas pue tester en i686 même si il n'y a aucune raison que sa pose de problème.
THIS ADVICE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
En clair, je ne pourrais être tenu responsable des dégats causés par l'utilisation de mes conseils
Heu pas vraiment, je me suis basé sur le PKGBUILD officiel pour écrire celui là et j'ai pas trouvé à quoi sa correspond. J'ai même pas essayé de compiler sans mais si tu veux je peux faire le test.
Edit :
J'ai mis à jours les PKGBUILDs au niveau des dépendances (corrigé grace à namcap) et j'ai enlevé l'option bizarre.
Les paquets compile (en x86_64) et le programme fonctionne.
Cela vide la variable MAKEFLAGS définie dans makepkg.conf. C'est utile si le programme ne supporte pas la compilation en parallèle avec make, genre utilisation des différents cœurs avec MAKEFLAGS="-J2" toussa...
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
Pour ce qui est des dépendances, quand je créer un PKGBUILD, je liste les dépendances demandées par le développeur en lisant les doc d'installation du programme pas en faisant une confiance absolu en ce qui a été fait pour les versions précédentes.
Mon avis sur namcap, c'est que c'est bien pour trouver les dépendances oubliées mais pas l'inverse.
Bon après si vous voulez absolument que j'enlève les dépendances qui ne sont pas dans le PKGBUILD "officiel" de la version 2.4, OK, je le ferais.
En fait, namcap s'occupe justement de "tout" (à vérifier quand même mais bon).
En gros si un soft A a comme dépendance un soft B qui a pour dépendance un soft C, dans le pkgbuild du soft C t'as juste a mettre B car A sera de base installé.
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
cdemoulins, comme disent marc[i1] et warnaud, sous arch il faut respecter cette règle dans la gestion des dépendances.
Au pire, tu peux aujouter toutes les deps au début puis lancer namcap qui te dira quelles sont les dépendances déjà inclues. Par exemple si tu mets pygtk et python, namcap te dis que python est une dépendance déjà inclue dans pygtk et qu'elle n'est pas nécessaire. Pas question de faire des paquetages avec la totalité des dépendances comme dans RPM ou deb.
Pour les paquetages non compilés (perl/python/bash/etc..) namcap n'est pas fiable et il faut effectivement se baser sur les deps indiquées par l'auteur. Pour les paquetages compilés, namcap utilise ldd pour retrouver les deps et c'est suffisemment fiable.
marc[i1] a écrit :Les gens venant de système rpm et deb ont souvent tendance à tout mettre, ce qui est superflu pour Arch
Pas sûr que ce soit superflu. Cela par du principe que l'utilisateur du paquet possède une archlinux brute de fonderie, sans paquets retouchés, ce qui n'est peut-être pas le cas.
C'est sûr que dans le cas python et pygtk on ne peut pas se tromper. Dans d'autre cas, comme les libgnome, où la relation de parenté n'est pas obligée, il peut il avoir problème.
Je suis en train d'écrire un programme qui permet de déterminer les dépendances inutiles. C'est dans le même style que namcap mais ça se base sur les dépendances indiquées dans le PKGBUILD.
Exemple :
On a un programme A qui a pour dépendances B et C.
Sachant que B dépend également de C.
$ mon_programme /var/abs/local/A/PKGBUILD
=> C est déjà inclus
J'ai également ajouté une option permettant de dessiner un joli arbre des dépendences.
Voilà un petit exemple pour mon PKGBUILD de deluge qui a une dépendence en trop : pygtk
THIS ADVICE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
En clair, je ne pourrais être tenu responsable des dégats causés par l'utilisation de mes conseils