Script bash en root ou quoi ?

Support Debian
#1

Ok le titre du post est un peu bizare, j’ai toujours du mal a trouver un bon titre. :think:
Je veux faire un script bash qui me permetra de compiler un logiciel sans refaire toutes les commande a chaque fois.
Par exemple pour compiller Ogre 1.8 + OIS.
Je creer un fichier que je nome compil_ogre.sh que je rend executable.
Je mets ceci dedans:

[code]#On crée un dossier et on se place dedans
mkdir ~/ogre_comp &&
cd ~/ogre_comp &&

#Ogre
wget http://sourceforge.net/projects/ogre/files/ogre/1.8/1.8.0/ogre_src_v1-8-0.tar.bz2/download -O ogre_src_v1-8-0.tar.bz2 &&
tar xjf ogre_src_.bz2 &&
cd ogre_src &&
cmake -DCMAKE_BUILD_TYPE:STRING=Release -DOGRE_BUILD_SAMPLES:BOOL=OFF . &&
make -j2 &&
make install &&
cd … &&

#OIS
wget http://sourceforge.net/projects/wgois/files/Source%20Release/1.3/ois_v1-3.tar.gz/download -O ois_v1-3.tar.gz &&
tar xvfz ois_v1-3.tar.gz &&
cd ois-v1-3 &&
sh bootstrap &&
./configure &&
make -j2 &&
make install &&
cd … &&
[/code]

Pour l’executer soit:
1/ Je rentre le chemin de mon script dans un terminal root
La mon probleme c’est que mon dossier creer avec

mkdir ~/ogre_comp

Il se retrouve dans /root et non pas mon /home/user/

2/ Ou je met le chemin de mon script dans un terminal normal, mais cela ne fonctionne pas car:

make install

A besoin d’etre root pour etre executer

Je ne voudrais avoir a executer q’une fois mon mot de passe root pour la compilation des deux logiciel et que mon chemin de creation de dossier se retrouve dans /hom/user/ quelque soit la personne qui l’execute (user different)
Solution super simple de preference :smiley: noob inside
Merci d’avance

#2

Salut

[quote]fonctionne pas car:
make install
A besoin d’etre root pour etre executer[/quote]
Tu dis que ca fonctionne mais que ton seul problème c’est qu’il demande le pass root à un moment ?
Encore heureux que le système n’autorise pas n’importe qui à installer un programme :stuck_out_tongue:

Je ne connais pas cmake; c’est un truc spécial.
Généralement les compilations ressemblent a cela: http://linux-attitude.fr/post/utilisation-de-configure-make-make-install
Et l’étape configure peut être configurée avec les options spécifiques au programme que tu peux voir avec./configure --help
Dans ton cas tu utilise cmake, alors
As tu regardé les options de configurations de la Documentation Ogre Cmake ?

  1. Build directory (= Ou tu contruit )
  2. CMAKE_INSTALL_PREFIX (=Install directory, ou tu installe)
    http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Getting+Started+With+CMake#Build_options_and_the_CMake_cache
    Tu pourais donc demander à installer dans un dossier d’un simple utilisateur, au lieu d’installelr dans le système entier.

Pour le script en général, attention à comment tu indique les emplacement dans un script. Evidément qu’un raccourci comme “~/” ne vaudra pas la meme chose selon qui lance le script etc… Ca peut faire bobo.
=> http://abs.traduc.org/

Tu compiles si souvent que ca Ogre pour avoir besoin d’un script ?
Les scripts c’est bien pour des taches régulières; mais un script pour une compilation et installation me parait complexe.
D’un jour a l’autre les dépendances peuvent changer, etc et ton script fera du caca.
Je ne suis pas sur qu’un simple && suffise a etre sur que la commande d’avant a bien fait ce que tu voulais.
Peut-etre que tu devra ajouter des tests de vérification des étapes importantes( présence d’un fichier, analyse plus précise des réponses de la commande précédente…).

Bonne chance en tout cas.

#3

Quelques remarques en vrac pour compléter ce que dit SwitchT…

