Deux commentaires se plaignent du manque d'arguments en faveur de la simplicité avec laquelle on peut créer un paquet Setup.
Tout d'abord, voici ce que je trouve complexe avec les paquets Deb et Rpm (pour les autres, ABS etc, j'ai dit que j'aimais bien et que je m'en étais inspiré). Pour ces deux types de paquets, créer un «paquet simple» est une affaire de minutes. J'ai eu l'occasion de tester, c'est rapide et facile.
Seulement, quand les paquets deviennent un peu complexes (plusieurs binaires, bibliothèques, etc), ça devient plus difficile. Il faut adapter le Control pour que ça marche, le fichier Rules se complexifie, etc.
Un paquet ne répondant pas strictement aux normes est également plus difficile à produire. Pour le constater, prenez le paquet sources des kdelibs, ou de tout programme KDE empaqueté par l'équipe KDE de Debian. Le rules est simple, oui, mais il commence par une ligne pour inclure une monstrueuse et complexe suite de scripts faisant en sorte que le rules marche.
Pour RPM, j'ai cru voir (mais je n'en suis pas certain) qu'il faut taper manuellement le nom de tous les fichiers qu'on veut inclure dans le paquet. Ok, c'est faisable pour Qtracker ou autre programme composé d'un petit nombre de fichiers, mais essayez un peu avec un truc un peu gros comme OpenOffice.org, FireFox, les kdelibs, etc. Vous allez en avoir vite marre.
Du côté de Setup, un paquet simple est un peu plus compliqué à faire (on a du code à taper), mais la complexité augmente bien moins quand le paquet change. Par exemple, le packagebuild contient les instructions nécessaires à la compilation, à la manière d'un pkgbuild (d'ailleurs, le nom packagebuild s'inspire bien de pkgbuild, comme quoi je sais voir ce qu'il y a de bien chez les autres :) ). Si vous suivez le LFS un de ces jours, vous verrez que toutes les lignes de commandes pour appliquer des patchs sont données. Avec Setup, il suffit de les copier/coller dans le pkgbuild. Avec un paquet Debian (je ne sais pas pour RPM), ça peut aussi se faire mais il faut une adaptation.
Pour le fichier XML, il est auto-documenté (petits commentaires, et balises XML explicites). Le principe du XML n'est pas compliqué à apprendre, même si c'est plus complexe qu'un simple fichier «Clef: Valeur» comme Debian utilise. Par contre, ça permet plein de choses, comme l'arbre DOM. C'est grâce à l'utilisation du XML que les traductions sont si faciles à faire, alors que Debian nécessite un puissant gettext (encore un exemple que Setup reste simple quand Debian se complexifie atrocement). Les règles de validation pour les questions sont également gérées par arbre DOM, ce qui permet de les regrouper, de les modifier, etc. Il y a plein d'autres exemples.
Néanmoins, j'admet que ce n'est pas si simple qu'un PKGBUILD, mais Setup s'oriente un peu plus vers l'user-friendlyness que Pacman. Avec Setup, l'utilisateur peut configurer son paquet graphiquement au moment de l'installation, toutes les chaînes de caractère traduites dans sa langue. Ça a un pris pour le développeur, oui.
# De la facilité avec laquelle un paquet Setup est créé
Posté par steckdenis . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 2.
Deux commentaires se plaignent du manque d'arguments en faveur de la simplicité avec laquelle on peut créer un paquet Setup.
Tout d'abord, voici ce que je trouve complexe avec les paquets Deb et Rpm (pour les autres, ABS etc, j'ai dit que j'aimais bien et que je m'en étais inspiré). Pour ces deux types de paquets, créer un «paquet simple» est une affaire de minutes. J'ai eu l'occasion de tester, c'est rapide et facile.
Seulement, quand les paquets deviennent un peu complexes (plusieurs binaires, bibliothèques, etc), ça devient plus difficile. Il faut adapter le Control pour que ça marche, le fichier Rules se complexifie, etc.
Un paquet ne répondant pas strictement aux normes est également plus difficile à produire. Pour le constater, prenez le paquet sources des kdelibs, ou de tout programme KDE empaqueté par l'équipe KDE de Debian. Le rules est simple, oui, mais il commence par une ligne pour inclure une monstrueuse et complexe suite de scripts faisant en sorte que le rules marche.
Pour RPM, j'ai cru voir (mais je n'en suis pas certain) qu'il faut taper manuellement le nom de tous les fichiers qu'on veut inclure dans le paquet. Ok, c'est faisable pour Qtracker ou autre programme composé d'un petit nombre de fichiers, mais essayez un peu avec un truc un peu gros comme OpenOffice.org, FireFox, les kdelibs, etc. Vous allez en avoir vite marre.
Du côté de Setup, un paquet simple est un peu plus compliqué à faire (on a du code à taper), mais la complexité augmente bien moins quand le paquet change. Par exemple, le packagebuild contient les instructions nécessaires à la compilation, à la manière d'un pkgbuild (d'ailleurs, le nom packagebuild s'inspire bien de pkgbuild, comme quoi je sais voir ce qu'il y a de bien chez les autres :) ). Si vous suivez le LFS un de ces jours, vous verrez que toutes les lignes de commandes pour appliquer des patchs sont données. Avec Setup, il suffit de les copier/coller dans le pkgbuild. Avec un paquet Debian (je ne sais pas pour RPM), ça peut aussi se faire mais il faut une adaptation.
Pour le fichier XML, il est auto-documenté (petits commentaires, et balises XML explicites). Le principe du XML n'est pas compliqué à apprendre, même si c'est plus complexe qu'un simple fichier «Clef: Valeur» comme Debian utilise. Par contre, ça permet plein de choses, comme l'arbre DOM. C'est grâce à l'utilisation du XML que les traductions sont si faciles à faire, alors que Debian nécessite un puissant gettext (encore un exemple que Setup reste simple quand Debian se complexifie atrocement). Les règles de validation pour les questions sont également gérées par arbre DOM, ce qui permet de les regrouper, de les modifier, etc. Il y a plein d'autres exemples.
Néanmoins, j'admet que ce n'est pas si simple qu'un PKGBUILD, mais Setup s'oriente un peu plus vers l'user-friendlyness que Pacman. Avec Setup, l'utilisateur peut configurer son paquet graphiquement au moment de l'installation, toutes les chaînes de caractère traduites dans sa langue. Ça a un pris pour le développeur, oui.