[HELP WANTED] Script de création sources.list / preferences

Pause Café
#4

Ce n’est pas comme ça que je l’ai lu :

C’est un problème facile à corriger.

Il faut évidement l’accord de François, mais je pense que ça peut être un outil pour présenter un ou plusieurs dépôt annexe.

Je suis alors convaincu qu’il lui faut une interface graphique autre que ncurse. Ceux qui sont capables d’apprendre l’existence de ce future script, de le télécharger le rendre exécutable et l’exécuter, sont en mesure de trouver des sources.list d’exemples et de les recopier.

Après l’un empêche pas l’autre on peut avoir 3 types d’interaction :
[ul]
[li]CLI avec questions[/li]
[li]CLI sans question (configuration via des options de la ligne de commande)[/li]
[li]GUI avec question[/li][/ul]

Après ce n’est qu’un avis, hein.

#5

L’idée générale me semble bonne et je suis plutôt pour le côté script avec, quand ça sera au point, un tuto dans T&A et une page dans le wiki.
Si script ==> dans “programmation”.
Pour le reste, je demande à voir le résultat d’un premier jet.
Sinon, mais je te fais confiance ainsi qu’à Misterfreez et à Totor, le plus de choix possibles.

#6

La sélection des mirroirs est importante dans certains cas. Par exemple, j’ai souvent eu des soucis d’accès avec les debian-multimedia.org (désormais systématiquement j’utilise le mirroir de l’IGH/CNRS).

Ça serait bien aussi de proposer d’installer automatiquement les paquets “keyring” et/ou importer les clés GPG qui vont bien :slightly_smiling:

Dans la liste des dépôts proposés, je rajouterai bien dotdeb.org

#7

[quote=“MisterFreez”]Ce n’est pas comme ça que je l’ai lu :

C’est un problème facile à corriger.[/quote]
Effectivement, je n’avais pas relu le commentaire de lol avant de poster. Si les dépôts annexes sont indiqués de manière suffisamment claire ça peut passer.

[quote=“MisterFreez”]Je suis alors convaincu qu’il lui faut une interface graphique autre que ncurse. Ceux qui sont capables d’apprendre l’existence de ce future script, de le télécharger le rendre exécutable et l’exécuter, sont en mesure de trouver des sources.list d’exemples et de les recopier.

Après l’un empêche pas l’autre on peut avoir 3 types d’interaction :
[ul]
[li]CLI avec questions[/li]
[li]CLI sans question (configuration via des options de la ligne de commande)[/li]
[li]GUI avec question[/li][/ul][/quote]
Je vois bien où tu veux en venir, y’a juste un truc qui m’inquiète : les dépendances, sachant qu’à priori la plupart des gens auront un sources.list très basique, voire limité au CD/DVD. Cela dit rien n’empêche de faire un wrapper capable de gérer console / ncurses (dialog) / zenity / kdialog… de manière transparente, en fonction de ce qui est dispo sur le système.
Aussi, il serait peut-être judicieux de faire un .deb pour faciliter l’installation, qui se limiterait alors à wget + dpkg -i

Ça me plaît bien ça. :mrgreen:

Rajouté dans la liste (premier message du fil).

#8

dotdeb.org je ne connais pas mais leu slogan c’est :

C’est bien un dépôt qui backport des versions de serveurs pour pouvoir faire un web avec Debian ?

Je me pose la question de l’utilité d’un tel script pour les administrateurs systèmes. De la même manière pour ce genre de chose pas question d’avoir quoi que ce soit de graphique.

J’ai peur que le projet explose en vol a vouloir suivre tout les cas d’utilisation.

L’exemple de l’astuce possède un objectif claire il me semble, quand un nouveau viens et ne sais pas ce qu’il doit mettre dans son fichier sources.list, ils le redirige vers cette interface web 3 cliques plus tard il a son fichier sources.list. Même si l’outil n’est pas parfait comme l’a dis lol, il a un objectif assez clair je trouve.

Je ne dis pas ça pour détruire l’idée bien au contraire, je pense simplement qu’il faudrait hiérarchiser les cas d’utilisation et commencer par en faire peu sans réfléchir à ceux qui suivent. Comme le disait Raymond Release early, release often. Pour moi ça passe par chercher à en faire le minimum au départ.

Est-ce qu’il y a régulièrement des gens qui posent des questions sur le sources.list dans la section Support ?

#9

D’accord avec Michel pour ce qui est d’un départ simple et réduit.
Il sera temps par la suite d’ajouter des possibilités.