[ul][li] ~ indique toujours le répertoire de l’utilisateur en cours. Quant l’utilisateur c’est root, c’est normal que ~ renvoie sur /root.[/li]
[li] Concernant l’invasion de && dont tu sembles être victime : il suffit de mettre set -e en début de script et tu pourras te passer de tous ces && : ça reviendra au même (arrêt du script à la première erreur) mais ça sera à la fois beaucoup plus lisible et tu n’auras plus aucune chance de te tromper à ce niveau (c’est assez facile d’oublier de taper un && en fin de ligne…).[/li]
[li] On ne compile JAMAIS en root. Seul le make install a éventuellement besoin des droits root (en fonction de ton préfixe d’installation), le reste devrait être effectué en tant que simple utilisateur ou dans un chroot. Pas de chance, la compilation en tant que simple utilisateur rend ton script caduque (puisque le make install ne pourra pas marcher en simple utilisateur sauf si tu changes le préfixe d’installation)…[/li]
[li] Il y a une bonne raison pour laquelle tu compiles à partir des sources du projet plutôt que de compiler à partir des sources Debian (oui, Ogre 1.8 est dispo sur Debian) ? Si les développeurs Debian s’emmerdent à écrire des patchs c’est pas pour rien : soit ça corrige des problèmes de l’upstream soit ça adapte le logiciel à l’environnement Debian. Si tu me dis “je savais pas” alors j’aurais tendance à te conseiller d’apprendre à marcher (connaître un minimum ton système) avant de courir (compiler toi-même).[/li][/ul]

[quote=“SwitchT”]Tu compiles si souvent que ca Ogre pour avoir besoin d’un script ?
Les scripts c’est bien pour des taches régulières; mais un script pour une compilation et installation me parait complexe.
D’un jour a l’autre les dépendances peuvent changer, etc et ton script fera du caca.[/quote]
+1
Et franchement c’est pas bien compliqué de retaper ces commandes les rares fois où tu vas recompiler le truc. Si tu utilises les sources Debian c’est même encore plus simple.

[quote=“SwitchT”]Je ne suis pas sur qu’un simple && suffise a etre sur que la commande d’avant a bien fait ce que tu voulais.
Peut-etre que tu devra ajouter des tests de vérification des étapes importantes( présence d’un fichier, analyse plus précise des réponses de la commande précédente…).[/quote]
La chaîne de compilation s’arrête avec un code de retour >0 s’il y a le moindre problème. Un code 0 signifie “tout s’est bien passé” donc les && (ou le set -e) sont suffisants.

Si tu es si noob que tu le dis, pourquoi tu t’embarques dans une compilation ? Ce n’est jamais “super simple” de compiler un programme, et de toute évidence tu ne comprends pas encore ton système correctement. Je ne dis pas ça pour te décourager (au contraire, c’est bien cette attitude “même pas peur”, c’est comme ça qu’on avance) mais d’un autre côté là j’ai un peu l’impression que tu mets la charrue avant les bœufs.

Bon sinon si on ignore superbement toutes les remarques de SwitchT et de moi-même, la solution à ta question initiale est de remplacer ~/ par le chemin de ton répertoire utilisateur /home/user/. Mais garde bien en mémoire que ça n’est pas la bonne manière de faire, et que si tu continues dans cette voie là tout ce que tu vas faire c’est prendre des mauvaises habitudes. :wink:

#4

Salut,
En passant j’ajouterais que l’utilisation de checkinstall +dpkg permet des installations plus “propres”.

#5

Re :slightly_smiling:
CMAKE_INSTALL_PREFIX permet de spécifier ou on instale.
Si il choisis d’installer dans le dossier de son utilisateur, il pourra faire le make install sans besoin de root.
J’ai dis une bêtise selon toi Syam ?

#6

Non t’as pas dit de bêtises. :wink: C’est d’ailleurs aussi ce que je disais :

#7

:geek: me faudrais des lunettes :whistle:

#8

Merci a vous de toutes ces reponses

Non pour ogre mais j’essaye souvent des truc ou il faut installer pas mal de chose et je remet mon systeme a (presque) 0 souvent.
Dans ce cas la j’essaye de faire un script pour compiler les dependances de Rigs of Rods car il y a beaucoup a faire a chaque fois et que c’est tres penibles
http://www.rigsofrods.com/wiki/pages/Compiling_Sources_under_Linux
http://www.rigsofrods.com/wiki/pages/Compiling_3rd_party_libraries

Je connais “”“bien”"" le systeme (Presque 10 ans sur linux et rien d’autre) mais je commence juste les scripts bash, voila pourquoi je demande votre aide

Merci du tuyau mon noobisme diminue en bash :slightly_smiling:

Ok j’installe dans le dossier utilisateur

