Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 22/11/2006, à 23:21

Cathou

(Plein de) Questions sur le développement de paquets

Bonjour,

- je cherche à savoir où trouver un document solide du genre "Ubuntu Policy Manual" qui préciserait comment ubuntu s'écarte de debian.
Un exemple, entre autres: dans le champ Section du fichier de contrôle, debian reconnaît 'non-free' et j'ai vu que pour ubuntu il s'agit en revanche de 'restricted', voire même de 'restricted/base' ou 'restricted/misc'.
J'ai rien trouvé de bien fameux via google sad

- je voudrais faire dépendre un paquet d'une version particulière d'ubuntu, par exemple dapper ou edgy, et ceci indépendamment de l'architecture. Comment faire?

Merci d'avance pour toute piste intéressante smile

Dernière modification par Cathou (Le 03/12/2006, à 12:47)

#2 Le 22/11/2006, à 23:32

lut!n

Re : (Plein de) Questions sur le développement de paquets

pour le reste je ne sais pas, mais tu ne peux pas rendre un paquet dependant d'un version particuliere, dans la mesure ou la distribution n'est qu'un ensemble de paquets de différentes versions, et pas une entité en soi, au sens packaging j'entends. Le mieux que tu puisses faire a mon avis c'est de versionner tes build-depends de maniere a le rendre incompatible avec la ou les distro pour lesquelles tu ne veux pas contruire. Mais au fait, pourquoi vouloir faire dépendre un paquet d'une version particulière ?

Hors ligne

#3 Le 23/11/2006, à 11:02

Cathou

Re : (Plein de) Questions sur le développement de paquets

Mais au fait, pourquoi vouloir faire dépendre un paquet d'une version particulière ?

Ben mon paquet doit fournir des modules noyau qui sont incompatibles avec des versions anciennes de noyau, quelle que soit l'archi.

Ma première idée était de le faire dépendre d'un méta-paquet du genre linux-image-2.6.15-23 mais:
- le méta-paquet pourrait avoir été désinstallé par l'utilisateur, et je ne veux pas forcer sa réinstall contre sa volonté
- ..et de toute façon ce méta-paquet n'existe pas big_smile

Ma deuxième idée était de vérifier le contenu de /etc/lsb-release pendant l'exécution du script preinst.
Mais ce serait vraiment immonde je trouve yikes

Ma troisième idée était de le faire dépendre d'un paquet virtuel exporté par un noyau installé.
Mais dans ce cas je n'ai le choix qu'entre linux-image et linux-image-2.6 ce qui n'est pas assez précis..
Ce qui aurait été pas mal c'est linux-image-2.6.15 mais il existe pas. grrr..

Le mieux que tu puisses faire a mon avis c'est de versionner tes build-depends de maniere a le rendre incompatible avec la ou les distro pour lesquelles tu ne veux pas contruire.

J'ai pas encore pigé la clause build-depends :shame:
Je vais creuser dans cette direction, merci smile

dans la mesure ou la distribution n'est qu'un ensemble de paquets de différentes versions, et pas une entité en soi, au sens packaging j'entends.

Oui je vois, malgré tout on peut pas installer un noyau linux-image-2.6.17-10-generic sous breezy par exemple. Si?

#4 Le 01/12/2006, à 09:36

Cathou

Re : (Plein de) Questions sur le développement de paquets

UP

C'est toujours d'actualité, et je vais rajouter une question hmm

- Je voudrais compiler sur ma machine (dapper i386) des paquets pour une autre archi que la mienne. D'après ce que j'ai pu voir, pbuilder est capable de faire ça, mais il y a très peu d'explications. De plus, j'ai vu qu'il existe dpkg-cross. Vous me conseillez quoi?

#5 Le 01/12/2006, à 13:45

mr_pouit

Re : (Plein de) Questions sur le développement de paquets

Cathou a écrit :

Ben mon paquet doit fournir des modules noyau qui sont incompatibles avec des versions anciennes de noyau, quelle que soit l'archi.

Dans ce cas, fais le dépendre du noyau pour lequel tu compiles le module (linux-image-2.6.17-10-generic par exemple), vu que de toute façon le module ne fonctionnera pas avec une autre version. wink

J'ai pas encore pigé la clause build-depends :shame:
Je vais creuser dans cette direction, merci smile

Ce sont les dépendances nécessaires à la compilation (je pense que tu t'en doutais lol).
Donc, si tu mets Build-Depends: debhelper (>=5), le paquet ne construira pas sous breezy, car il n'y a que debhelper 4.

Oui je vois, malgré tout on peut pas installer un noyau linux-image-2.6.17-10-generic sous breezy par exemple. Si?

Justement à cause des dépendances (et Build-Depends)

Cathou a écrit :

UP

C'est toujours d'actualité, et je vais rajouter une question hmm

- Je voudrais compiler sur ma machine (dapper i386) des paquets pour une autre archi que la mienne. D'après ce que j'ai pu voir, pbuilder est capable de faire ça, mais il y a très peu d'explications. De plus, j'ai vu qu'il existe dpkg-cross. Vous me conseillez quoi?

essaie dpkg-cross, car j'avais lu que pbuilder ne le supportait pas très bien (en tout cas, j'ai essayé de créer un pbuilder amd64 sous i386, mais ça ne marchait pas)

Hors ligne

#6 Le 02/12/2006, à 14:07

Cathou

Re : (Plein de) Questions sur le développement de paquets