#10

C’était bien mon objectif de départ (en passant par un script plutôt qu’une page web, mais bon…). :wink:

Le gros problème de cette page web c’est que pour une testing ou unstable, c’est tout bonnement mal configuré (pas de stable/testing pour une sid, etc).

Bof, tu sais bien comment c’est, ils ne posent pas forcément de questions mais ils sont quand même redirigés assez régulièrement vers le T&A “sources liste au carré”. :mrgreen:
Mais, à mon avis, l’inconvénient de ce T&A pour les débutants complets c’est que ça demande un minimum de compréhension de l’environnement Debian alors que bien souvent ils pataugent totalement (même s’il a l’avantage d’expliquer les choses). D’où le fait que j’ai trouvé le principe de cette page web très intéressant malgré sa mauvaise implémentation.

Bref, il semblerait que ça soit plus raisonnable de revenir sur l’idée de départ avec quelques dépôts “classiques”, quitte à faire évoluer le biniou plus tard.

#11

Le gros problème de cette page web c’est que pour une testing ou unstable, c’est tout bonnement mal configuré (pas de stable/testing pour une sid, etc).[/quote]
Ce n’est pas si grave du point de vu du logiciel.

Bof, tu sais bien comment c’est, ils ne posent pas forcément de questions mais ils sont quand même redirigés assez régulièrement vers le T&A “sources liste au carré”. :mrgreen:
Mais, à mon avis, l’inconvénient de ce T&A pour les débutants complets c’est que ça demande un minimum de compréhension de l’environnement Debian alors que bien souvent ils pataugent totalement (même s’il a l’avantage d’expliquer les choses). D’où le fait que j’ai trouvé le principe de cette page web très intéressant malgré sa mauvaise implémentation.[/quote]
Je suis un chieur mais il me semble que ce qui correspond le mieux à ce cas c’est un formulaire web, qui une fois rempli génère un package qui remplace le sources.list et le fichier de préférences.

#12

Ouhla… générer dynamiquement un .deb (tar.gz) avec toute l’arborescence et les bonnes permissions (donc fakeroot)… via une page web ? :119
Ça sera sans moi là, les technos web je ne m’en approche que contraint et forcé, et encore faut-il que la menace soit très menaçante… :smiley:

#13

Ouhla… générer dynamiquement un .deb (tar.gz) avec toute l’arborescence et les bonnes permissions (donc fakeroot)… via une page web ? :119
Ça sera sans moi là, les technos web je ne m’en approche que contraint et forcé, et encore faut-il que la menace soit très menaçante… :smiley:[/quote]
Pff tu le fait en CLI, puis c’est pas si compliqué de faire une interface web qui utilise ce script.

#14

Eh, j’ai une super bonne idée !
Je fais la partie CLI qui pose des questions, puis je l’adapte pour accepter des paramètres en ligne de commande, je fais même le script pour construire le paquet si tu veux, et tu pourras faire l’interface web… :eusa-whistle:

:016 :smiley:

#15

Eh, j’ai une super bonne idée !
Je fais la partie CLI qui pose des questions, puis je l’adapte pour accepter des paramètres en ligne de commande, je fais même le script pour construire le paquet si tu veux, et tu pourras faire l’interface web… :eusa-whistle:

:016 :smiley:[/quote]
Je garanti rien, ça dépendra de mon temps mais pourquoi pas. De toute manière ça va dans le sens de ce que tu voulais faire.

#16

Salut,
J’ai voté “oui” hier, c’est une bonne idée.

Mais… pourquoi s’emmerder à faire un deb ? :017
Pourquoi ne pas simplement générer (comme ça se fait pour tous les générateurs en ligne) un résultat à copier/coller ?

#17

Pour ne pas avoir d’erreur de copier/coller et pour installer les clefs des dépôts.
Ma remarque faisait suite à des problèmes avec l’existant qui consiste à faire du copier coller.

#18

[quote=“MisterFreez”]Pour ne pas avoir d’erreur de copier/coller et pour installer les clefs des dépôts.
Ma remarque faisait suite à des problèmes avec l’existant qui consiste à faire du copier coller.[/quote]

Bien,
Je trouve ça extrême, mais bon!
Ça imposera pour celui qui hébergera plus de ressources à mettre à disposition; Si le générateur fonctionne bien (ce que je lui souhaite), encore plus… Ce n’est rien de compiler un petit deb, mais plusieurs…

