Re: Quelques questions

[gwenhael <gwenjo@xxxxxxx>]

Salut 
> 
> Re...
> 
> > Je suit tout à fait ok, mais le problème c'est que si le mainteneur
> > décide de mettre --with-x il est théoriquement nécessaire de modifier
> > le receipt pour parvenir à désactiver cette option non? L'intéret à
> > mon sens dans le cas où l'on souhaite bien plus afiner la compilation
> > de chaques paquets serait une sorte de mise en place d'options
> > globales.... Voir pourquoi pas des options bien spécifiques au
> > paquets. Si je met des --enable-machin ou --without-truc dans le
> > CONFIGURE_ARGS de tazwok.conf concernant php afin d'afiner vim n'en
> > as pas grand chose à faire et risque de mettre des messages
> > d'avertissement. Si le receipt réalise une ligne de compilation en
> > regardant les options qui le concerne la ligne sera moins lourde et
> > plus adaptée .
> >
> 
> Il y de l'idée et oui super bien.
> 
> > > > Si un utilisateur souhaite créer son propre iso en
> > > > enlevant/ajoutant des fonctions il va devoir dans ce cas modifier
> > > > l'ensemble des receipt pour tous les package dont il a besoin.
> > > > C'est un travail qui est relativement fastidieux et s'il n'y
> > > > prend pas garde en mettant à jour le wok il va perdre une
> > > > partie/tout son travail. Ne serait-il
> > > 
> > > Non, aucune recette n'a besoin d'être modifié pour créer son ISO
> > > avec avec les paquets officiel.
> > > 
> > 
> > Dans le cas d'un ISO avec paquets officiel mais dans le cas d'un ISO
> > avec paquets "perso"?
> > 
> 
> Oh mais si un user commence à compiler pour créer ses paquetos c'est
> qu'il a installer compilateur libs-dev, qu'il n'est plus un débutant et
> qu'il devrait s'attendre à bidouiller ? Cela dis l'idée des otions
> centralisé faciliterait la vie.
> 
Ben oui, c'est clair qu'il a déjà quelques compétences, mais de sortir les nécessités de modification des receipt pour permettre leur centralisation ailleurs aiderait grandement d'une part à dégrossir la configuration, et si le wok est mis à jour, éviterai un fastidieux travail de comparaison pas forcément évident afin de déterminer quels sont les receipt qui n'ont pas étaient touchés par l'utilisateur et ceux qui ont était modifié par le mainteneur.
Si l'utilisateur n'as plus besoin de toucher au receipt il peut envoyer une mise à jour sans trop se prendre la tête.
Au fond le seul cas où il aurait besoin de regarder le receipt serait pour faire un "grep WITH receipt" afin de savoir qu'elles sont options dispo.
> 
> > > Ben en fait il suffit de modifier la liste des paquets à installés.
> > > Cette liste est utilisée par Tazlito pour générer l'ISO, il est
> > > indépendant de Tazwok ou Tazpkg.
> > > 
> > 
> > Oui mais que ce passe t'il si un logiciel est compilé avec le support
> > de gtk et que l'ISO soit construit sans lui? le logiciel a des
> > chances de pas retrouver ses petits.
> > 
> 
> CF la discuss sur IRC, on reprende le code de Tazpkg pour Tazlito et on
> gère les deps lors de la création d'ISO.
> 
Est ce que ce ne serait pas possible que lors de la création du tazpkg, on stipule dans un fichier genre Manifest quels sont les dépendances, de cette manière il n'y a plus besoin de laisser à Tazlito la nécessité de marcher dans les platebandes des autres?
> 
> > > 
> > > J'ai vite fait la recette de Vim comme exemple... Regarder d'autres
> > > paquets qui on des locales (leafpad), je copie que le français.
> > > 
> > 
> > Si l'on met en place un systeme permettant de stipuler la ou les
> > langues souhaitées dans le cas de l'utilisation d'un paquet recompilé
> > ça pourrait permettre d'agrandir le support des langues relativement
> > facilement, bien entendu la base du système ne serait pas localisé
> > mais au moins les logiciels
> > 
> 
> Encore un très bonne idée, je prends!
> 
Un truc genre lang="fr_FR fr_CH ..." dans le tazwok.conf et une petite
boucle for l in $lang dans receipt -> genpkg_rules() par exemple?
 
