> >oui, tous les paquet offciels sont sur le CD-ROM, et il n'y a qu'un CD-ROM. > >Nasgaïa doit être une base pour une distribution adatpée aux envies de > >chacun. Cela ne sertà rien de chercher à fournir de manière stricte > >tous les paquets inimaginables (même pas Gnome ou Kde, puisqu'on a > >choisit xfce+goodies comme desktop plutot qu'un environnement tout en > >un) > > OK. Admettons que les paquets officiels correspondent uniquement aux paquets > mis sur le CD-ROM.
je sais pas si c'est vraiment ce que voulait dire riri, si tous les paquets officiels doivent tenir sur un cdrom on en aura pas beaucoups. je pense que les paquets dispos sur le cdrom ne seront pas les seuls à être officiels > Une première sortie officielle de Nasgaïa est publiée avec une liste > déterminée de paquets officiels, donc, de paquets présents sur le CD-ROM. > Pour les sorties suivantes, on décide de remplacer un logiciel par un autre > pour une raison ou pour une autre (par exemple, firefox par epiphany). > > Que va-t-on faire ? On va supprimer le répertoire SVN firefox et créer un > nouveau répertoire epiphany ?! Cela signifie donc que nous allons perdre > tout l'historique SVN du paquet firefox. pourquois, le faire de cette façon ? , imagine notre svn différement. Les paquets officiels n'étant pas seulement ceux de l'iso. Imagine maintenant que tu mettes simplement les paquets étant sur l'iso dans <groups>iso,base</groups> (exemple pour gcc). De même pour firefox <groups>iso,http</groups> et epiphine <groups>http</groups>. cela permait simplement lors de l'installation de faire Ncooker install -g iso (-g installation par groupes de paquets). Si un paquet n'est plus sur l'iso il suffit de l'enlever du groupe "iso". c'es très simple à maintenir de cette façon. > Personnellement, je vois les choses assez loin. L'ensemble des logiciels > existants dans le monde est infini. Par conséquent, l'ensemble des paquets > possibles est lui aussi infini. De ce fait, l'espace de stockage doit être > infini. Or, tout espace de stockage est fini. On ne peut donc pas stocker > tous les paquets de contribution sur un espace (preuve par contradiction > :p). > > C'est pourquoi je vois plutôt un espace de stockage réparti, autrement dit, > plusieurs espaces de stockage (des sites perso) répertoriés. avec gna il me semble que l'on dispose de 100Mega d'espace de stockage. Pour des fichiers textes cela suffit largement ! > > > Le premier cas est celui dans lequel notre cher nasgaïen veut installer > >un > > > logiciel particulier mais que le nbuild/nba correspondant à ce logiciel > >est > > > introuvable. Ni une, ni deux, ce nasgaïen courageux va créer le nbuild > > > souhaité. Il réussit à installer son logiciel et son paquet lui semble > > > correct. Il va naturellement vouloir partager son paquet avec l'ensemble > >de > > > la communauté Nasgaïa. Quel moyen aura-t-il pour le faire ? Comment s'y > > > prendra-t-il ? Où sera stocké son paquet ? Son paquet sera-t-il > >considéré > > > comme un paquet de contribution ? > > > >un centre (ou dépot) de Nbuilds (cf au-dessus) > >On peut imaginer faire un projet nasgaia-nbuilds sur tuxfamily qui > >sert de projet de partage des nbuilds. Pour moi la façon la plus simples est une ML packages-submit ou un svn séparé de gna. > > Argggg. Tu n'as répondu qu'à une seule des quatre questions. :) > > Je me réponds à moi-même alors. :) > > -> Quel moyen aura-t-il pour le faire ? Comment s'y prendra-t-il ? > > Je vois deux possibilités : > - HTTP : une interface web permet de soumettre un paquet ; > - courriel : une adresse électronique réceptionne les soumissions de paquets phpftp par exemple est un moyen très simple de la faire, ces paquets pourraient être stockés dans un dossier incomming (une archive tar.bz2 des fichiers info et install) > > -> Où sera stocké son paquet ? cf au dessus > Il sera stocké dans un répertoire "distant" (HTTP, FTP) dans lequel tout le > monde pourra piocher (en particulier et surtout Ncooker). > > -> Son paquet sera-t-il considéré comme un paquet de contribution ? > > Oui. Dans un premier temps, en tout cas. oui, mais marqué comme unstable je pense, Des utilisateurs (trusted users) parmis la communauté (utilisateurs de confiance nommé par système de vote par exemple par les dev officiels de nasgaia ? ) pourront marquer le paquet comme "safe". Ainsi les contributions seront classé de bonne qualité ou pas. > Si l'équipe Nasgaïa veut en faire un paquet officiel, elle teste et vérifie > le paquet afin de la valider. Si le paquet n'est pas valide, elle demande au > mainteneur d'y apporter les modifications nécessaires ou elle apporte > elle-même les modifications. Une fois validé, elle déplacera le paquet vers > l'espace de stockage des paquets officiels. je pense pas , qu'il faut obliger qq un qui propose un paquet à le modifier, si un membre officiel de nasgaia veut adopter un paquet en officiel à lui de le modif et d'en assumer la maintenance. > > > > Le deuxième cas est celui dans lequel notre cher nasgaïen veut installer > >la > > > toute dernière version d'un logiciel mais que les seuls nbuild/nba qu'il > > > trouve correspondent à des versions antérieures de ce logiciel. Ni une, > >ni > > > deux, ce nasgaïen courageux va récupérer le nbuild correspondant à une > > > version quelconque (la plus grande si il n'est pas trop bête) et > >l'adapter > > > pour la toute dernière version du logiciel. Il réussit à installer son > > > logiciel et son paquet lui semble correct. Il va naturellement vouloir > > > partager son paquet avec l'ensemble de la communauté Nasgaïa. Que > >fera-t-il > > > pour cela ? Si le paquet en question fait partie de la liste des paquets > > > officiels, comment le fruit de son courage sera-t-il soumis au dépôt SVN > >? un système de flag "out of date" peut être signalant que le paquet à besoin d'une MAJ peut être ? si il veut quand même sans occuper il peut poster le paquet MAJ sur la ML ou dans le repo incoming de nasgaia. Pour ce qui est de son fruit de son courage... je ne pense pas que changer le numéro de version das le Nbuild (ce qui est fait la plus part du temps) nécessite de site le contributeur dans le paquet ni dans le changelog. Si un plus gros travail est fait sur le paquet , son nom pourrait être cité dans le changelog come contributeur ? > > > Le paquet passera-t-il par une phase "paquet de contribution" ? > > > >si c'est un paquet officiels, soit il s'inscrit en tant que membre > >pour commiter sur le dépot subversion, soit il envoit son nbuild sur > >la ML pour informer les membres qu'il ont à disposition une nouvelle > >version. Tu as raison d'en parler comme ça, ça montre ce qu'il sera > >nécessaire de clarifier sur le site web > > Le truc, c'est que mon cher nasgaïen ne sait pas que c'est un paquet > officiel ou un paquet de contribution. D'ailleurs, il s'en moque un peu. > Lui, il veut juste partager son paquet avec le reste de la communauté. il doit le mettre en contribution sur le repo contribution. Si il es tdéj en officiel il sera surement suprimé plus tard, sauf si il apporte qq chose de plus que le paquet officiel ? > Idem que ci-dessus (interface web ou adresse électronique). > > > -> Si le paquet en question fait partie de la liste des paquets officiels, > comment le fruit de son courage sera-t-il soumis au dépôt SVN ? cf au dessus > Sur ce sujet, ce que tu proposes pose quelques problèmes. > > Quand mon cher nasgaïen a construit son paquet pour la nouvelle version du > logiciel, il est parti d'un nbuild tout fait. Il ne s'est pas préalablement > enregistré sur Gna! afin de récuperer une image du dépôt SVN. Par > conséquent, le fait de remonter les modifications apportées sur le paquet > dans le dépôt SVN est délicat et source d'erreurs. > > Ca, c'est le deuxième argument contre l'utilisation d'un dépôt SVN. > c'est pour cela que j'aimerais séparer le repo svn officiel et le repo svn contrib. > -> Le paquet passera-t-il par une phase "paquet de contribution" ? > > Oui. Typiquement, on peut imaginer que la toute dernière version du noyau > Linux soit disponible sous la forme d'un paquet de contribution alors que le > paquet du noyau Linux dont la version est considérée comme fiable fera > partie de l'ensemble des paquets officiels. > > > A+ > > -- > Julien L > > _________________________________________________________________ > Apprenez à lutter contre le spam ! > http://go.msn.fr/10-channel/80-security/spam/default.asp > > > _______________________________________________ > Nasgaia-dev mailing list > [email protected] > https://mail.gna.org/listinfo/nasgaia-dev