Oui je l’ai fait mais ca ne fonctionne pas avec toutes les dependances
J’ecris a coté de ce script ,un autre script pour tout desinstaller

Je vais me pencher sur cette histoire de sources presentes dans debian.
J’apprends tous les jours,merci de vos reponses constructives (quoi que un peu piquante par moment :laughing: )
J’essaye ca et je vous dis si c’est good
Et comme dit syam

#9

Dans ce cas créer des chroot serait sûrement intéressant pour toi. Ça te permettrait de bien séparer les choses : une machine “normale” fonctionnelle, et plusieurs environnements de test que tu peux modifier à ta guise, supprimer, dupliquer, chacun avec son ensemble de paquets indépendant des autres chroot.
Des machines virtuelles pourraient être une autre solution envisageable également mais c’est beaucoup plus lourd que des chroot au niveau des ressources utilisées (par contre l’isolation est encore meilleure).

Le principal c’est effectivement que ça reste constructif même si des fois ça pique un peu au passage (dans les limites du raisonnable)… :wink:
Faut bien que notre sale caractère s’exprime un peu de temps en temps, que diable ! :mrgreen:

#10

Oui il existe dans sid
Pour installer les dependances:

apt-get build-dep ogre-1.8 Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait E: La dépendance Build-Depends vis-à-vis de ogre ne peut être satisfaite car aucune version du paquet debhelper ne peut satisfaire à la version requise
Au final il faut que j’installe une SID pour avoir Ogre en 1.8 ?

#11

Salut,
En regardant la procédure d’installation du SDK Ogre:
http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Installing%20the%20Ogre%20SDK&tikiversion=Linux

Pour Linux ils proposent des dépôts pour Ubuntu.

J’ai regardé dans un Ubuntu les paquets portant le nom ogre.

Puis j’ai regardé dans les dépôts Debian de base.
Debian (Wheezy dans l’exempl ):

libogre-1.7.4-dbg libogre-1.8-dev libogre-1.8.0 libogre-1.8.0-dbg libogre-dev libogre-perl ogre-1.8-doc ogre-1.8-samples ogre-1.8-samples-data ogre-1.8-samples-dbg ogre-1.8-tools ogre-doc ogre-samples ogre-samples-dbg ogre-tools

Je vois plus de paquets dans Debian et plus récents ( 1.8 ) que dans le ppa Ubuntu ( 1.7.3 ).
Toi qui avait déja compilé le tout a la main, qu’avait tu de plus que dans ces dépôts?

L’installation du SDK ce fait avec:

Il correspond a version 1.7 chez moi.
Dans mon cas ( debian wheezy ) je vois même un paquet plus récent : libogre-dev-1.8; libre a toi te choisir.

Voila tout ca c’est ce qu’il y a sur le wiki de Ogre ( lien en haut) et aussi sur le site officiel Ogre à la page downloads: http://www.ogre3d.org/download
Dans cette partie des downloads, ils proposent aussi des outils ( tools) et des démos (samples).
Et ca je l’ai aussi dans les paquets debian.

J’ai testé les “samples” (démos) ca fonctionne chez moi, c’est joli le chateau en 3D et tout.

Avec dpkg, tu peux voir ce que contient un paquet exactement.
Ex , pour voir ce que contenait le paquet des examples, et trouver la commande pour démarrer le programme (donc un fichier étant dans le dossier ‘bin’):

Une dernière chose:
Quand tu sais pas trop quel paquet correspond a quoi et les versions disponibles dans quel dépôt etc…
y’a le site packages.debian.org, tu peux juste ajouter un mot a chercher a l’adresse , ex: ogre ca donne:
http://packages.debian.org/ogre
Tu verra tout, tu poura esuite affiner en cliquant sur ta version (squeeze, wheezy, etc), voir ce que contiennent les paquets exactement, compraer les version, voir les mails de ceux qui maintiennent les paquets, avoir la liste des bugs de ces paquets, voir les adaptations des programmes pour qu’ils soient bien intégré dans ton debian ( ce qui est donc mieux qu’une simple compilation qui ne sera pas obligatoirement respectueuse des facons de faire maison debian)etc…

Pas de bol si ca ne suffit pas dans ton cas et si tu dois compiler.
A plus :slightly_smiling:

#12

[quote=“SwitchT”]Pour Linux ils proposent des dépôts pour Ubuntu.