> > > 
> > > De toute façon je crois pas qu'on peut comparer... SliTaz la
> > > mini/micro/nano/pico à *BSD, Gentoo ou Slackware. Je te conseil
> > > aussi de lire le post de MilkaJinka et ma réponse :
> > > 
> > > http://listengine.tuxfamily.org/lists.tuxfamily.org/slitaz/2007/11/msg00041.html
> > > 
> > Je suis absolument d'accord avec toi mais certains concepts peuvent
> > être interessant de mettre en oeuvre, peut être pas en poussant à
> > fond mais certaines choses peuvent être mises en oeuvre aisément.
> 
> C'est sur, rien empèche de regarder ailleurs, c'est comme cela que les
> autres au passage...
> 
C'est un des concepts du logiciel libre en fait. Et puis à quoi bon réinventer le fil à couper l'eau chaude quand on peut se baser sur des choses déjà imaginées ?
  
> > J'ai fait quelques test sur une solution pour afiner la compilation
> > d'un paquet en ajoutant des variables ou pas dans tazwok.conf du
> > type : WITHOUT_X=yes ou WITH_GTK=yes
> > 
> > ensuite dans le receipt 
> > if [ WITHOUT_X ]; then
> > ARG_CONF=$ARG_CONF" --without-x --enable-gui=no"
> > else
> > 	ARG_CONF=$ARG_CONF" --with-x"
> > 	if [ WITH_GTK ]; then
> > 		ARG_CONF=$ARG_CONF" --enable-gui=gtk"
> > 	fi
> > fi
> > 
> 
> ET l'inverse en fait, la grosse partie du code dans un .conf ou .rules
> et des recettes plus lègères ?
> 
> Dans un fichiers de conf ou rules
> ---------------------------------
> 
> STANDARD_BIN="./configure --prefix=/usr $MORE_ARGS_IF_NEEDED"
> 
> STANDARD_BIN_PKG="mkdir $fs/usr \
> cp -a $_pkg/usr/bin \
> strip $fs/usr/bin/*"
> 
> STANDARD_LIB="..."
> 
> ETC="..."
> 
> ----
> Je pense à ça parcequ'il y beaucoup de paquets qui effectivement n'ont
> pas besoin de règles particulières est pourrait appeler des commandes
> de complilation prédéfinies. C'est une voie non ?
> 
Oui et non... Que les répertoires genre man, bin, info & co soient donné par un .conf c'est niquel, c'est même j'avoue ce que j'ai fait vu que tous les paquets sont avec ce genre de choses en communs
Par contre que les régles soient ailleurs ...Dans FreeBSD tu as un Makefile qui correspond au receipt de slitaz, l'avantage étant que le mainteneur met les régles qu'il souhaite pour la compilation du paquetage. Ainsi lors de la comp, la recette va au plus direct.
Il y a clairement à mon avis un fichier dans /etc qui doit stocker toutes les informations génériques ainsi que les choix de bases ou ceux de l'utilisateur afin de régler le système, ensuite la recette est là pour prendre les informations dont elle (et le logiciel) a besoin pour la construction et l'empaquetage. 
> 
> > Cette solution a l'avantage de pouvoir mettre un ensemble de
> > variables par défaut pour produire l'ISO qui serait l'exacte
> > reproduction de la version officielle mais aussi n'empêche pas que
> > des paquets sans ce type de gestion puissent être compilés. J'ai
> > testé cette solution avec vim qui compile niquel a+ Gwen
> 
> Moi je serais assé pour bosser dans ce sens là.
> 
Je me demandais s'il ne faudrait pas pouvoir spécifier une chaine de caractére par défaut ( genre cook) dans le nom du tazpkg pour le différencier de la version officiel? Voir donner une option à tazwok pour que l'utilisateur puisse spécifier sa propre chaine.
Ainsi il pourrait se faire un ISO avec les paquets officiels, un avec des paquets épuré de X et un autre avec X et des options autres... C'est une idée en l'air et je pense qu'il faudrait approfondir un peu pour voir si c'est réaliste.
> A+
> - Pankso
> 
A+ Gwen
> 
> 
> 
> 
> 
> 
> ---
> SliTaz GNU/Linux Mailing list.
> Web site : http://www.slitaz.org/
> 


-------
http://www.trabucayre.com
Arsenic et vieilles ferailles

---
SliTaz GNU/Linux Mailing list.
Web site : http://www.slitaz.org/