Risques : Installation par Utilisateur de paquets .deb Hors distribution ? Le sujet est résolu

[dezix]

Bonjour,

Suite au problème que je rencontre avec LibreOffice Draw,
je me suis tourné vers la communauté de LO.

On y préconise en 1er lieu l'Installation de plusieurs versions de LibreOffice en parallèle
notamment de la version stable la plus fraîche pour voir si le problème rencontré se reproduit ou non.

La méthode proposée consiste à mettre les paquets à installer dans un sous-répertoire de /home/user/
d'y créer aussi un répertoire p.ex: ./install pour obtenir :

Code : Tout sélectionner

my_program
	├── install
	├── pkge-1.deb
	├── pkge-2.deb
	└── pkge-3.deb

puis,

cd ./install

enfin,

for i in ../*.deb; do dpkg-deb -x $i . ; done

pour installer (extraire) la collection de paquets.


Dans le cas particulier des paquets livrés par l'archive en provenance de libreoffice.org
tout s'installe proprement dans : ./install/opt/libreoffice7.0/...

J'ai testé cela dans une VBox en stable (libreoffice 6.1) => La version 7 fonctionne.


Mais avant de faire cela sur mon système installé (testing),

je m'interroge sur innocuité du procédé.



Pour aller un peu plus loin dans cette direction,
cette VM stable est installée avec LXDE et lxtask le gestionnaire de processus dans sa version (0.1.9-1)
— j'ai choisi ce paquet car léger et peu de dépendances —

j'ai donc téléchargé la version (0.1.8-1) de stretch avec :

Code : Tout sélectionner

$ wget http://ftp.fr.debian.org/debian/pool/main/l/lxtask/lxtask_0.1.8-1_amd64.deb

et j'ai suivi la même méthode en me plaçant initialement dans : ~/.local/share/lxtask-exp

cela donne au final :

Code : Tout sélectionner

/home/toto/.local/share/lxtask-exp/install/
└── usr
    ├── bin
    │   └── lxtask
    └── share
        ├── applications
        ├── doc
        ├── locale
        └── man

La commande :

$ /home/toto/.local/share/lxtask-exp/install/usr/bin/lxtask

lance correctement la version "stretch" de lxtask


Enfin, je suppose que les paquets des éventuelles dépendances non-couvertes par le système installé
devraient être également téléchargés manuellement et placés avec le paquet de l'application principale,
afin que tous les fichiers soient extraits par : dpkg-deb -x ../*.deb
et placés dans : .../mon_app/install/...


Y-a-t-il un risque de casse du système à agir de la sorte ?


PS: J'ai relu l'excellent FrankenDebian de Grhim
mais ce point n'y est pas abordé.


Merci.

[piratebab]

Déjà, tu utilises la gestion des paquets Debian ce qui est un très bon point. Cela permet de bien gérer ce qui est installé.
Tu profites aussi de la gestion des dépendances. Si le logiciel que tu installes à besoin d’une dépendance plus récente que celle installée sur le système, il va forcément t’en informer.
À toi de faire en sorte qu’il la trouve (généralement via le pinning).
Le gestionnaire de paquet va normalement t’avertir si cette dépendance plus récente est en conflit avec un autre logiciel installé.
Tant que ce sont des dépendances non système, tu as peu de risque. S’il te demande d’installer une libc plus récente, il faut par contre y réfléchir à 2 fois.
Ce n’est que mon opinion basée sur mes expériences, et mes erreurs!

[dezix]

Merci, c'est bien rassurant.

... après réflexion, il ne devrait pas être permis à un utilisateur configurer par défaut (adduser toto) de mettre l'installation en péril.

Au pire toto casse sa session utilisateur et ne parvient plus à se connecter au système,
c'est la peine maximum ou je me trompe ?

[piratebab]

si on n'a pas fait n'importe quoi avec l'utilisation de sudo, c'est la base de POSIX: la séparation des droits

[dezix]

Merci, pour ta patience.

Mais comme tu le sais bien,
le passage d'utilisateur-admin de sa station de travail personnelle où on fait toutes les conneries soi-même,
à l'administration d'un système multi-utilisateurs (pour de vrai) change complètement le point de vue.

Ça demande de nouveaux réflexes et un approfondissement des connaissances de bases.

[piratebab]

Perso je me refuse à cette déviation de l'utilisation de sudo. Je reste fidèle à la stratégie de séparation des droits entre l'administrateur et l'utilisateur.. Je connais mes limites et mes failles.
J'ai un prompt différent pour les 2 utilisateurs afin de ne pas me tromper (la différence entre $ et # n'est pas suffisamment visible).
Stratégie KISS!