Re: Quelques questions

[gwenhael <gwenjo@xxxxxxx>]

Re

> > Salut 
> 
> Salut,
> 
> > > > 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.
> 
> Vu comme ça c'est idéal...
A mon sens je pense que c'est la meilleure solution pour éviter certains désagrément ( c'est du vécu avec FreeBSD et le problème de se rappeler les bonnes options à chaques mises à jour)
> 
> > > 
> > > 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?
> 
> Je vois pas. Quand on créer un ISO avec Tazlito, il extract tous les
> paquets un à un dans le rootfs (tazpkg extract aussi...). On peut soit
> vérifier si les deps à chaque install et stopper si il en manque ou
> tout extraire et générer une liste des paquets qu'il faudrait.
> 
L'idée d'une sorte d'arbre serait peut-être la solution la plus efficace afin de ne pas chercher 15 fois l'existence d'une même dépendance.
> Et quand on crée un tazpkg, on peut déjà spécifier les deps via DEPENDS.
> 
Oups j'avais pas fait gaffe à ça. Dans ce cas le DEPENDS doit être mis à jour dynamiquement lors de la préparation de compil.
> 
> > > 
> > > 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?
> >  
> 
> Yes. Tu, je ?
> 
En fait il suffirait juste de rajouter une variable dans tazwok.conf par ex et puis c'est au mainteneur d'en tenir ou pas compte, genre dans tous les cas copier l'anglais et puis boucler.
Aussi on pourrait rajouter un NO_MAN pour carrément ne pas copier un certains nombres de choses du genre man, exemples, doc
Tenir compte d'un WITHOUT_X pour ne pas copier les images ( abérant si tu bosse en console...)
> > > 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 ? 
> 
> C'est sûr. Pour Tazpkg/Tazwok, les pkgtool BSD m'on bien aidé, c'est
> propre, je savais que Slack et Gentoo fesait un truc dans le genre, mais
> les premiers ça doit être les BSD je crois. Et... j'aurais envie de dire
> que c'était pas une désion facile, j'étais seul à l'époque et je
> crois que le gestionnaire de paquet d'une distro est emblématique.
> Ils font parties de mon trip... "from scratch". Et... je voulais pas
> faire une xième Debian, Slack, Gentoo based system...
> 
Parfaitement ok avec toi... A quoi bon refaire entièrement un système si c'est pour au final réimplémenter exactement debian ou gentoo... Autant forker dans ce cas... 
> 
> > > 
> > > ----
> > > 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. 
> > > 
> 
> Yes, j'avais pensé au Makefile au lieu des recettes pur SHell script
> et OUI il faut clairement un fichier dans /etc. Je continue sur le
> suivant (vu ton complèment) ou CF la suite...
> 
> > > 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.
> 
> 
> Exemple (TAZ_REV pour slitaz revision) :
> 
> VERSION=""
> TAZ_REV="$VERSION-cook-1"
> 
> C'est pas une idée en l'air, c'est ce qu'on doit faire. Ca pose déjà
> problème maintenant, genre j'ai corriger grub-0.97, sur un système
> installé, il va pas se mettre à jour vu que la version est pareil, il
> faudrait que je mette grub-0.97-cook-0 pour après suivre avec
> grub-0.97-cook-1 si il le faut.
> 
Faudras dans ce cas mettre quelques part une variable qui permette à tazlito de gérer les dépendances, je m'explique :
En l'état comment il peut faire pour choisir entre une version officielle et une version cook et que faire si il n'y a pas de version cook.
Donc :
PREFERRED_VERSION = official, cook, ask.
la première allant directement sur l'officielle, la seconde essayant de trouver une version cook et si elle n'existe pas prendre l'officielle et la troisième demanderait à l'utilisateur quoi faire, (continuer avec l'officiel ou arrêter pour l'utilisateur fasse sa cuisine :) ).
> 
> Roadmap for Tazpkg 1.4
> ----------------------
> Avec toutes ces bonnes idées, il faut qu'on se fixe des priorités.
> C'est sûr que la gestion des paquets et encore jeune et qu'on peut
> toujours améliorer. Je sais pas quand j'aurais le temps de préparer
> un dépôt Mercurial pour Tazpkg & co,. Je propose de lancer un nouveau
> sujet sur la liste  avec comme sujet : Roadmap for Tazpkg 1.4 ?
> 
> 
Très bonne idée parce que vu la taille que prend le poste ça deviens plus très évident de s'y retrouver
> Bonne après-midi,
> - Pankso
> 
Bonne soirée
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/