Merci pour dpgk-cross, ça m'évitera de perdre du temps le moment venu. Je vais le garder sous le coude en fait, de la même manière que pbuilder, que je ne l'utilise pas encore..
Pour le moment je fais tout à coup de chown, chmod, dpkg-deb -b et linda. Pas taper.. smile

Il faut dire que mes paquets sont uniquement binaires, c'est pourquoi j'ai fait l'impasse sur la clause Build-Depends.

Malgré tout je précise que je suis extrèmement attentive à l'idempotence, et que je suis allée jusqu'à mettre des traces dans mes scripts de paquets pour bien comprendre la mécanique de dpkg en cas de remove, purge, mise à jour de version, etc..

Dans ce cas, fais le dépendre du noyau pour lequel tu compiles le module (linux-image-2.6.17-10-generic par exemple), vu que de toute façon le module ne fonctionnera pas avec une autre version.

Oui oui bien sûr, mais.. en fait, autant décrire les tas de lard, dans l'attente de ton avis:

Le problème est simple: je fais des paquets pour un modem nécessitant un module noyau qui est déficient sous dapper, mais correct sous edgy et ultérieures.

Voila la liste de mes paquets et leurs dépendances actuelles:

1) Un paquet indépendant de l'archi et de la version d'ubuntu.
Architecture: all
Package: firmwares

2) Des paquets i386 pour dapper, par exemple celui qui fournit le module noyau compilé pour le noyau 2.6.15-27-k7:
Package: pilote-2.6.15.27-k7
Depends: firmwares, linux-image-2.6.15-27-k7
Provides: pilote

J'ai ainsi 12 paquets correspondant aux noyaux i386 disponibles sur les dépots dapper..
Quand j'installe un de ces paquets, ça rend le modem fonctionnel sous dapper pour le noyau en question.

3) Différents paquets de connexion, indépendants de l'archi et de la version d'ubuntu. Typiquement:
Architecture: all
Package: pilote-connex-pppoa
Depends: pilote

4) Des méta-paquets i386 pour edgy. Typiquement:
Package: pilote-2.6.17-10-generic
Depends: firmwares, linux-image-2.6.17-10-generic
Provides: pilote

Tel quel ça marche très bien, grâce aux contraintes fortes sur les versions de noyaux, et à l'utilisation du paquet virtuel 'pilote'. Mais une chose me gène: j'aimerais trouver un moyen de me passer des méta-paquets sous edgy. En effet, dès qu'on installe le paquet firmwares sous edgy le modem EST fonctionnel, et ce serait bien de pouvoir offrir directement un type de connexion avec un paquet du type 3 cool

Alors voila, d'après toi existe-t-il quelque chose de plus élégant que de se servir des paquets du type 4 ?
J'ai essayé de faire des depends conditionnels dans les paquets de type 3, mais la syntaxe admise dans le fichier control semble limitée..
Quelque chose m'échappe, probablement. Merci d'avance de me faire profiter de tes lumières.

Au fait, est-ce que #ubuntu-fr-classroom est un lieu de discussion approprié si on fait comme moi des paquets sans pbuilder?
Et faut-il faire une manip particulière quand on entre dans le canal? J'y suis allée il y a quelques temps et il y avait du beau linge, mais tout le monde était silencieux. Faut dire qu'en plus d'être apprentie-packageuse, je suis une bille en irc roll

@+

#7 Le 03/12/2006, à 12:47

Cathou

Re : (Plein de) Questions sur le développement de paquets

UP

Si quelqu'un pouvait donner un avis sur ce qui est décrit dans le post précédent..
Merci d'avance smile

#8 Le 03/12/2006, à 21:10

mr_pouit

Re : (Plein de) Questions sur le développement de paquets

On ne peut pas faire "simplement" des dépendances selon l'architecture (il y a des méthodes, mais un méta-paquet c'est plus simple à gérer) wink

Et #ubuntu-fr-classroom est approprié, t'as juste pas eu de chance en passant à un moment ou c'était silencieux (c'est rare lol)

Hors ligne

#9 Le 03/12/2006, à 22:47

Cathou

Re : (Plein de) Questions sur le développement de paquets

Merci bien.

#ubuntu-fr-classroom est approprié, t'as juste pas eu de chance

Je ferai une nouvelle tentative un de ces soirs smile

#10 Le 06/12/2006, à 23:39

ares

Re : (Plein de) Questions sur le développement de paquets

Bonjour,

Je ne suis pas un spécialiste Debian et encore moins du "Paquet" smile

1- Si je comprends bien la "philosophie Debiannesque" cela ce résume en :
« apt-get mon fils » ou « dpkg install mon fils »
En gardant ce principe je ne peux qu'être admiratif devant ton travail pour tout ces paquets disponibles. J'ai eu quelques difficultés a en faire un ! smile

2-  A mon humble avis je serais pour garder l'indépendance maximum vis à vis du noyau. L'utilisateur doit avoir la possibilité d'installer un nouveau noyau et de désinstaller le précédent sans perdre le paquet "firware". Dans mon cas j'utilise le 2.6.19 et en secours le 2.6.18

Je ne pense pas avoir répondu a tes interrogations techniques, mais il est important de faciliter l'utilisation du Fast 800 que beaucoup aime a maudire mais fonctionne depuis plus de trois ans chez mois (Gento, Redhat, & Kubuntu)

Avec mes encourengements pour tes efforts Cathou !

Dernière modification par ares (Le 06/12/2006, à 23:39)


Le droit d'emmerder Dieu BNF

Hors ligne