Un gestionnaire de packages doit-il modifier votre fichier .bashrc?

9

J'écris un package pour quelque chose qui nécessite qu'une variable d'environnement soit définie pour s'exécuter correctement. L'étape d'installation d'un gestionnaire de packages doit-elle modifier l'environnement d'un utilisateur ou simplement inviter l'utilisateur à le faire lui-même? Mon intuition serait la seconde, mais je peux voir des arguments pour la première.

installer environment package-managers

— David Cowden
source

7

Pouvez-vous faire en sorte que quelque chose se comporte mieux, en supprimant la dépendance à la variable d'environnement (par exemple, en utilisant un fichier de configuration à la place)? Ce serait préférable à l'emballage de hacks ou de nettoyage avec .bashrc, je pense.

Bien sûr, mais disons aux fins de cette question que la modification de l'application n'est pas une option.

— David Cowden

1

Et si l'utilisateur n'est pas en cours d'exécution bash? Il existe de nombreux shells alternatifs disponibles avec une grande variété de fichiers de démarrage. Je suggère sérieusement de trouver une autre solution ici.

— Jules

10

Donc, écrivez un wrapper autour de lui. Voir, par exemple, tomcatqui a besoin de plusieurs variables d'environnement pour fonctionner correctement; ils sont tous définis par un script de démarrage qui est exécuté au lieu d'exécuter directement son binaire.

— Jules

1

@Vality je sais. La proposition de Jules a déjà été suggérée. Je suis facétieux - je me moque de la logique circulaire impliquée pour dire d'abord que je devrais avoir une solution shell agnostique, puis je suggère d'utiliser un script shell comme solution. C'est une blague (;

— David Cowden

18

L'étape d'installation d'un gestionnaire de packages doit-elle modifier l'environnement d'un utilisateur ou simplement inviter l'utilisateur à le faire lui-même?

Ni. Les installateurs de packages ne doivent jamais toucher quoi que ce soit dans un répertoire personnel pour un compte que le package ne possède pas. Les packages doivent également se configurer de sorte que s'ils sont installés, ils soient utilisables sans effort particulier de la part de l'utilisateur. (Il y a des cas exceptionnels où vous ne voulez pas faire cela, mais ils sont rares.)

Les environnements Unixy ont une place pour mettre des fichiers de configuration qui sont lus chaque fois qu'un utilisateur démarre un shell de connexion. Pour les shells Bourne et C, vous pouvez insérer votre configuration dans /etc/profileet /etc/csh.cshrcrespectivement. (N'oubliez pas de le supprimer lors de la désinstallation.)

De nombreux systèmes prennent également en charge cette opération à l'aide de fichiers individuels, ce qui facilite l'ajout et la suppression de bits de configuration sans avoir à déposer du texte à un endroit arbitraire dans un fichier. (Il vous offre également tous les avantages de contrôle et de responsabilité que vous obtenez d'un gestionnaire de packages.) Certaines distributions configurent la /etc/profilelecture de tous les fichiers correspondants /etc/profile.d/*.sh.

— Blrfl
source

1

Historiquement, rcdans un script, le nom dérive de CTSSruncom (Run Commands), mais a depuis élargi sa portée pour inclure d'autres significations.

— Jeffrey Hantin

1

@JeffreyHantin: Touché. Supprimé.

— Blrfl

1

Déteste continuer à cueillir, mais profile.dn'est pas intégré à bash, c'est un crochet généralement fourni par (généralement la base de la distribution) /etc/profile. ;)

— Jeffrey Hantin

1

@JeffreyHantin: C'est vrai, bien qu'il n'y aura pas de critique de mon utilisation du mot "Unixy". :-)

— Blrfl

14

Il n'est jamais acceptable de modifier la /homestructure d' un utilisateur à partir du gestionnaire de packages, sauf si cette modification est le point entier.

Les principales approches en la matière sont les suivantes:

Informez l'utilisateur dont il a besoin pour le configurer.
Les valeurs par défaut de l'approvisionnement ne sont donc pas nécessaires
Empaqueter un script de lancement qui définit les valeurs de manière appropriée
(Si la distribution le prend en charge) Déposez un fichier exportant la variable d'environnement à l'intérieur /etc/profile.d. Sur certains systèmes Linux, tous les scripts de ce répertoire proviennent de la configuration par défaut du shell, vous pouvez donc y définir la variable en toute sécurité.

— Daenyth
source

7

Question L'étape d'installation d'un gestionnaire de packages doit-elle modifier l'environnement d'un utilisateur?

Réponse Non. C'est une mauvaise idée de modifier les données d'un utilisateur, dans ce cas le fichier .bashrc. Les données de l'utilisateur doivent être considérées comme sacrées par un gestionnaire de paquets?

Question L'étape d'installation d'un gestionnaire de packages doit-elle simplement inviter l'utilisateur à le faire lui-même?

Réponse C'est une solution beaucoup plus agréable au goût mais pas toujours idéale.

Je pense que vous devriez créer un script shell wrapper où vous pouvez définir les variables d'environnement nécessaires et les exécuter après cela.

— R Sahu
source

J'ai aussi pensé à cette idée. Le projet est jeune et arrivera au point où cela ne devrait pas être nécessaire.

— David Cowden

@ GlenH7 J'ai mis à jour ma réponse. Si tout va bien la réponse mise à jour est plus de réponse que vous recherchez.

— R Sahu

@ GlenH7: Cette question est essentiellement un problème XY: meta.stackexchange.com/questions/66377/what-is-the-xy-problem , où le besoin de variables d'environnement est le vrai problème à résoudre.

— whatsisname

De plus, la suggestion de cette réponse de créer un script wrapper est la seule réponse qui fonctionnera pour tous les shells.

— whatsisname

1

@MattThomason que la réalisation est ce qui m'a poussé à poser la question (;

— David Cowden

5

Vous manquez la forêt pour les arbres. Évidemment, il est plus pratique d'effectuer le changement d'environnement pour l'utilisateur, mais c'est aussi plus risqué et quelque peu invasif. Vous devez combiner le meilleur des deux mondes en demandant à l'utilisateur si l'installateur doit modifier le leur .bashrc, et sinon donner des instructions sur la façon de le faire lui-même.

— Kilian Foth
source

Merci pour le conseil. Je n'ai jamais écrit de paquet public auparavant et je veux juste m'assurer de ne pas faire quelque chose de tabou.

— David Cowden

C'est ainsi que le SDK Google Cloud gère cela aujourd'hui. Il vous demande si vous souhaitez modifier vos fichiers de démarrage.

— jmq

1

Vous supposez que "utilisateur" est singulier. Que se passe-t-il si j'ai des milliers d'utilisateurs sur ce système?

Vous supposez que vous pouvez même trouver le répertoire personnel de l'utilisateur. Si les utilisateurs sont gérés par exemple par LDAP, il se peut que vous ne soyez même pas autorisé à obtenir une liste de tous les utilisateurs valides. Les répertoires personnels peuvent ne pas se trouver dans / home; ils peuvent être montés dynamiquement à partir du réseau. Le répertoire personnel de l'utilisateur peut être crypté et la clé inaccessible tant qu'il n'est pas connecté.

Il n'y a aucun moyen de le faire de manière fiable dans toutes les situations possibles. Utilisez le mécanisme de la distribution pour définir des variables d'environnement pour les utilisateurs lorsqu'ils se connectent ou génèrent des shells. Si cela ne fonctionne pas, écrivez un wrapper. (Le wrapper peut également être un binaire si nécessaire, pour traiter l'argument dans les commentaires).

— pjc50
source

0

La définition d'une variable globale dans un package est acceptable si elle est définie par votre propre projet (et cela signifie que le nom du projet fait partie du nom de la variable!). Même dans ce cas, vous ne devez pas toucher le .bashrcfichier de l'utilisateur - vous devez plutôt ajouter un script à /etc/profile.d .

— Idan Arye
source