Bonjour.
Je construis, pour le plaisir, une mini-distribution pour une console de jeux vidéo portable, la [[Dingoo_A320]].
http://fr.wikipedia.org/wiki/Dingoo_A320
J'ai une centaine de "paquets" de prêts, contenant les binaires pré-compilés. Par paquet, à l'heure actuelle, j'entends des archives tar.gz contenant les binaires et fichiers précompilé pour une architecture mips. Je suis parti "from scratch", en compilant tout un par un, et pour chaque machin compilé, je l'ai archivé. Tout fonctionne correctement.
MAIS.
À l'heure actuelle, pour installer tout ce bordel, j'ai juste un pitit programme python que j'ai créer qui s'occupe de désarchiver les "paquets" sur la console ( branché en usb et se comportant comme une clé USB ), qui gère les dépendances et qui s'utilise en ligne de commande. Il ne gère pas la désinstallation des paquets, parce que c'est bien compliqué pour mes petites connaissances en "algorithme".
Je l'ai créer un peu dans l'urgence, surtout pour mon propre usage et pour tester les paquets. Ça m'a pris que quelques heures et je ne compte pas le diffuser, vu que c'est un peu pourrave. Et je ne souhaite pas réinventer la roue.
Donc, je voudrais vous demander quel gestionnaire de paquets existant répondrait aux critères suivant :
* Permet la gestion en "externe". Je m'explique. La console n'est pas relié au réseau, elle se comporte comme une simple clé USB. Du coup, je ne peux pas mettre le gestionnaire de paquets directement sur la console, il doit être installer sur le pc et simplement copier les fichiers dans les répertoires de la clé USB ( ou créer un fichier, etc... en gros, tout ce qui est possible sur une simple clé USB ). J'espère être clair, c'est relativement difficile à expliquer.
* Gère les dépendances, l'installation, et SURTOUT la désinstallation des paquets, en supprimant les dépendances obsolètes sans virer les trucs essentiels. Se comporter comme aptitude par exemple.
* Être le plus simple possible, typiquement, être utilisable en "stand-alone". Voir le point suivant pour comprendre.
* Être portable facilement sur un autre OS. Parce que la majorité des utilisateurs de cette console sont des gros manches, sous Windows, il n'est pas possible d'être ancré dans l'architecture Linux, en utilisant massivement bash par exemple.
Si il faut reconstruire les paquets, cela ne me dérange pas du tout. Je n'en suis plus à une dizaine d'heure prêt.
Dans l'idéal, avoir un truc en python serait vraiment cool. Parce que c'est LE truc que je maîtrise à peu près. Mais bon, je rêve un peu. Dans le pire, je plongerais dans les arcanes du C ou C++ ( de toute manière, j'y ai été contraint durant toute la phase de compilation, parce que jamais rien ne marche de manière simple, surtout avec un processeur MIPS à la con).
Une interface graphique, je m'en fous totalement. Si les appels au gestionnaire de paquets est simple, je peux bricoler un truc autour en graphique.
Voili, voiloù. En espérant avoir été compréhensible. Si ça se trouve, y a un truc évident, mais je n'y connais rien en gestion de paquets. Et c'est TRÈS frustrant d'avoir construit des tas de paquets qui fonctionne, mais qui sont inutilisable pour une autre personne que moi. À moi que l'on adore gérer chaque fichier un par un, décompresser des archives par centaine, etc....
Bisous à tous.
Forum Linux.embarqué Recherche gestionnaire de paquets "externe" pour embarqué
4
sept.
2010
# Utiliser l'existant
Posté par JJD . Évalué à 2.
Tu pourrais essayer de jeter un coup d'oeil aux outils existants sur les distributions traditionnelles. Des outils comme rpm ou dpkg permettent d'installer des paquets et de gérer la base de configuration dans une arborescence indépendante de la machine sur laquelle ils sont exécutés.
Pour dpkg, regarde du côté des options --admindir, --instdir ou --root.
Pour rpm, il existe au moins les options --root et --dbpath.
Il doit certainement exister des possibilités équivalentes pour les gestionnaires de paquets des autres distributions (c'est ce qui doit être utilisé lors de l'installation avec le système de fichier cible monté sur /target par exemple).
Évidemment, dans ton cas, il y a certainement certaines limitations liées à l'hétérogénéité de tes archi d'exécution et cible par exemple. Les scripts de {pre,post}install vont être exécutés dans un chroot, c'est à dire avec accès à des binaires MIPS, alors que le processeur utilisé sera celui de ton PC : ça ne fonctionnera donc pas (à moins que ton PC soit en fait une station SGI). Mais si jusqu'à présent tu installais simplement en décompressant tes archives, cela ne devrait pas être trop gênant.
A+
JJD
[^] # Re: Utiliser l'existant
Posté par Sekigo . Évalué à 2.
Merci pour ce début de piste.
Pour le reste, concernant l'hétérogénéité, c'est tout le contraire. C'est une plateforme ULTRA-homogène, ça ne se destine qu'à la Dingoo A320, où les variations de hardware se font uniquement sur l'écran LCD ( qui est géré par le kernel de toute manière ). Les scripts pré et post install sont réduit au minimum ( en fait, pour le moment, il n'y en a aucun ), les seuls trucs "un poil" compliqué à faire pour le moment, c'est concernant le système de fichier, l'installation du programme de démarrage ( uboot en l'occurence ) et le peuplement de /dev, mais là, ce n'est pas de mon ressort, je m'occupe uniquement du système proprement dit.
Pour les plateformes d'exécution, effectivement, c'est déjà plus problématique. C'est bien pour cela que je demandais un truc qui fonctionne tout seul et qui puisse être utilisable sur n'importe quel système ( enfin, au moins les plus utilisés quoi ).
[^] # Re: Utiliser l'existant
Posté par Mali (site web personnel) . Évalué à 3.
C'est juste une piste, je n'ai plus touché de slackware depuis quelques années et je ne connais pas slapkg, mais çà peut-être une bonne base de départ.
PS : Joli projet, tu t'es fait plaisir ?
[^] # Re: Utiliser l'existant
Posté par kinou . Évalué à 3.
avec --dbpath pour changer la base de donnée utilisé
et --root pour définir la racine de ton système
[^] # Re: Utiliser l'existant
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
C'est pas limité à NetBSD comme beaucoup le croient, et des distributions linux l'utilisent.
# Opkg
Posté par benoar . Évalué à 3.
Je pense qu'il correspond à tous tes critères (mais il est en C, embarqué oblige).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.