Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.os.unix > #8023 > unrolled thread

installation des images

Back to article view | Back to fr.comp.os.unix

Contents

  installation des images Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-18 22:17 +0200
    Re: installation des images Nicolas George <nicolas$george@salle-s.org> - 2022-09-18 21:31 +0000
      Re: installation des images Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-19 02:19 +0200
        Re: installation des images Nicolas George <nicolas$george@salle-s.org> - 2022-09-19 11:06 +0000
          Re: installation des images Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-19 16:26 +0200
            Re: installation des images Jo Engo <yl@icite.fr> - 2022-09-25 14:38 +0000
              Re: installation des images Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-04-22 15:18 +0200
                Re: installation des images Marc SCHAEFER <schaefer@alphanet.ch> - 2023-04-22 13:51 +0000
                  Re: installation des images Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-04-22 19:35 +0200
                    Re: installation des images Marc SCHAEFER <schaefer@alphanet.ch> - 2023-04-23 11:45 +0000
                    Re: installation des images Marc SCHAEFER <schaefer@alphanet.ch> - 2023-04-23 11:48 +0000
                      Re: installation des images Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-05-15 02:33 +0200
                        Re: installation des images Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2023-06-04 17:29 +0200
                          Re: installation des images Marc SCHAEFER <schaefer@alphanet.ch> - 2023-06-04 18:22 +0000
            Re: installation des images Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-10-23 22:31 +0200

#8023 — installation des images

bonjour :-)


pour ceux qui ne le savent pas encore (ou qui auraient oublié),
je développe un logiciel (qui, entre autres, utilise des images).

- ma vie est bcp plus celle d'un développeur que celle d'un intégrateur.
- ce sont de simples icônes, il ne s'agit pas d'un logiciel de 
traitement d'images.


j'en suis à m'occuper de l'installation (cible "install").

je me demande si les images doivent être rangées à un endroit 
particulier.
pour l'instant je les ai mises dans "img", juste à coté de "bin".

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

[toc] | [next] | [standalone]

#8024

Thomas , dans le message <63277cc2$0$31542$426a74cc@news.free.fr>, a
 écrit :
> je me demande si les images doivent être rangées à un endroit 
> particulier.
> pour l'instant je les ai mises dans "img", juste à coté de "bin".

L'endroit standard serait $(PREFIX)/share/tonsoft/.

[toc] | [prev] | [next] | [standalone]

#8025

In article <63278e42$0$5129$426a34cc@news.free.fr>,
 Nicolas George <nicolas$george@salle-s.org> wrote:

> Thomas , dans le message <63277cc2$0$31542$426a74cc@news.free.fr>, a
>  écrit :
> > je me demande si les images doivent être rangées à un endroit 
> > particulier.
> > pour l'instant je les ai mises dans "img", juste à coté de "bin".
> 
> L'endroit standard serait $(PREFIX)/share/tonsoft/.

merci :-)

tiens, c'est $(PREFIX) pas $(prefix) ?
https://www.gnu.org/software/make/manual/html_node/Directory-Variables

$(PREFIX)/share/rapid/img/ ?


je vois qu'il m'a mis qques fichiers de config comme :
$(PREFIX)/share/gpr/rapid.gpr

est-ce que ça veut dire que $(PREFIX)/share/ est fait pour ranger toutes 
les données plus ou moins brutes qui n'ont pas de place ailleurs (avec 
"rapid" qqpart dans le chemin pour identifier le logiciel rattaché) ?


est-ce que c'est une bonne idée d'avoir un share/ aussi dans le 
répertoire de distribution ?
justement, je me posais la question du bon endroit pour ranger dans le 
répertoire de distribution les images ainsi que divers fichiers de 
config.

(par exemple mes Makefiles (pas le principal mais toutes les 
"dépendances") je pourrais les ranger dans share/config/ ou share/mk/ ?)

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

[toc] | [prev] | [next] | [standalone]

#8026

Thomas , dans le message <6327b5a2$0$25824$426a74cc@news.free.fr>, a
 écrit :
> est-ce que ça veut dire que $(PREFIX)/share/ est fait pour ranger toutes 
> les données plus ou moins brutes qui n'ont pas de place ailleurs (avec 
> "rapid" qqpart dans le chemin pour identifier le logiciel rattaché) ?

https://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

[toc] | [prev] | [next] | [standalone]

#8027

In article <63284d46$0$22070$426a74cc@news.free.fr>,
 Nicolas George <nicolas$george@salle-s.org> wrote:

> Thomas , dans le message <6327b5a2$0$25824$426a74cc@news.free.fr>, a
>  écrit :
> > est-ce que ça veut dire que $(PREFIX)/share/ est fait pour ranger toutes 
> > les données plus ou moins brutes qui n'ont pas de place ailleurs (avec 
> > "rapid" qqpart dans le chemin pour identifier le logiciel rattaché) ?
> 
> https://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

merci :-)


si je comprend bien, ça serais plutôt $(PREFIX)/share/doc/rapid/ pour la 
doc,

