Path: ...!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas <fantome.forums.tDeContes@free.fr.invalid>
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: <fantome.forums.tDeContes-28DBD3.02330115052023@news.eternal-september.org>
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> <tgpp4g$t37$2@shakotay.alphanet.ch> <fantome.forums.tDeContes-0FC775.15183122042023@news.eternal-september.org> <u20op0$7f9$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-555539.19351622042023@news.eternal-september.org> <u235tl$avp$1@shakotay.alphanet.ch>
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 <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/