Je ne sais pas si ton intention était de conseiller l’installation de ces paquets Ubuntu sur une Debian, mais je préfère prendre les devants au cas où : ça serait une très mauvaise idée. Ubuntu est trop différente de Debian, ces paquets risqueraient de foutre la zone.

Non tu n’as pas besoin d’installer une Sid. Il te suffit d’activer les dépôts Sid (voire Testing éventuellement) dans ton sources.list, et de configurer ton /etc/apt/preferences en conséquence.
Ça te permettra de conserver ta Squeeze telle quelle, tout en ayant accès aux dépôts testing et unstable pour piocher dedans si tu le souhaites.
Lis attentivement le tutoriel “Sources de paquets : les bases (sources.list)” dans notre section Trucs et Astuces, ainsi que l’article sur l’étiquetage de paquets présent sur notre Wiki : isalo.org/wiki.debian-fr/ind … references ça te permettra de comprendre de quoi il retourne.
Étant donné que l’ajout de dépôts peut sérieusement foutre ta machine en l’air si c’est mal fait (voir les conséquences d’une mauvaise configuration : ecran-vert-et-perte-de-menu-de-configuration-t40105.html ; mais au contraire si c’est fait correctement tu ne risques rien), avant de faire la moindre modification je te conseille quand même de nous montrer ici-même les modifs que tu veux apporter à tes sources.list et preferences pour qu’on les valide.

Étant donné que tu utilises Squeeze, il est déconseillé d’utiliser les paquets binaires provenant de testing ou unstable. Par contre ce n’est absolument pas gênant de prendre les paquets sources dans testing ou unstable et de les recompiler pour les faire fonctionner sur Squeeze (c’est ce qu’on appelle faire un backport).

Juste pour clarifier les choses : ça fait combien de temps que tu utilises Debian ? Je demande ça parce que “10 ans sur Linux” c’est pas la même chose que “10 ans sur Debian”, Debian a quelques spécificités notamment la gestion de paquets.

#13

Déja essayé avec la version des depot mais la compilation de RoR s’arrete a un moment car il manque a Ogre 1.7 des choses qui on etais résolu en compilant la 1.8.

Mon source.liste :

[code]# deb http://ftp.fr.debian.org/debian/ squeeze main

squeeze-updates, previously known as ‘volatile’

deb http://ftp.fr.debian.org/debian/ squeeze-updates main
deb-src http://ftp.fr.debian.org/debian/ squeeze-updates main

testing

deb http://ftp.fr.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ testing main contrib non-free

sid

deb http://ftp.fr.debian.org/debian/ unstable main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ unstable main contrib non-free[/code]
Mes preferences :

[code]Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release a=testing
Pin-Priority: -100

Package: *
Pin: release a=unstable
Pin-Priority: -100
[/code]
Apres je seche un peu.
Il me faut quand meme les dependances pour compiler le paquet ?

Meme probleme que plus haut
Ou bien il faut que je le fasse en manuel(dependances et compilation)?

3ans de fedora, 4ans dual boot fedora+ubuntu, 1 ans ubuntu, 1ans debian et tous les deux ans j’essaye gentoo jusqu’a que j’ai mal au crane et j’abandone :slightly_smiling:

#14

Ton sources.list est un peu bizarre, il manque le dépôt principal (première ligne en commentaires).
Tu devrais plutôt utiliser celui-ci :

[code]# squeeze
deb http://ftp.fr.debian.org/debian/ squeeze main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ squeeze main contrib non-free

squeeze security

deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free

squeeze updates (former volatile)

deb http://ftp.fr.debian.org/debian/ squeeze-updates main
deb-src http://ftp.fr.debian.org/debian/ squeeze-updates main

testing

deb http://ftp.fr.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ testing main contrib non-free

sid

deb http://ftp.fr.debian.org/debian/ unstable main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ unstable main contrib non-free[/code]

Pour ton preferences, perso je mettrais testing et unstable à 1 pas à -100 (priorité négative = interdit l’installation des paquets) et je remplacerais “stable” par “squeeze” pour correspondre au sources.list.

apt-get update pour mettre à jour ta liste de paquets.
apt-get -s upgrade pour voir ce qui se passe si tu fais une mise à jour de ton système (-s = simulation), s’il te propose de mettre à jour plein de paquets (des centaines) c’est que tu as un problème avec ton preferences mais ne t’affole pas avec -s il ne fera aucune modification réelle sur ton système.
Si c’est bon, apt-get upgrade (sans le -s) pour faire les éventuelles mises à jour manquantes (ça peut pas faire de mal).

