En pratique, tu ne fais que modifier à la volée des variables d'environnement via un mécanisme assez simple, une première commande génère un fichier temporaire puis tu source celui-ci dans le shell en cours. Pas besoin de dbus et autre subtilité pour faire cela donc le code doit être robuste avec une API simple.
Pourquoi un code stable devrait être moins rassurant ;-)
PS : L'approche module n'est pas parfaite car le unload n'est pas fiable à 100% mais c'est un choix de faire simple. Surtout qu'on ne fait pas en pratique des load/unload toutes les 5min...
PPS : Il existe d'autres approches comme 'schroot' par exemple. Chaque approche a des avantages et des inconvénients.
[^] # Re: modules
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Red Hat Software Collections 2.1. Évalué à 2.
En pratique, tu ne fais que modifier à la volée des variables d'environnement via un mécanisme assez simple, une première commande génère un fichier temporaire puis tu source celui-ci dans le shell en cours. Pas besoin de dbus et autre subtilité pour faire cela donc le code doit être robuste avec une API simple.
Pourquoi un code stable devrait être moins rassurant ;-)
PS : L'approche module n'est pas parfaite car le unload n'est pas fiable à 100% mais c'est un choix de faire simple. Surtout qu'on ne fait pas en pratique des load/unload toutes les 5min...
PPS : Il existe d'autres approches comme 'schroot' par exemple. Chaque approche a des avantages et des inconvénients.