Où ranger les exécutables 32 bits ?

Support Debian
#1

Bonsoir à tous,

Je suis en train de confectionner un paquet pour BMRT (Blue Moon Rendering Tool), un moteur de rendu 3D historique mais qui rend encore de bons services, dont j’ai tous les binaires. Seulement voilà, tout est en trente-deux bits, et si les repertoires lib32 ne manquent pas dans une honnête installation, je ne sais que faire des exécutables, étant entendu qu’un beau paquet comme celui que je mijote doit immanquablement trouver place dans /usr et pas perdu en province…

  • ouvrir un répertoire “32” à la main dans /usr/bin : ça sent un peu le soufre, non ?
  • la même chose dans /usr/local : plus discret mais, au fond, c’est pareil…
  • en vrac dans /opt : cela revient à l’immonde situation actuelle, que je suis précisément en train de nettoyer en faisant ces paquets.

Quelqu’un aura-t-il l’idée du siècle, au nom de l’élégance ?

A+

Sergio

#2

d’aprés la définition de la FHS, un paquet deb n’a rien à faire dans /opt.wiki.debian.org/FilesystemHierarchyStandard

A minima se sera /usr, aprés je dirai /usr/bin.
Mais avec multiarch, je ne sais plus trop si c’est encore valable.
Crée un rep 32b me ferai trop penser à windows avec son win32 :slightly_smiling:

#3

S’il n’existe pas de version amd64, l’exécutable trouvera parfaitement sa place sous /usr/local/bin sans risque de créer de conflit.

#4

Et pour encore plus de sécurité, tu peux très bien laisser cet exécutable dans ton dossier utilisateur, par exemple /home/moi/logiciels.
Par contre, pense à ajouter ceci dans ton fichier ~/.profile ou ~/.bashrc :

#5

OK, merci à tous, je me demande si je ne vais pas me laisser tenter par la solution violente directos dans le /usr/bin, sans répertoire particulier. J’ai une question subsidiaire dans le même registre, je vais rouvrir un fil.

A+

Sergio

#6

[quote=“Sergio”]OK, merci à tous, je me demande si je ne vais pas me laisser tenter par la solution violente directos dans le /usr/bin, sans répertoire particulier. J’ai une question subsidiaire dans le même registre, je vais rouvrir un fil.

A+

Sergio[/quote]
Dans ce cas, j’insiste : met les dans /usr/local/bin : cela te permet de faciliter une éventuelle future désinstallation.

#7

En fait ce sera bien pareil : ce qui est intéressant dans cette affaire de réaliser des paquets au lieu de laisser du vrac dans le /opt, c’est la protection des dépendances. Maintenant cas particulier, un trente-deux bits verrouillé parce que, sans les sources, je ne peux le recompiler. Mes exécutables (une petite dizaine pour ce moteur de rendu) seront perdus au milieu des soixante-quatre bits, ce n’est pas très grave du moment qu’en désinstallant le paquet ils disparaissent vite fait… Mais c’est vrai, si l’on met tout en paquets, on s’aperçoit que le /usr/local, où l’on installe traditionnellement ce que l’on compile soi-même, ne sert plus.

#8

Honnêtement quel est le problème de mettre tes binaires dans /opt. Ta base ne va pas explosé. Tu sais parfaitement où sont tes paquets, tu peux rajouter les librairies dédiés dans /opt/lib32 et il te suffit juste de faire un script de lancement dans /usr/local/bin.
Dans la mesure ou de toute façon c’est un paquet binaire, il n’a rien d’un paquet debian devant respecter une hiérarchie quelconque. En procédant aini (dans /opt) tu auras clairement différencié tes binaires des autres logiciels debian tout en ayant un truc propre désinstallable rapidement. Que demander de plus?

#9

Oui mais justement je me suis mis à en faire un vrai paquet Debian, méthode directe. En ce moment je suis en train de récupérer les dépendances par ldd et leurs paquets d’origine par dpkg -S.

Bien sûr, que j’aurais pu laisser ma dizaine d’applicatifs en vrac dans /opt, il y a même Blender, qui change tout le temps, et à un moment il fallait suivre à cause de Makehuman. Enfin, cela fait un moment que je voulais voir cette confection de paquets, et puis il y a quand même un avantage technique, la protection des dépendances telle que je viens de la voir fonctionner en réel sous Synaptic. Un peu de perfectionnisme, tout cela, mais peut-être qu’un peu d’activité système me manquait par rapport à Solaris…

#10

Quel est le rapport entre la localisation des binaires et la qualité de ton paquet? Pour un extérieur, avoir ces binaires clairement localisés dans un endroit soulignant leur aspect particulier est une bonne chose. Si tu veux absolument être dans /usr, crée un répertoire /usr/local/tonpaquet et met tes binaires dedans avec un script dans /usr/local/bin le lançant.

Pour obtenir les dépendances de tes binaires, j’ai fais un script assez efficace:

#!/bin/bash find . -type f | xargs ldd 2> /dev/null | sed -e '1,$s/=.*//' | sed -e '1,$s/^ */dpkg -S /' | grep -v ":" | sed -e '1,$s/ (.*$//' | grep "\.so" | sort -u | sh | sed -e '1,$s/:.*//' | sort -u | sed -e '1,$s/^/dpkg -l | grep "^[a-zA-Z]\\{2\\} * /' | sed -e '1,$s/$/ "/' |sh
Tu te mets dans le répertoire contenant les binaires, éventuellement rajoute ceux que tu obtiens en te mettant dans le répertoire contenant les librairies spécifiques.
Tu te contentes de lancer le script, ça te sort la liste des paquets. (Il faut que ceux ci soient installés et le programme fonctionnel)

#11

C’est curieux, voici ce qu’il donne :

[quote]ii lib32gcc1 1:4.7.2-5 amd64 GCC support library (32 bit Version)
ii lib32stdc++6 4.7.2-5 amd64 GNU Standard C++ Library v3 (32 bit Version)
ii libc6-i386 2.13-38 amd64 Embedded GNU C Library: 32-bit shared libraries for AMD64
[/quote]
et voici ce que je trouve à la main :

Je pense que c’est ton script qui élimine les dépendances secondaires, les jprimaires suffisant, mais alors, pour que l’on retrouve ma partie graphique, cela signifierait que, par exemple, libc6-i386 dépend d’une GLX ou GLU Mesa ?

EDIT : je viens de regarder sous Synaptic, cela ressemble bien à ça.

#12

Ard, il ne donne que les paquets amd64…