Pour installer les dépendances de compilation : apt-get build-dep ogre-1.8/testing (ou /unstable si tu préfères, bref t’as compris le principe). Ces dépendances seront prises dans Squeeze mais en fonction des sources de testing, ce qui garantit que lorsque tu compileras Ogre 1.8 il fonctionnera correctement sur Squeeze.
Une fois que les dépendances de compilation sont installées, pour télécharger les sources et construire les paquets Ogre 1.8 (en un seul coup) : apt-get -b source ogre-1.8/testing

#15

apt-get build-dep ogre-1.8/unstable # ou /stable et /testing Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait E: La dépendance Build-Depends vis-à-vis de ogre-1.8 ne peut être satisfaite car aucune version du paquet debhelper ne peut satisfaire à la version requise
Meme probleme
Je commence a croire que compiler depuis les sources du projet c’est beaucoup plus facile :slightly_smiling:
Mais j’abandonne pas

#16

Je pense que cela doit venir de la priorité des depots
Il est ecrit ici:
isalo.org/wiki.debian-fr/ind … es.list.3F
Ligne Pin-Priority

C’est sur cette ligne qu’est indiquée la priorité du paquet ou groupe de paquets. Elle doit être un entier positif ou négatif. Ces priorités sont interprétés à peu près comme suit:

P > 1000
Cette priorité entraîne l’installation du paquet même s’il s’agit d’un retour en arrière.

990 < P <=1000
La version sera installée, même si elle n’appartient pas à la distribution par défaut ; mais elle ne sera pas installée si la version installée est plus récente.

500 < P <=990
La version sera installée, sauf s’il existe une version appartenant à la distribution par défaut ou si la version installée est plus récente.

100 < P <=500
La version sera installée, sauf s’il existe une version appartenant à une autre distribution ou si la version installée est plus récente.

0 < P <=100
La version sera installée si aucune version du paquet n’est installée.

Une version de debhelper est deja installé ^^

#17

Non mais en fait j’en ai zappé un gros morceau. :blush:

Le problème ne vient pas de la priorité des dépôts Wheezy (dans mon chroot je m’en sors très bien avec une priorité de 1) mais du fait que plusieurs paquets Wheezy sont nécessaires pour la phase de compilation (debhelper, binutils, dpkg, multiarch-support, …) et qu’il faudrait également faire les backports avant (et donc te retrouver avec un système qui n’est plus tout à fait une Squeeze). Au contraire la priorité 1 a en quelque sorte “protégé” ton système.
Pour faire les choses correctement il te faudrait un chroot où tu pourras installer les backports des paquets Wheezy nécessaires à la compilation.

#18

Ok ok pas de soucis syam.
Le but de la question originel c’était de creer un script de compilation et d’installation pour le jeu,Rigs of rods.
Que d’autres aurais pu éventuellement utiliser (après vérification par des expert :slightly_smiling: )
Donc tu m’as déja donné la réponse:

Je vais opter pour cette solution dans mon script plutot que de créer un chroot pour tous ceux qui veulent jouer au jeu :slightly_smiling:
Par contre je vais me metre a réflechir et utilisé un chroot et toute les technique apprisent plus haut
Merci a vous de vos réponses
Je pense revenir souvent sur ce fofo pour vous prendre un peu de votre temps et de vos connaissance

#19

[quote=“Velociraptux”]Le but de la question originel c’était de creer un script de compilation et d’installation pour le jeu,Rigs of rods.
Que d’autres aurais pu éventuellement utiliser (après vérification par des expert :slightly_smiling: )[/quote]
Ah oui effectivement dans ce cas ton objectif de départ (script) a plus de sens. D’où l’utilité d’expliquer également le but final que tu poursuis, et non pas seulement la manière dont tu veux y arriver. :wink:

Cela dit, rien ne t’empêche de distribuer également les paquets .deb une fois tout compilé, ça serait encore plus simple pour les autres (en admettant qu’ils aient confiance en toi, c’est toujours le point délicat dans la distribution de binaires). Et là, utiliser les sources Debian prend tout son sens puisque l’empaquetage des paquets backportés se fait tout seul, mais du coup la procédure de compilation est un peu plus complexe à mettre en place au départ comme tu as pu le voir.

Bon courage et à bientôt ! :slightly_smiling: