Path: ...!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Thomas Newsgroups: fr.comp.os.unix Subject: Re: installation des images Date: Mon, 15 May 2023 02:33:01 +0200 Organization: A noiseless patient Spider Lines: 147 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-Info: dont-email.me; posting-host="8bfb1a3cfda7c6013bd766fd84811b08"; logging-data="2922059"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18MoxV4E7JCT4aIRYnJj/4LvPfhTvoCJ3w=" User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Cancel-Lock: sha1:mjxLTLq33vAHOlbsNXsXY5ToTaM= Mail-Copies-To: nobody Bytes: 6503 In article , Marc SCHAEFER wrote: > 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. (ç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)// ? > > 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// 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// (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/