C’est mon idée sur la question, peut-être que je me trompe.

#19

Avec une mise en cache des 20 derniers paquets ça doit pas être si monstrueux.

#20

Après je peux dire des conneries et vous avez droits de m’envoyer bouler, hien. Je ne fais que des petites propositions. On peut faire un p’tit script à lancer par l’utilisateur si on considère que ce n’est pas trop compliqué pour lui.

#21

[quote=“MisterFreez”]
Je suis un chieur mais il me semble que ce qui correspond le mieux à ce cas c’est un formulaire web[…][/quote]
+1
mais la question est de savoir si ce +1 est pour le coté “chieur” ou pour l’idée du formulaire :laughing:

Plus sérieusement, je te suis pour le formulaire, car outre l’aspect technique, j’y vois les aspects suivants :

  • cela peut devenir un “service” du site debian-fr.org et donc un atout
  • la correction de “bugs” est plus “largement” diffusée (tout comme la diffusion de bugs d’ailleurs)
  • la maintenabilité en est simplifiée si il s’agit d’un service du site. En effet il n’y aurait qu’une seule version centralisée et non autant de version téléchargées et potentiellement modifiées par l’utilisateur.
#22

J’ai uploadé (dans le premier message) une gribouille qui ne fait que poser des questions et calculer les dépôts nécessaires sans toucher à rien sur le système. Plusieurs remarques :

  • c’est loin d’être complet (ça ne génère pas réellement de sources.list / preferences, juste une liste de dépôts + priorités, et aucune gestion des miroirs)
  • j’ai mis des « (recommandé) » dans l’optique de guider un débutant complet, pas forcément d’être au top du top. Par exemple, je recommande d’inclure les backports sur une stable, comme ça c’est dispo dès le départ (et ça mange pas de pain vu qu’il faut une manip spéciale pour installer un backport). Forcément c’est discutable, alors discutez. :stuck_out_tongue:
  • de même, j’ai fait les pinnings en fonction de ce qui me semble le plus logique et des contraintes des divers dépôts, à discuter encore une fois
  • pas utile de faire des remarques sur l’implémentation proprement dite pour le moment, vu que ça va sûrement changer beaucoup (je sais, c’est crade et rempli de bashismes…)

Y’a pas non plus 36 millions de combinaisons possibles, et sachant que les .deb ne seront pas bien gros c’est pas la fin du monde de tout cacher à la volée en base de données (cache complètement effacé lors d’une mise à jour du script of course). Ça va bouffer quoi ? 1 Mo à tout casser…
Cela dit je vous laisse vous battre avec vos histoires de .deb et d’interface web, moi je m’occupe de faire un script fonctionnel ça sera déjà pas mal… :mrgreen:

[quote=“Totor”]- la correction de “bugs” est plus “largement” diffusée (tout comme la diffusion de bugs d’ailleurs)

  • la maintenabilité en est simplifiée si il s’agit d’un service du site. En effet il n’y aurait qu’une seule version centralisée et non autant de version téléchargées et potentiellement modifiées par l’utilisateur.[/quote]
    Ça c’est clairement un ÉNORME plus, d’autant que le script sera forcément amené à évoluer régulièrement (changements dans les dépôts mozilla, changement de stable, …).
#23

L’exemple donné en astuce fait 2^27 combinaison, le nombre maximal de fichier pour un système de fichier ext4 c’est 4*10^9. Il faudrait donc utiliser un cache en btrfs (il permet 2^64 fichiers).

Bien sûr si on arrive à avoir 2^27 requête avant disons décembre 2013 (date éventuelle de sortie de la prochaine version) 2^27/14/30 (disons qu’un moi fait 30 jours) ça voudrait dire que le script génère 320 000 demandes par jours (différentes je ne compte que des combinaisons de demandes différentes). Ça fait 220 connexion à la minute, je pense que le site web tombera avant le système de fichier.

Donc oui on peut tout mettre en cache si ça peut faire plaisir.

Pour ce qui est de l’interface web j’avais penser à un couple nginx/tornado. Nginx distribue tout ce qui est statique (le formulaire et tout ce qui va avec et le paquet) et tornado pour lancer le script et renvoyer une page avec le lien pour télécharger le paquet (et un petit descriptif sur l’installation de celui-ci.

Histoire de se simplifier la tache on peut, peut être, oublier le paquet pour le moment histoire de voir comment le tout peut se faire. Je bosserais là dessus ce week end, je pense.