Discussion:Apt-troulite

Fonctionnement du script

Xavier_OM (Gestion du sources.list par défaut): Pour le moment le script insère 'en dur' un sources.list correspondant à Etch/free. Ce n'est que temporaire. A terme le user devrait pouvoir fournir son sources.list en plus des dépots souhaités (choix parmis la liste des dépots officiels + ajout des dépots non officiels par text area). Les possibilités que je vois sont :

• décortiquer son sources.list pour :
  • virer les commentaires
  • insérer ligne par ligne les dépots comme arguments d'apt-troulite
• rajouter une option du genre --sources= et on part du principe que les dépots non officiels et le sources.list uploadé par le user ont été fusionnés dans un fichier qu'on passe donc en argument.
  • avantages : plus besoin de parser un nombre quelconque de dépôts
  • inconvénients : faut analyser la ligne de commande pour détecter le --sources=brol, mais bon j'ai en stock des scripts qui font ca tout seul
• une variante des 2 :
  • on met un --sources pour passer en argument le sources.list du user
  • on laisse la possibilité d'ajouter des repositories "à la volée" en acceptant un nombre quelconque d'arguments dans le script

J'avoue que je ne mesure pas trop les avantages et inconvénients de ces différentes solutions... des avis ? Ptet que la dernière est plus souple...

edit : A priori je vais partir sur la deuxième, tout dans le sources.list, pour simplifier l'appel d'apt-troulite ce qui permettra de rajouter à terme la gestion de n paquets au lieu d'un seul.

Ze Reaper (Suppression des déchêts): Pour supprimer les restes en cas d'interruption du script PHP, il faudrait se renseigner sur ses possibilités justement, voir s'il n'est pas possible de forcer l'exécution d'une fonction de nettoyage. Si ce n'est pas possible, il reste la possibilité de faire un cron qui supprimerait les fichiers qui ont plus d'un certain âge (disons 1h ou 2), sachant qu'a priori (à vérifier tout de même) si un fichier est en cours d'utilisation par Apache (lorsque l'utilisateur télécharge l'archive), alors supprimer le-dit fichier ne casse pas l'upload (Apache doit utiliser un cache ?).

Xavier_OM Ou encore plus simple, au moment où l'on génère l'archive on utilise at pour qu'une heure après le fichier soit effacé.

Xavier_OM (Ne pas envoyer de tar.gz pour limiter le traffic du MIT):

• apt-troulite, par son troulitisme naturel, est très supérieur à apt-zip... personne ne met cela en doute, la preuve il y a troulite dans son nom et même l'url de la web interface contient 2 fois le mot troulite c'est pour dire ! Bon sans rire, apt-troulite résoud les dépendances et l'ajout de dépôts pour vous, pas besoin de faire plusieurs aller-retour comme avec apt-zip
• Mais en l'état on ne pourra jamais diffuser cet url, le traffic réseau exploserait vu qu'apt-troulite passe son temps à télécharger (au MIT) puis à uploader chez vous des tas de bytes. Je reste persuadé que ce genre de "résolveur de dépendances distant" pourrait être utile pourtant :(
• apt-zip, lui, fait appel à une fonction d'apt-get pour ne pas télécharger mais afficher les url des paquets à télécharger.

On pourrait peut-être utiliser apt-troulite comme aujourd'hui (demande de paquet, upload de status file, ajout de repositories, résolution de dépendances) mais au lieu de télécharger/générer/renvoyer un tar.gz on générerait et renverrait une liste d'url "à la apt-zip".

Après tout, wget est disponible sur différentes plateformes et l'utilisateur moyen d'apt-troulite est un type voulant upgrader sa debian, donc assez intelligent pour lancer un wget --input-file=toto.txt

J'ai besoin de votre avis.

Ze ReaperLe probleme c'est que quelqu'un qui utilise apt-troulite depuis Windows (et ca peut arriver, un mec qui n'a pas le net choisit pas forcement la plate-forme qu'il va utiliser pour apt-troulite) va se faire chier pour downloader les trucs.

Ensuite effectivement, le MIT risque de gueuler si ca devient trop utilise, mais je pense que troulite sera a la rue avant, c'est pas un foudre de guerre ;). Enfin, dans un premier temps on peut le laisser la mais faudrait mettre un truc pour monitorer la bande-passante utilisee, pour pouvoir surveiller.

Dernier point, pense a bien escaper les contenus des champs du formulaire si tu re-affiches leur contenu, pour eviter les XSS

Xavier_OM (Création de tar imbriqués à la volée - Aide demandée à yéti):

Je crée un .tar avec des .deb dedans.

Je crée un .tar.gz avec ce .tar et 2 autres fichiers textes.

Ca marche.

Et là je me dis que le premier .tar, je le crée vraiment pour pas grand chose.

Vu qu'il va être intégré dans le .tar.gz, ne pourrait-on pas éviter de créer un fichier temporaire pour rien ?

Donc j'ai essayé de créer [un .tar.gz contenant un .tar contenant des .deb], en jouant avec stdout, les pipes et les pipes nommés.

Le problème, c'est qu'un flux qu'on balance sur stdout n'a pas de nom donc même si on peut créer le .tar temporaire et le balancer dans un pipe ou un pipe nommé, de l'autre côté du tuyau au moment de l'intégrer au tar.gz il n'a pas de nom.

doc de tar http://sunsite.ualberta.ca/Documentation/Gnu/tar-1.13/html_chapter/tar_6.html

Xavier_OM (Réponse de yéti):

Yo

Le pb c que tar serialise un bout du filesystem.

Ce flux peut certes etre envoye dans un pipe/fifo/fichier, mais tar lit le FS.

Et il ne lit pas le contenu des fifo (pipe nommes), mais stocke qu'il en existe un (c voulu pour pouvoir dupliquer un FS contenant un fifo).

Donc ouin ouin.

<joke> Eventuellement, tu peut faire un driver qui implemente un FS volatil, ou bien faire un filtre Unix genre cat++ qui ajoute un en-tete tar en plus du flux de donnees afin de simuler un vrai fichier? </joke>