Path: csiph.com!weretis.net!feeder8.news.weretis.net!news.imp.ch!news.alphanet.ch!alphanet.ch!.POSTED!not-for-mail From: Marc SCHAEFER Newsgroups: fr.comp.os.unix Subject: Re: installation des images Supersedes: Date: Sun, 23 Apr 2023 11:48:05 -0000 (UTC) Organization: Posted through news.alphanet.ch Message-ID: References: <63277cc2$0$31542$426a74cc@news.free.fr> <63278e42$0$5129$426a34cc@news.free.fr> <6327b5a2$0$25824$426a74cc@news.free.fr> <63284d46$0$22070$426a74cc@news.free.fr> <63287c19$0$22050$426a74cc@news.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 23 Apr 2023 11:48:05 -0000 (UTC) Injection-Info: shakotay.alphanet.ch; posting-account="schaefer"; logging-data="11257"; mail-complaints-to="usenet@alphanet.ch"; posting-host="634ce6c9682d817d72f6177875e2bb4f.nnrp.alphanet.ch" User-Agent: tin/2.4.3-20181224 ("Glen Mhor") (UNIX) (Linux/4.19.0-23-amd64 (x86_64)) Cancel-Key: sha256:FOelP1vG+TZLMfu7tb6b7C0tLJYxRer8ZsrnE2x1bkE= Cancel-Lock: sha256:tyHwwuJI3TFxqRy8YaBrxBtSGm5syqZTs8WV4bSjOgc= sha256:8wlnsX42ZDh5ULuCIukBW7rmp7xpnN7PJYjT5UqyztA= Xref: csiph.com fr.comp.os.unix:8068 On Sat, 22 Apr 2023 19:35:17, Thomas 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. Ce sont finalement les distributions Linux qui, grâce à la configurabilité à la compilation des applications, rendent le tout relativement uniforme. > 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. > 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, et il me semble qu'un navigateur lancé localement peut facilement suivre les URLs de type file: 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. Ainsi, pour l'exporter par web, une seule configuration Apache2 serait nécessaire. > 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: - par défaut les images utilisées par l'application sont sous la macro C (ou de ton langage préféré) HTML_IMAGES - à la compilation, HTML_IMAGES est remplacé par /usr/share/APPLICATION/html/images, sauf si l'utilisateur a configuré la compilation de l'application autrement (exemple: ./configure --html-images=...) Tout est donc statiquement défini à la compilation. On peut aussi compliquer / rendre plus dynamique: - un fichier de configuration centralisé de l'application donne l'emplacement des images, si non configuré, le défaut ci-dessus - une variable d'environnement, APPLICATION_HTML_IMAGES - etc 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. Quelque chose que j'aime bien dans les applications web c'est le "convention over configuration" -- tout en laissant possible la configurabilité, les défauts sont "usuels". Ca justifie aussi la 1ère stratégie dans le contexte d'un programme compilé depuis la source par l'intégrateur. > 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)// ? 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. -- Attention: limitez le nombre de lignes de citation à l'essentiel, sinon je ne verrai pas votre réponse. Et si vous écrivez souvent des bobards, je ne vous lirai plus et je recommanderai (NoCeM) de ne plus vous lire.