Mais il me reste un petit soucis sur le ebuild (ci-joint), avec
le install et le dodoc... Le install par défaut de xcave
installe la doc et des cochonneries dans /usr/share/doc/xcave
Mais il me reste un petit soucis sur le ebuild (ci-joint), avec
le install et le dodoc... Le install par défaut de xcave
installe la doc et des cochonneries dans /usr/share/doc/xcave
Mais il me reste un petit soucis sur le ebuild (ci-joint), avec
le install et le dodoc... Le install par défaut de xcave
installe la doc et des cochonneries dans /usr/share/doc/xcave
> le install et le dodoc... Le install par défaut de xcave
> installe la doc et des cochonneries dans /usr/share/doc/xcave
Pour éviter ça, tu peux patcher le Makefile.in. Je te mets en
Tant que j'y étais, j'ai modifié 2 ou 3 autres petites choses:
- y'a pas de dépendance sur gnome-libs, c'est juste du gtk2.
Toujours à propos de dépendances, il toujours faut définir à la
fois DEPEND et RDEPEND, même si ils sont identiques (c'est fait
automatiquement si il en manque un, mais dans qlqs temps ça ne
sera plus le cas).
- même avec USE=nls, y'a pas besoin de gettext je pense (les
.gmo sont déjà compilés).
la catégorie "Autres" ou assimilé (mais si tu veux en rajouter
une, tu peux regarder la liste ici:
http://standards.freedesktop.org/menu-spec/latest/apa.html
et tu rajoutes un argument à l'appel à make_desktop_entry.
Voilà voilà, c'est des petites choses, mais toujours bonnes à
savoir quand on commence à bricoler des ebuilds...
> le install et le dodoc... Le install par défaut de xcave
> installe la doc et des cochonneries dans /usr/share/doc/xcave
Pour éviter ça, tu peux patcher le Makefile.in. Je te mets en
Tant que j'y étais, j'ai modifié 2 ou 3 autres petites choses:
- y'a pas de dépendance sur gnome-libs, c'est juste du gtk2.
Toujours à propos de dépendances, il toujours faut définir à la
fois DEPEND et RDEPEND, même si ils sont identiques (c'est fait
automatiquement si il en manque un, mais dans qlqs temps ça ne
sera plus le cas).
- même avec USE=nls, y'a pas besoin de gettext je pense (les
.gmo sont déjà compilés).
la catégorie "Autres" ou assimilé (mais si tu veux en rajouter
une, tu peux regarder la liste ici:
http://standards.freedesktop.org/menu-spec/latest/apa.html
et tu rajoutes un argument à l'appel à make_desktop_entry.
Voilà voilà, c'est des petites choses, mais toujours bonnes à
savoir quand on commence à bricoler des ebuilds...
> le install et le dodoc... Le install par défaut de xcave
> installe la doc et des cochonneries dans /usr/share/doc/xcave
Pour éviter ça, tu peux patcher le Makefile.in. Je te mets en
Tant que j'y étais, j'ai modifié 2 ou 3 autres petites choses:
- y'a pas de dépendance sur gnome-libs, c'est juste du gtk2.
Toujours à propos de dépendances, il toujours faut définir à la
fois DEPEND et RDEPEND, même si ils sont identiques (c'est fait
automatiquement si il en manque un, mais dans qlqs temps ça ne
sera plus le cas).
- même avec USE=nls, y'a pas besoin de gettext je pense (les
.gmo sont déjà compilés).
la catégorie "Autres" ou assimilé (mais si tu veux en rajouter
une, tu peux regarder la liste ici:
http://standards.freedesktop.org/menu-spec/latest/apa.html
et tu rajoutes un argument à l'appel à make_desktop_entry.
Voilà voilà, c'est des petites choses, mais toujours bonnes à
savoir quand on commence à bricoler des ebuilds...
Je voulais éviter ça, mais effectivement, je vois mal comment
m'y prendre autrement. Mfbon.
"You only need to explicitly specify RDEPEND if the ebuild's
runtime dependencies are different than what you specified in
DEPEND; if not specified, RDEPEND will default to your DEPEND
settings."
(en même temps, ils devraient quasiment tous dépendre de
virtual/libc, à part ceux compilés en statique...)
Hmm... Bonne question. Pas l'impression qu'il y ait de politique
officielle là-dessus... La plupart des logiciels ont gettext en
dep quand ils ont nls. Un deuxième avis ?
GTK Application based on GTK+ libraries
A tout hasard, ya pas un outil permettant de vérifier un
ebuild, y compris la conformité (SLOT, etc), comme sous freebsd
avec portlint ?
Je voulais éviter ça, mais effectivement, je vois mal comment
m'y prendre autrement. Mfbon.
"You only need to explicitly specify RDEPEND if the ebuild's
runtime dependencies are different than what you specified in
DEPEND; if not specified, RDEPEND will default to your DEPEND
settings."
(en même temps, ils devraient quasiment tous dépendre de
virtual/libc, à part ceux compilés en statique...)
Hmm... Bonne question. Pas l'impression qu'il y ait de politique
officielle là-dessus... La plupart des logiciels ont gettext en
dep quand ils ont nls. Un deuxième avis ?
GTK Application based on GTK+ libraries
A tout hasard, ya pas un outil permettant de vérifier un
ebuild, y compris la conformité (SLOT, etc), comme sous freebsd
avec portlint ?
Je voulais éviter ça, mais effectivement, je vois mal comment
m'y prendre autrement. Mfbon.
"You only need to explicitly specify RDEPEND if the ebuild's
runtime dependencies are different than what you specified in
DEPEND; if not specified, RDEPEND will default to your DEPEND
settings."
(en même temps, ils devraient quasiment tous dépendre de
virtual/libc, à part ceux compilés en statique...)
Hmm... Bonne question. Pas l'impression qu'il y ait de politique
officielle là-dessus... La plupart des logiciels ont gettext en
dep quand ils ont nls. Un deuxième avis ?
GTK Application based on GTK+ libraries
A tout hasard, ya pas un outil permettant de vérifier un
ebuild, y compris la conformité (SLOT, etc), comme sous freebsd
avec portlint ?
> Je voulais éviter ça, mais effectivement, je vois mal comment
> m'y prendre autrement. Mfbon.
Bah là franchement, pour éviter ça je vois pas trop.
Certains mainteneurs préféreront un patch que du sed par contre
Mais sinon, sans modifier de fichier Makefile, la seule
solution que je vois serait de nettoyer ${D} après le "make
install", mais ça serait franchement goret.
> DEPEND; if not specified, RDEPEND will default to your DEPEND
> settings."
Ça a été la politique, mais elle est en train de changer. Dans
des ebuilds qui en tiennent compte dès maintenant. La décision
n'étant vieille que de qlqs jours, ça explique je suppose que la
doc n'ait pas encore été modifiée.
> (en même temps, ils devraient quasiment tous dépendre de
> virtual/libc, à part ceux compilés en statique...)
Et de gcc, et de tant d'autres choses...
> officielle là-dessus... La plupart des logiciels ont gettext
> en dep quand ils ont nls. Un deuxième avis ?
Ouaif, tu fais bien de poser la question, parce que je suis pas
100% sûr de mon coup en fait. C'est certain que sur les
sytème à base de glibc, si elle est compilée avec USE=nls en tout
cas, y'en n'a pas besoin, sauf quand tu as des fichiers de
trad à compiler (mais c'est bien souvent le cas qu'ils soient
déjà compilés, comme ici).
Maintenant, avec une autre libc (genre
sur bsd ou macos peut-être),
ou si la glibc n'a pas USE=nls, alors j'en sais rien, peut-être
qu'il faut une libintl.so dans ce cas. À vérifier avec des gens
+ compétents...
ne comprend vraiment, et là je ne serais vraiment pas étonné si
le fin mot de l'histoire était que la dep est souvent ajoutée
juste parce que les scripts ./configure en vérifient la présence
et que donc ça doit servir à qqch :)
> GTK Application based on GTK+ libraries
Ouais, pourquoi pas. Ça va sûrement pas beaucoup aider à mieux
le ranger dans le menu gnome, mais bon vu que je vois pas trop
où ça pourrait aller de toute façon...
Y'a "repoman". Il doit être installer avec portage il me semble,
> Je voulais éviter ça, mais effectivement, je vois mal comment
> m'y prendre autrement. Mfbon.
Bah là franchement, pour éviter ça je vois pas trop.
Certains mainteneurs préféreront un patch que du sed par contre
Mais sinon, sans modifier de fichier Makefile, la seule
solution que je vois serait de nettoyer ${D} après le "make
install", mais ça serait franchement goret.
> DEPEND; if not specified, RDEPEND will default to your DEPEND
> settings."
Ça a été la politique, mais elle est en train de changer. Dans
des ebuilds qui en tiennent compte dès maintenant. La décision
n'étant vieille que de qlqs jours, ça explique je suppose que la
doc n'ait pas encore été modifiée.
> (en même temps, ils devraient quasiment tous dépendre de
> virtual/libc, à part ceux compilés en statique...)
Et de gcc, et de tant d'autres choses...
> officielle là-dessus... La plupart des logiciels ont gettext
> en dep quand ils ont nls. Un deuxième avis ?
Ouaif, tu fais bien de poser la question, parce que je suis pas
100% sûr de mon coup en fait. C'est certain que sur les
sytème à base de glibc, si elle est compilée avec USE=nls en tout
cas, y'en n'a pas besoin, sauf quand tu as des fichiers de
trad à compiler (mais c'est bien souvent le cas qu'ils soient
déjà compilés, comme ici).
Maintenant, avec une autre libc (genre
sur bsd ou macos peut-être),
ou si la glibc n'a pas USE=nls, alors j'en sais rien, peut-être
qu'il faut une libintl.so dans ce cas. À vérifier avec des gens
+ compétents...
ne comprend vraiment, et là je ne serais vraiment pas étonné si
le fin mot de l'histoire était que la dep est souvent ajoutée
juste parce que les scripts ./configure en vérifient la présence
et que donc ça doit servir à qqch :)
> GTK Application based on GTK+ libraries
Ouais, pourquoi pas. Ça va sûrement pas beaucoup aider à mieux
le ranger dans le menu gnome, mais bon vu que je vois pas trop
où ça pourrait aller de toute façon...
Y'a "repoman". Il doit être installer avec portage il me semble,
> Je voulais éviter ça, mais effectivement, je vois mal comment
> m'y prendre autrement. Mfbon.
Bah là franchement, pour éviter ça je vois pas trop.
Certains mainteneurs préféreront un patch que du sed par contre
Mais sinon, sans modifier de fichier Makefile, la seule
solution que je vois serait de nettoyer ${D} après le "make
install", mais ça serait franchement goret.
> DEPEND; if not specified, RDEPEND will default to your DEPEND
> settings."
Ça a été la politique, mais elle est en train de changer. Dans
des ebuilds qui en tiennent compte dès maintenant. La décision
n'étant vieille que de qlqs jours, ça explique je suppose que la
doc n'ait pas encore été modifiée.
> (en même temps, ils devraient quasiment tous dépendre de
> virtual/libc, à part ceux compilés en statique...)
Et de gcc, et de tant d'autres choses...
> officielle là-dessus... La plupart des logiciels ont gettext
> en dep quand ils ont nls. Un deuxième avis ?
Ouaif, tu fais bien de poser la question, parce que je suis pas
100% sûr de mon coup en fait. C'est certain que sur les
sytème à base de glibc, si elle est compilée avec USE=nls en tout
cas, y'en n'a pas besoin, sauf quand tu as des fichiers de
trad à compiler (mais c'est bien souvent le cas qu'ils soient
déjà compilés, comme ici).
Maintenant, avec une autre libc (genre
sur bsd ou macos peut-être),
ou si la glibc n'a pas USE=nls, alors j'en sais rien, peut-être
qu'il faut une libintl.so dans ce cas. À vérifier avec des gens
+ compétents...
ne comprend vraiment, et là je ne serais vraiment pas étonné si
le fin mot de l'histoire était que la dep est souvent ajoutée
juste parce que les scripts ./configure en vérifient la présence
et que donc ça doit servir à qqch :)
> GTK Application based on GTK+ libraries
Ouais, pourquoi pas. Ça va sûrement pas beaucoup aider à mieux
le ranger dans le menu gnome, mais bon vu que je vois pas trop
où ça pourrait aller de toute façon...
Y'a "repoman". Il doit être installer avec portage il me semble,
Moi je veux bien, mais à la St-Thomas (hum, désolé), je veux un
pointeur vers la nouvelle proposition :)
> Et de gcc, et de tant d'autres choses...
pas en RDEPEND.
> ou si la glibc n'a pas USE=nls, alors j'en sais rien,
> peut-être qu'il faut une libintl.so dans ce cas. À vérifier
> avec des gens + compétents...
Oui. Ça se trouve où, ce genre de choses ? Déjà que j'ai pas
trouvé une seule liste dédiée à la discussion sur la
création/maintenance des ebuild...
D'ailleurs, l'icône de gnucash a disparue, personne ne saurait
pourquoi, voire comment la remettre ?
J'aimerais bien une réponse sur gettext avant de le reproposer
sur bugs, ceci dit.
Moi je veux bien, mais à la St-Thomas (hum, désolé), je veux un
pointeur vers la nouvelle proposition :)
> Et de gcc, et de tant d'autres choses...
pas en RDEPEND.
> ou si la glibc n'a pas USE=nls, alors j'en sais rien,
> peut-être qu'il faut une libintl.so dans ce cas. À vérifier
> avec des gens + compétents...
Oui. Ça se trouve où, ce genre de choses ? Déjà que j'ai pas
trouvé une seule liste dédiée à la discussion sur la
création/maintenance des ebuild...
D'ailleurs, l'icône de gnucash a disparue, personne ne saurait
pourquoi, voire comment la remettre ?
J'aimerais bien une réponse sur gettext avant de le reproposer
sur bugs, ceci dit.
Moi je veux bien, mais à la St-Thomas (hum, désolé), je veux un
pointeur vers la nouvelle proposition :)
> Et de gcc, et de tant d'autres choses...
pas en RDEPEND.
> ou si la glibc n'a pas USE=nls, alors j'en sais rien,
> peut-être qu'il faut une libintl.so dans ce cas. À vérifier
> avec des gens + compétents...
Oui. Ça se trouve où, ce genre de choses ? Déjà que j'ai pas
trouvé une seule liste dédiée à la discussion sur la
création/maintenance des ebuild...
D'ailleurs, l'icône de gnucash a disparue, personne ne saurait
pourquoi, voire comment la remettre ?
J'aimerais bien une réponse sur gettext avant de le reproposer
sur bugs, ceci dit.
> trouvé une seule liste dédiée à la discussion sur la
> création/maintenance des ebuild...
Sur gentoo-dev@, les questions sur l'écriture d'ebuilds sont
correctement accueillies quand elles ne trouvent effectivement
pas de réponse dans la doc ou le simple bon sens. Là je pense
que c'est le cas.
> D'ailleurs, l'icône de gnucash a disparue, personne ne saurait
> pourquoi, voire comment la remettre ?
Regarde ce que raconte, un :
# equery files gnucash | grep '.desktop'
> J'aimerais bien une réponse sur gettext avant de le reproposer
> sur bugs, ceci dit.
Une solution serait de proposer ton ebuild en précisant que sur
ce point tu as un doute, et puis tu verras bien ce que la
personne qui s'en occupera décidera. Mais bon, le post sur
gentoo-dev@ lui aurait l'avantage d'avoir éventuellement
plusieurs réponses.
> trouvé une seule liste dédiée à la discussion sur la
> création/maintenance des ebuild...
Sur gentoo-dev@, les questions sur l'écriture d'ebuilds sont
correctement accueillies quand elles ne trouvent effectivement
pas de réponse dans la doc ou le simple bon sens. Là je pense
que c'est le cas.
> D'ailleurs, l'icône de gnucash a disparue, personne ne saurait
> pourquoi, voire comment la remettre ?
Regarde ce que raconte, un :
# equery files gnucash | grep '.desktop'
> J'aimerais bien une réponse sur gettext avant de le reproposer
> sur bugs, ceci dit.
Une solution serait de proposer ton ebuild en précisant que sur
ce point tu as un doute, et puis tu verras bien ce que la
personne qui s'en occupera décidera. Mais bon, le post sur
gentoo-dev@ lui aurait l'avantage d'avoir éventuellement
plusieurs réponses.
> trouvé une seule liste dédiée à la discussion sur la
> création/maintenance des ebuild...
Sur gentoo-dev@, les questions sur l'écriture d'ebuilds sont
correctement accueillies quand elles ne trouvent effectivement
pas de réponse dans la doc ou le simple bon sens. Là je pense
que c'est le cas.
> D'ailleurs, l'icône de gnucash a disparue, personne ne saurait
> pourquoi, voire comment la remettre ?
Regarde ce que raconte, un :
# equery files gnucash | grep '.desktop'
> J'aimerais bien une réponse sur gettext avant de le reproposer
> sur bugs, ceci dit.
Une solution serait de proposer ton ebuild en précisant que sur
ce point tu as un doute, et puis tu verras bien ce que la
personne qui s'en occupera décidera. Mais bon, le post sur
gentoo-dev@ lui aurait l'avantage d'avoir éventuellement
plusieurs réponses.
