Difference between revisions of "Fr:Integration ipkg"

From ArmadeusWiki
Jump to: navigation, search
(Création de la page)
 
m (C'est parti)
 
(2 intermediate revisions by the same user not shown)
Line 8: Line 8:
  
 
===C'est parti===
 
===C'est parti===
à la racine de l'arborescence Buildroot il y a la version "script" de ipkg qui sera appelée par les makefiles:<br>
+
à la racine de l'arborescence Buildroot il faut la version "script" de ipkg qui sera appelée par les makefiles des packages:<br>
-> création du répertoire ''script/''<br>
+
-> création du répertoire ''scripts/'' ->> et finalement pourquoi pas le mettre dans ''toolchain/'' directement ??<br>
-> copie des scripts ''ipkg'' et ''make-ipkg-dir.sh''<br>
+
-> copie des scripts ''ipkg'' et ''make-ipkg-dir.sh'' de OpenWrt<br>
  
on ne peut pas utiliser directement le makefile ''package/rules.mk'' de OpenWrt, et donc ça rèle implicite pour générer les ''.ipkg'', car chez eux, chaque package a un fichier ''Makefile'' dédié qui est appelé indépendamment /récursivement et pas un gros Makefile qui inclue tous les autres comme c'est le cas dans notre Buildroot actuel.
+
on ne peut pas utiliser directement le makefile ''package/rules.mk'' de OpenWrt, et donc ses règles implicites pour générer les ''.ipkg'', car chez eux, chaque package a un fichier ''Makefile'' dédié qui est appelé indépendamment/récursivement et pas un gros Makefile qui inclue tous les autres comme c'est le cas dans notre Buildroot actuel.
 
Donc chez nous, dans chaque makefile ''package.mk'', il faut ajouter une nouvelle cible qui génère les fichiers de conf pour ipkg.
 
Donc chez nous, dans chaque makefile ''package.mk'', il faut ajouter une nouvelle cible qui génère les fichiers de conf pour ipkg.
  
Pour construire des packages sur le Host, il faut les ftp://ftp.handhelds.org/packages/ipkg-utils
+
Pour chaque package:
 +
* dans le répertoire de build du package (''buildroot/build_arm_nofpu/$package_name/''), il faut un répertoire ''ipkg/$package_name/'' qui va contenir les exe/libs et les fichiers CONTROL/.. nécessaires à ipkg.
 +
* dans ''buildroot/package/$package_name'' il faut créer un répertoire ''ipkg/'' et mettre dedans un fichier ''$package_name.control'' avec les infos qui vont bien pour ipkg
  
Dans le répertoire de build du package il faut un rep ipkg/$package/ qui va contenir les exe/libs et les fichiers CONTROL/.. nécessaires à ipkg
+
A la racine de Buildroot il faut un répertoire où l'on peut stocker les packages: par exemple ''bin/packages/'' (à créer automatiquement dans un Makefile ??)
  
Pour chaque package dans buidlroot il faut créer un répertoire ipkg/ et mettre dedans un fichier package.control avec les infos qui vont bien pour ipkg
+
Pour chaque package, il y a donc un rep "ipkg/$package_name" qui est généré (??comment??) dans le répertoire de build et c'est là qu'il faut maintenant aussi installer les résultats de compile (ie en plus de ce qui est fait dans $(STAGING_DIR) / $(TARGET_DIR).
  
A la racine de Buildroot il faut un répertoire où l'on peut stocker les packages: par exemple bin/packages/ (à créer automatiquement dans un Makefile ??)
+
dans OpenWrt ils ont pour chaque target/routeur supportés un répertoire dans build-xxx/$target/ qui contient tous leurs binaires générés pour la plateforme. c'est là aussi qu'ils ont leur ipkg.conf nécessaires à "ipkg install". Moi je vais tenter de le mettre dans ''build_arm_nofpu/'' tout court...
  
Pour chaque package, il y a donc un rep "ipkg/$package" dans le répertoire de build et c'est là qu'il faut maintenant aussi installer les résultats de compile
+
'''Pour l'instant seul le package Buildroot ipkg génère un paquet .ipkg. Il faudrait ajouter la génération de paquet à chaque package et donc ça va demander du boulot !!'''
  
dans OpenWrt ils ont pour chaque target un rep dans build-xxx/$target/ qui contient toutes leurs binaires générés pour la plateforme. c'est là aussi qu'ils ont leur ipkg.conf nécessaires à "ipkg install". Moi je vais tenter de le mettre dans build-armnofpu tout court...
+
===ipkg-utils===
 +
Pour construire des packages sur le Host, il faut les ftp://ftp.handhelds.org/packages/ipkg-utils.
  
attention ne pas confondre ipkg-build qui build les packages et ipkg-install qui les install dans un rootfs avant de générer un jffs2 par exemple..
+
!! Attention ne pas confondre ''ipkg-build'' qui génère les paquets et ''ipkg-install'' qui permet de les installer dans un rootfs, avant de générer l'image jffs2 par exemple !!
  
dans buildroot/toolchain il faut rajouter un rep "ipkg-utils/" (copie de celui de OpenWrt avec modif du makefile) ça permet de recupérer pour le host ipkg-build, ipkg-make-index & Co et de construire le fichier ipkg.conf dans $(STAGING_DIR)/etc/
+
Dans ''buildroot/toolchain'' il faut rajouter un répertoire ''ipkg-utils/'' (copie de celui de OpenWrt avec modif du makefile). Cela permet d'installer pour le Host: ''ipkg-build'', ''ipkg-make-index'' & Co et de construire le fichier ''$(STAGING_DIR)/etc/ipkg.conf''.
  
 
+
faut aussi dans le makefile principal mettre un cd bin/packages && ../../build_arm_nofpu/staging_dir/usr/bin/ipkg-make-index . > Packages    ça permet de générer la liste des paquets générés. Ce fichier n'est apparement nécessaire que pour les Serveurs/Feeds.
à faire: mettre en place ipkg-build dans le Makefile pour le package de test (ipkg) -> ok
+
 
+
faut aussi dans le makefile principal mettre un cd bin/packages && ../../build_arm_nofpu/staging_dir/usr/bin/ipkg-make-index . > Packages    ça permet de générer la liste des packages du système.
+
Ce fichier n'est apparement nécessaire que pour les Serveurs de Feed
+
  
 
faudrait définir les variables IPKG_BUILD, etc.. dans un fichier global type package/Makefile.in (là où sont définis les STAGING_DIR & Co...)
 
faudrait définir les variables IPKG_BUILD, etc.. dans un fichier global type package/Makefile.in (là où sont définis les STAGING_DIR & Co...)
Line 41: Line 40:
 
simplifier la génération du fichier CONTROL/control dans le makefile en mettant une partie générique dans un script ??
 
simplifier la génération du fichier CONTROL/control dans le makefile en mettant une partie générique dans un script ??
  
Pour packager les modules Linux, il faut regarder du coté de "target/linux/control/" où il y a un fichier .control par package module. Ces fichiers ".control" sont utilisés par un makefile: "target/linux/linux-2.4/Makefile" qui inclue un "rule.mk" dans lequel est définie une putain de template KMOD_template qui pour chaque module qui ont été configurés (elle scan le .config à la racine) et bien va builder le package.... la folie... y a aussi dans  "target/linux/linux-2.4/Makefile" la config kernel qui est incluse pour savoir quels modules sont configurés ou pas..
+
===Paquets modules noyau===
 +
Pour packager les modules Linux, il faut regarder du coté de "target/linux/control/" où il y a un fichier .control par paquet module. Ces fichiers ".control" sont utilisés par un makefile: "target/linux/linux-2.4/Makefile" qui inclue un "rule.mk" dans lequel est définie une putain de template KMOD_template qui pour chaque module qui ont été configurés (elle scan le .config à la racine) et bien va builder le package.... la folie... y a aussi dans  "target/linux/linux-2.4/Makefile" la config kernel qui est incluse pour savoir quels modules sont configurés ou pas..
 
les fichiers .control dans "target/linux/control/" servent à générer les rep et fichiers dans "build_arm.../linux-24-brcm/linux-modules/ipkg".  Dans ce rep sont mis les rep CONTROL et les modules dans lib/modules... et après ipkg est lancé par dessus...
 
les fichiers .control dans "target/linux/control/" servent à générer les rep et fichiers dans "build_arm.../linux-24-brcm/linux-modules/ipkg".  Dans ce rep sont mis les rep CONTROL et les modules dans lib/modules... et après ipkg est lancé par dessus...
 
un truc intéressant aussi dans whiterussian est la présence de etc/modules.d dans chaque package avec un fichier dedans contenant le nom du module à charger... ça permet d'automatiser le chargement des modules au démarrage si le package est installé ou pas.
 
un truc intéressant aussi dans whiterussian est la présence de etc/modules.d dans chaque package avec un fichier dedans contenant le nom du module à charger... ça permet d'automatiser le chargement des modules au démarrage si le package est installé ou pas.
Line 47: Line 47:
 
du coup:
 
du coup:
 
création de buildroot/target/device/armadeus/linux/control/*.control comme dans whiteruss/target/linux/control/...
 
création de buildroot/target/device/armadeus/linux/control/*.control comme dans whiteruss/target/linux/control/...
les fichiers des .control contiennent des infos en plus à la fin du fichier afin de pourvoir utiliser mon script /make-kmod-control.sh qui va parcourir le répertoire et packager les modules qui en ont besoin (en vérifiant le .config du noyau)
+
Chez nous les fichiers ''.control'' contiennent des infos en plus à la fin, afin de pourvoir utiliser mon script /make-kmod-control.sh qui va parcourir le répertoire et packager les modules qui en ont besoin (en vérifiant le .config du noyau)

Latest revision as of 19:12, 9 August 2007

Intégration de IPKG (inspiration libre de OpenWRT / WhiteRussian)

Introduction

On peut séparer l'ajout de ipkg dans le projet Armadeus en 2 parties:

  • une partie "cible" qui permettra de disposer de la commande ipkg sur la cible et ainsi de charger des paquets prégénérés depuis notre Feed (=serveur Web de paquets). Cette partie est déjà intégrée dans Buildroot grâce au portage du travail fait dans OpenWRT (=en gros création d'un rep ipkg/ dans buildroot/package/ et adaptation du Makefile)
  • une partie "Host" qui permet à tous de générer des paquets ipkg à partir des packages Buildroot. C'est cette partie qui est la plus "compliquée" et qui est détaillée sur cette page.

Pour savoir exactement comment marche ipkg, il faut lire: http://handhelds.org/moin/moin.cgi/Ipkg

C'est parti

à la racine de l'arborescence Buildroot il faut la version "script" de ipkg qui sera appelée par les makefiles des packages:
-> création du répertoire scripts/ ->> et finalement pourquoi pas le mettre dans toolchain/ directement ??
-> copie des scripts ipkg et make-ipkg-dir.sh de OpenWrt

on ne peut pas utiliser directement le makefile package/rules.mk de OpenWrt, et donc ses règles implicites pour générer les .ipkg, car chez eux, chaque package a un fichier Makefile dédié qui est appelé indépendamment/récursivement et pas un gros Makefile qui inclue tous les autres comme c'est le cas dans notre Buildroot actuel. Donc chez nous, dans chaque makefile package.mk, il faut ajouter une nouvelle cible qui génère les fichiers de conf pour ipkg.

Pour chaque package:

  • dans le répertoire de build du package (buildroot/build_arm_nofpu/$package_name/), il faut un répertoire ipkg/$package_name/ qui va contenir les exe/libs et les fichiers CONTROL/.. nécessaires à ipkg.
  • dans buildroot/package/$package_name il faut créer un répertoire ipkg/ et mettre dedans un fichier $package_name.control avec les infos qui vont bien pour ipkg

A la racine de Buildroot il faut un répertoire où l'on peut stocker les packages: par exemple bin/packages/ (à créer automatiquement dans un Makefile ??)

Pour chaque package, il y a donc un rep "ipkg/$package_name" qui est généré (??comment??) dans le répertoire de build et c'est là qu'il faut maintenant aussi installer les résultats de compile (ie en plus de ce qui est fait dans $(STAGING_DIR) / $(TARGET_DIR).

dans OpenWrt ils ont pour chaque target/routeur supportés un répertoire dans build-xxx/$target/ qui contient tous leurs binaires générés pour la plateforme. c'est là aussi qu'ils ont leur ipkg.conf nécessaires à "ipkg install". Moi je vais tenter de le mettre dans build_arm_nofpu/ tout court...

Pour l'instant seul le package Buildroot ipkg génère un paquet .ipkg. Il faudrait ajouter la génération de paquet à chaque package et donc ça va demander du boulot !!

ipkg-utils

Pour construire des packages sur le Host, il faut les ftp://ftp.handhelds.org/packages/ipkg-utils.

!! Attention ne pas confondre ipkg-build qui génère les paquets et ipkg-install qui permet de les installer dans un rootfs, avant de générer l'image jffs2 par exemple !!

Dans buildroot/toolchain il faut rajouter un répertoire ipkg-utils/ (copie de celui de OpenWrt avec modif du makefile). Cela permet d'installer pour le Host: ipkg-build, ipkg-make-index & Co et de construire le fichier $(STAGING_DIR)/etc/ipkg.conf.

faut aussi dans le makefile principal mettre un cd bin/packages && ../../build_arm_nofpu/staging_dir/usr/bin/ipkg-make-index . > Packages ça permet de générer la liste des paquets générés. Ce fichier n'est apparement nécessaire que pour les Serveurs/Feeds.

faudrait définir les variables IPKG_BUILD, etc.. dans un fichier global type package/Makefile.in (là où sont définis les STAGING_DIR & Co...)

simplifier la génération du fichier CONTROL/control dans le makefile en mettant une partie générique dans un script ??

Paquets modules noyau

Pour packager les modules Linux, il faut regarder du coté de "target/linux/control/" où il y a un fichier .control par paquet module. Ces fichiers ".control" sont utilisés par un makefile: "target/linux/linux-2.4/Makefile" qui inclue un "rule.mk" dans lequel est définie une putain de template KMOD_template qui pour chaque module qui ont été configurés (elle scan le .config à la racine) et bien va builder le package.... la folie... y a aussi dans "target/linux/linux-2.4/Makefile" la config kernel qui est incluse pour savoir quels modules sont configurés ou pas.. les fichiers .control dans "target/linux/control/" servent à générer les rep et fichiers dans "build_arm.../linux-24-brcm/linux-modules/ipkg". Dans ce rep sont mis les rep CONTROL et les modules dans lib/modules... et après ipkg est lancé par dessus... un truc intéressant aussi dans whiterussian est la présence de etc/modules.d dans chaque package avec un fichier dedans contenant le nom du module à charger... ça permet d'automatiser le chargement des modules au démarrage si le package est installé ou pas.

du coup: création de buildroot/target/device/armadeus/linux/control/*.control comme dans whiteruss/target/linux/control/... Chez nous les fichiers .control contiennent des infos en plus à la fin, afin de pourvoir utiliser mon script /make-kmod-control.sh qui va parcourir le répertoire et packager les modules qui en ont besoin (en vérifiant le .config du noyau)