donc pour les images est-ce que ça serais plutôt 
$(PREFIX)/share/img/rapid/ que $(PREFIX)/share/rapid/img/ ?

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

[toc] | [prev] | [next] | [standalone]

#8032

Le Mon, 19 Sep 2022 16:26:32 +0200, Thomas a écrit :

> $(PREFIX)/share/img/rapid/ que $(PREFIX)/share/rapid/img/ ?


$(PREFIX)/share/images/rapid/


-- 
Aimez donc la raison ; que toujours vos écrits
Empruntent d'elle seule et leur lustre et leur prix.
	-+- Nicolas Boileau, Art poétique -+-

[toc] | [prev] | [next] | [standalone]

#8064

salut :-)


désolé pour le délai, et surtout pour avoir écrit un msg après toi sans 
te répondre.
j'avais un mauvais serveur, qui mangeais qqes msgs, et c'est tombé sur 
le tiens.
désolé. :-)



In article <tgpp4g$t37$2@shakotay.alphanet.ch>, Jo Engo <yl@icite.fr> 
wrote:

> Le Mon, 19 Sep 2022 16:26:32 +0200, Thomas a écrit :
> 
> > $(PREFIX)/share/img/rapid/ que $(PREFIX)/share/rapid/img/ ?
> 
> 
> $(PREFIX)/share/images/rapid/


si j'ai bien suivi,
- Nicolas dit $(PREFIX)/share/rapid/* mais pas forcément 
$(PREFIX)/share/rapid/img/
- tu dis $(PREFIX)/share/images/rapid/ (mais pas 
$(PREFIX)/share/img/rapid/)

comment choisir ?
(pourquoi est-ce qu'on n'utilise pas le diminutif dans ta proposition ?)


pour le long terme, le mieux ça serais de pouvoir factoriser les images 
avec la doc.
est-ce que tu accepterais de répondre à cette partie de mon précédent 
msg stp ? :-)

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

[toc] | [prev] | [next] | [standalone]

#8065

On Sat, 22 Apr 2023 15:18:31, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
>> Le Mon, 19 Sep 2022 16:26:32 +0200, Thomas a écrit :

Archéologie :>

> comment choisir ?

Soit le file hierarchy standard (qui est un peu moribond) précise où
stocker les images[1], soit on fait ce qu'on veut. En regardant mon
système Debian, je vois qu'il y a

   - des applications qui posent leurs icônes dans un répertoire
     partagé par exemple pour que l'utilisateur puisse utiliser
     ces icônes ailleurs

   - des applications qui créent $(PREFIX)/share/NOM-DU-LOGICIEL puis
     une arborescence totalement privée dessous (avec ou sans
     sous-répertoires)

Si tes icônes ne servent qu'à ton logiciel, alors
$(PREFIX)/share/NOM-DU-LOGICIEL ou
$(PREFIX)/share/NOM-DU-LOGICIEL/images ou autre semble approprié.

> (pourquoi est-ce qu'on n'utilise pas le diminutif dans ta proposition ?)

Je ne vois pas trop l'intérêt d'appeler ce répertoire img plutôt
qu'images, comme j'aime bien appeler des fichiers JPEG toto.jpeg et pas
TOTO.JPG, mais c'est une question de préférence personnelle.
 
> pour le long terme, le mieux ça serais de pouvoir factoriser les images 
> avec la doc.

Factoriser, tu veux dire les mettre le plus près de la doc? Je ne
connais pas ce sens du mot "factoriser".

[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

-- 
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.

[toc] | [prev] | [next] | [standalone]

#8066

In article <u20op0$7f9$1@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

> > comment choisir ?
> 
> Soit le file hierarchy standard (qui est un peu moribond)

dans quel sens ?

est-ce qu'il est dépassé par de nouveaux besoins ?
dans ce cas il faut en envisager une nouvelle version.

ou est-ce qu'il y a simplement trop de devs qui ne l'ont pas suivi 
soigneusement sans nécessité réelle ?
dans ce cas il me semble préférable de nous entendre pour être les plus 
nombreux possible à le suivre.
à moins qu'il y ait une très bonne raison de ne pas le faire
(ça peut exister, et ça peut être politique plutôt que pour un besoin 
particulier).


> précise où
> stocker les images[1], soit on fait ce qu'on veut. En regardant mon
> système Debian, je vois qu'il y a

...

> Si tes icônes ne servent qu'à ton logiciel, alors
> $(PREFIX)/share/NOM-DU-LOGICIEL ou
> $(PREFIX)/share/NOM-DU-LOGICIEL/images ou autre semble approprié.

merci :-)

> [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

instructif, merci :-)

> 
> > (pourquoi est-ce qu'on n'utilise pas le diminutif dans ta proposition ?)
> 
> Je ne vois pas trop l'intérêt d'appeler ce répertoire img plutôt
> qu'images, comme j'aime bien appeler des fichiers JPEG toto.jpeg et pas
> TOTO.JPG, mais c'est une question de préférence personnelle.

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.



>  
> > pour le long terme, le mieux ça serais de pouvoir factoriser les images 
> > avec la doc.
> 
> Factoriser, tu veux dire les mettre le plus près de la doc? Je ne
> connais pas ce sens du mot "factoriser".

voilà le précédent msg : <6355a4b1$0$2996$426a74cc@news.free.fr>

et comme c'est à nouveau de l'Archéologie :> je devine que tu peux avoir 
du mal à y accéder, alors je copie la partie sur les images de la doc :



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.

les fichiers html utilisent les images de la doc, et je n'imagine pas 
pouvoir les modifier à la volée au moment de l'installation (tandis que 
j'imagine pouvoir le faire avec l'exécutable).

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 ?
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>/ ?

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

[toc] | [prev] | [next] | [standalone]

#8067

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.

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:

   - parfaut 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é
     /usr/share/APPLICATION/html/images, sauf si l'utilisateur
     a configuré la compilation de l'application autrement
     (exemple: ./configure --html-images=...)

On peut aussi compliquer:

   - 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.

> 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.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#8068

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.

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)/<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.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#8082

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/

[toc] | [prev] | [next] | [standalone]

#8099

salut :-)

vu ta signature, je me dis que tu as peut-être été gavé des réponses 
entre parenthèses (ce qui signifie "je te le met là juste pour ton 
information"),
alors je te remet juste ce qui est important pour moi.


In article 
<fantome.forums.tDeContes-28DBD3.02330115052023@news.eternal-september.o
rg>,
 Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> 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:


> ici, la question est 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 ?


voilà : si je t'ai bien compris, tu m'as dit 2 choses contradictoires :
- suivre autant que possible les recommandations du FHS
- tout mettre dans /usr/share/<package-name>/, sans utiliser 
/usr/share/doc.

peux-tu préciser ta pensée stp ?


> 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/

[toc] | [prev] | [next] | [standalone]

#8103

On Sun, 04 Jun 2023 17:29:47, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> voilà : si je t'ai bien compris, tu m'as dit 2 choses contradictoires :
> - suivre autant que possible les recommandations du FHS
> - tout mettre dans /usr/share/<package-name>/, sans utiliser 
> /usr/share/doc.

Ce sont les deux approches qui me semblent pertinentes: soit découper
selon le FHS, soit tout mettre au même endroit.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#8044

In article <63287c19$0$22050$426a74cc@news.free.fr>,
 Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> In article <63284d46$0$22070$426a74cc@news.free.fr>,
>  Nicolas George <nicolas$george@salle-s.org> wrote:
> 
> > Thomas , dans le message <6327b5a2$0$25824$426a74cc@news.free.fr>, a
> >  écrit :
> > > est-ce que ça veut dire que $(PREFIX)/share/ est fait pour ranger toutes 
> > > les données plus ou moins brutes qui n'ont pas de place ailleurs (avec 
> > > "rapid" qqpart dans le chemin pour identifier le logiciel rattaché) ?


désolé, je n'avais relu que le paragraphe "prefix" dans 
https://www.gnu.org/software/make/manual/html_node/Directory-Variables 
pas les autres.

si je comprend bien cette fois ci:


> > https://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> 
> merci :-)
> 
> 
> si je comprend bien, ça serais plutôt $(PREFIX)/share/doc/rapid/ pour la 
> doc,

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

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.

> 
> donc pour les images est-ce que ça serais plutôt 
> $(PREFIX)/share/img/rapid/ que $(PREFIX)/share/rapid/img/ ?

$(datadir)/<package-name>/img/

j'imagine qu'on a trouvé plus intéressant de regrouper par package tout 
ce qui ne devait pas être à un endroit predefini.

dommage que datadir ne soit pas un sous-répertoire de datarootdir, ça 
aurais évité de mélanger les <package-name> avec les sous-répertoires 
predefinis.



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.

les fichiers html utilisent les images de la doc, et je n'imagine pas 
pouvoir les modifier à la volée au moment de l'installation (tandis que 
j'imagine pouvoir le faire avec l'exécutable).

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 ?
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>/ ?



y a-t-il une place pour le fichier qui contient le n° de version de la 
distribution ?

$(sysconfdir)/<package-name>/ (cad $(prefix)/etc/<package-name>/ ), 
c'est bien ?



j'imagine que la doc Markdown va avec le reste de la doc.

est-ce que les exemples vont ici aussi ?



question connexe :

j'ai un vieux script dont je ne sais pas quoi faire (en attendant de 
décider si je le met à jour ou si je le jette).

est-ce que ça va obligatoirement dans $(bindir) ?
ou est-ce qu'on peut lui trouver une place dans $(datadir), 
en considérant qu'en tant que script, c'est de la donnée 
"read-only architecture-independent" ?

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

[toc] | [prev] | [standalone]

Back to top | Article view | fr.comp.os.unix

csiph-web