> Il m'est venu une idée à propos des nbuilds ... > Je pense qu'il peut être approprié pour l'utilisateur qui va construire > le nbuild de vouloir l'adapter a ses besoins. > > ... > > Partant de ce constat, je pense qu'il faudrait un système de flags (à > la Gentoo). Je vois d'ici une objection : ce serait compliqué de > maintenir ces flags pour toute une distribution. Je suis d'accord. > je propose donc que ces flags ne soient pas communs à toutes les > applications mais spécifiques aux nbuilds. > > ... > > Il faut bien sûr que le paquet docuimente les flags qu'il propose. Cela > devrait être disponible avec une commande Ncooker > > > Bon, vous remarquerez que j'ai mis le nom du paquet comme étant > optionnel. La raison est simple : Si un paquet dispose d'un flag kde > (par exemple) et qu'il dépend d'un paquet disposant du flag kde ... > etc. Au lieu de définir de manière fastidieuse : > soft1:+kde soft2:+kde soft3:+kde ... > il suffirait de: > +kde > > Alors, bien sûr les flags sont suceptibles d'être différents pour > chaque paquet. Cependant, on peut raisonablement penser qu'un flag > 'kde' aura la même signification d'un paquet à l'autre, non ? > Et si ce n'est pas le cas, il faudra faire attention avant.
C'est là que ton idée flanche, car on ne pourra pas assurer les bons flags communs à tous les paquets s'ils sont déterminés pour chacun indiféremment. Le principe de flags est bons, afin de donner des options, par contre, l'utiliser pour résoudre les dépendances, je ne suis pas particulièrement pour. Le principe des flags est par contre intéressant, si on ne tombe pas dans la misère de configuration de Gentoo (désolé pour les fans), en effet, bien se configurer les flags est devenu une abomination sur cette distro. > Si un jour on arrive avec un Ncooker avec une gestion des dépendances, > il pourrait ête intéressant de définir de tels flags non seulement pour > le paquet qu'on demande de compiler, mais aussi pour tous les paquets > qui en dépendent. Il faut alors différencier les flags destinés a un > paquet ou a un autre paquet. > Dans un contexte avec de multiples dépendances, on pourrait imaginer > qu'un flag se décrirait ainsi : (crochet = optionnel ; | = ou) > [nom_du_paquet:][+|-]flag[=valeur] > Ces flags pourraient se donner soit sur la ligne de commande, soit dans > une variable d'un fichier de conf ... a voir. Je suis opposé aux dépendances de paquets, car il n'est pas possible de les rendre complètement fonctionnels. Ncooker2 (de nga1) utilisait les dépendances directes de fichiers (en particulier les libs), et ça marchait très bien. En plus des dépendances calculées automatiquement par l'outil, il permettait les dépendances 'humaines', à savoir que le créateur de Nbuild pouvait rajouter une dépendance en la donnant dans un fichier du Nbuild (par exemple, a besoin du service MTA pour envoyer des mails, en se foutant du MTA installé). Cela n'était malheureusement jamais utilisé. J'estime que cela reste la meilleure façon de gérer les dépendances, en s'appuyant sur ce dont le programme a réellement besoin. Bien-sûr, certaines dépendances ne peuvent pas être calculées automatiquement, et c'est un travail supplémentaire pour le créateur du nbuild, mais je préfère placer le travail du côté du nbuilder que de celui de l'utilisateur. PS: je pars aussi du principe que les dépendances ne sont pas obligatoires pour l'utilisateur, il doit pouvoir les ignorer s'il le veut. C'est une flexibilité importante dans certains cas. -- Richard 'riri' GILL jabber: [EMAIL PROTECTED] -- Al trom, siam d'droba : Ihct ! Ihct ! -- _______________________________________________ Nasgaia-dev mailing list [email protected] https://mail.gna.org/listinfo/nasgaia-dev
