Re: installation des images

Liste des GroupesRevenir à fco unix 
Sujet : Re: installation des images
De : fantome.forums.tDeContes (at) *nospam* free.fr.invalid (Thomas)
Groupes : fr.comp.os.unix
Date : 15. May 2023, 02:33:01
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <fantome.forums.tDeContes-28DBD3.02330115052023@news.eternal-september.org>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
In article <u235tl$avp$1@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

On Sat, 22 Apr 2023 19:35:17, Thomas
<fantome.forums.tDeContes@free.fr.invalid> wrote:
Soit le file hierarchy standard (qui est un peu moribond)
 
dans quel sens ?
 
Déjà, c'est un standard des distributions Linux et pas de tous les UNIX.
 
Ensuite, j'ai l'impression -- mais ce n'est qu'une impression -- qu'il
n'évalue pas beaucoup.
 

Aussi, beaucoup de logiciels commerciaux mettent tout dans
/opt/NOM-APPLICATION sans respecter de structure claire.

(ça me rappelle qqch d'avoir vu une recommandation pour ranger les
choses comme ça, mais je ne me rappelle plus où.)

 
Ce sont finalement les distributions Linux qui, grâce à la
configurabilité à la compilation des applications, rendent le tout
relativement uniforme.

j'ai un logiciel d'installation automatique qui respecte cette
convention pour ce qu'il gère automatiquement, et on peut lui demander
d'ajouter des trucs en plus qu'il ne gère pas, juste il copie ce qu'on
lui demande comme cp.
ça me parait logique de continuer à suivre cette convention pour ce
qu'on ajoute.

 
dans ce cas il me semble préférable de nous entendre pour être les plus
nombreux possible à le suivre.
 
Oui, dans la mesure où c'est possible: typiquement, je n'ai pas trouvé
de référence à images ou img (mais je n'ai pas cherché beaucoup).
 
pour le répertoire de construction, on m'a appris qu'il est bon
d'utiliser des noms comme "src" "obj" "lib" bin" ... qui semblent tous
être des diminutifs.
 
Je prends ça comme une recommandation très forte pour les noms figurant
dans le FHS, oui.

du coup ça me parait logique de rester dans la continuité en gardant les
diminutifs pour les nouveaux.
(je n'ai pas trouvé "obj" non plus ;-) )

mais je comprend tout à fait que, à lire, tu préfères les versions
longues :-)


 
je me suis aperçu récemment que mon dossier img est probablement un
doublon des images que je trouve dans la doc.
il me parait logique d'en supprimer 1 des 2 AQP.
 
Oui,

merci :-)

et il me semble qu'un navigateur lancé localement peut facilement
suivre les URLs de type file:

(je ne m'encombre pas avec "file:" : dans ma config le plus adapté c'est
les liens relatifs, qui ont tous les avantages.)

 
Pour l'accès distant, je recommanderais alors
/usr/share/nom-application/html avec dessous si tu veux images/
css/ javascript/ et tout ce qui t'aide à structurer ta documentation.

c'est pas comme ça pour l'instant, mais j'ai bien l'intention de ranger
de cette façon des que j'aurai repris la doc en main.

Ainsi, pour l'exporter par web, une seule configuration Apache2
serait nécessaire.

(je n'envisage pas d'installer un serveur web sur une machine,
ni de préparer un `make install` dans ce but.)


 
est-ce que ça convient d'utiliser les images de la doc par l'exécutable,
ou est-ce qu'il y a des inconvénients ?
 
Une stratégie pourrait être:

...

Tout est donc statiquement défini à la compilation.
 
On peut aussi compliquer / rendre plus dynamique:

...

 
Mais vu qu'en général, l'intégrateur qui compile le logiciel est aussi
celui qui sait le meilleur endroit pour mettre les documentations,
la 1ère stratége me semble bonne.

en fait on avait parlé de ça dans le fil sur les logs, et je t'en
remercie, j'ai l'intention d'en implementer des morceaux. :-)
mais ici, la question est seulement celle de l'emplacement choisi par le
`make install`.


par ex est-ce qu'il y a un risque que $(datarootdir)/doc soit modifié
sans prévenir (par l'administration du système ou autre processus
externe), qu'il n'y aurait pas avec $(datadir)/<package-name>/ ?
 
La voie d'un répertoire par application évite effectivement des
problèmes, et la centralisation de toutes les images à un endroit pour
toutes les applications n'a de sens que si ces images peuvent être
utilisées spécifiquement, ce qui ne semble pas le cas ici.

dans le vieux msg, je me referais à :
https://www.gnu.org/software/make/manual/html_node/Directory-Variables
et je disais que pour la doc le chemin est :

$(datarootdir)/doc/<package-name>/

d'ailleurs, c'est noté dans le FHS, précisément sur la page que tu m'as
indiquée ("/usr/share/doc").

j'imagine que c'est pour que les usagers puissent trouver toutes les
docs au même endroit, sans que ça soit mélangé avec d'autres sortes de
fichiers.

est-ce que tu penses que finalement c'est mieux de ne pas s'en servir et
de tout mettre dans/usr/share/<package-name>/ (par commodité ou
sécurité) ?
il n'y a pas de risque de déranger d'une autre manière, à ne pas
utiliser /usr/share/doc alors qu'il est prévu ?



je devine que tu n'a pas accès au vieux msg.
est-ce que tu m'autorise à recopier ici les autres questions, pour que
tu puisses y répondre si tu le souhaites ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Date Sujet#  Auteur
18 Sep 22 * installation des images13Thomas
18 Sep 22 `* Re: installation des images12Nicolas George
19 Sep 22  `* Re: installation des images11Thomas
19 Sep 22   `* Re: installation des images10Nicolas George
19 Sep 22    `* Re: installation des images9Thomas
25 Sep 22     +* Re: installation des images7Jo Engo
22 Apr 23     i`* Re: installation des images6Thomas
22 Apr 23     i `* Re: installation des images5Marc SCHAEFER
22 Apr 23     i  `* Re: installation des images4Thomas
15 May 23     i   `* Re: installation des images3Thomas
4 Jun 23     i    `* Re: installation des images2Thomas
4 Jun 23     i     `- Re: installation des images1Marc SCHAEFER
23 Oct 22     `- Re: installation des images1Thomas

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal