J'ai réussi à installer une gentoo 2004.1 sur mon ibook G4, tous fonctionne
parfaitement (mis à part l'heure mais je ferais un autre post) mais quand je
fait un :
ibook root # emerge --pretend --update --deep world
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[ebuild N ] media-sound/alsa-driver-0.9.8
Mais le problème est que je n'en ai pas besoin de ce fichus paquet or je
n'arrive pas à trouver dans la doc comment je peux éviter d'installer de
paquet :-(
En fait j'aimerais bien marquer quelques part que je ne veux jammais
installer ce paquet
tu peux rajouter/modifier les lignes suivantes dans le fichier /var/cache/edb/virtuals : virtual/alsa-drivers sys-kernel/development-sources virtual/alsa sys-kernel/development-sources
Le fichier virtuals sert à gérer des dépendances virtuelles. Par exemple, un paquet peut dépendre d'un serveur X, mais sans savoir si ce serveur X est Xfree ou X.org ou un autre. Ce paquet dépendre alors de virtual/x11, et portage ira voir dans le fichier virtuals pour savoir quel serveur X utiliser (virtual/x11 x11-base/xorg-x11 pour X.org).
Normalement, ce fichier devrait disparaitre dans une prochaine version de portage : portage regardera ce qui est déjà installé pour obtenir les dépendances virtuelles.
Bruno Michel
Regis wrote:
Bonjour,
J'ai réussi à installer une gentoo 2004.1 sur mon ibook G4, tous fonctionne parfaitement (mis à part l'heure mais je ferais un autre post) mais quand je fait un :
ibook root # emerge --pretend --update --deep world
These are the packages that I would merge, in order:
Calculating world dependencies ...done! [ebuild N ] media-sound/alsa-driver-0.9.8
Mais le problème est que je n'en ai pas besoin de ce fichus paquet or je n'arrive pas à trouver dans la doc comment je peux éviter d'installer de paquet :-(
En fait j'aimerais bien marquer quelques part que je ne veux jammais installer ce paquet
Donc si vous avez une solus ,-))
Merci d'avance
-- mailing list
-- mailing list
Bonjour,
tu peux rajouter/modifier les lignes suivantes dans le fichier
/var/cache/edb/virtuals :
virtual/alsa-drivers sys-kernel/development-sources
virtual/alsa sys-kernel/development-sources
Le fichier virtuals sert à gérer des dépendances virtuelles. Par
exemple, un paquet peut dépendre d'un serveur X, mais sans savoir si ce
serveur X est Xfree ou X.org ou un autre. Ce paquet dépendre alors de
virtual/x11, et portage ira voir dans le fichier virtuals pour savoir
quel serveur X utiliser (virtual/x11 x11-base/xorg-x11 pour X.org).
Normalement, ce fichier devrait disparaitre dans une prochaine version
de portage : portage regardera ce qui est déjà installé pour obtenir les
dépendances virtuelles.
Bruno Michel
Regis wrote:
Bonjour,
J'ai réussi à installer une gentoo 2004.1 sur mon ibook G4, tous fonctionne
parfaitement (mis à part l'heure mais je ferais un autre post) mais quand je
fait un :
ibook root # emerge --pretend --update --deep world
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[ebuild N ] media-sound/alsa-driver-0.9.8
Mais le problème est que je n'en ai pas besoin de ce fichus paquet or je
n'arrive pas à trouver dans la doc comment je peux éviter d'installer de
paquet :-(
En fait j'aimerais bien marquer quelques part que je ne veux jammais
installer ce paquet
tu peux rajouter/modifier les lignes suivantes dans le fichier /var/cache/edb/virtuals : virtual/alsa-drivers sys-kernel/development-sources virtual/alsa sys-kernel/development-sources
Le fichier virtuals sert à gérer des dépendances virtuelles. Par exemple, un paquet peut dépendre d'un serveur X, mais sans savoir si ce serveur X est Xfree ou X.org ou un autre. Ce paquet dépendre alors de virtual/x11, et portage ira voir dans le fichier virtuals pour savoir quel serveur X utiliser (virtual/x11 x11-base/xorg-x11 pour X.org).
Normalement, ce fichier devrait disparaitre dans une prochaine version de portage : portage regardera ce qui est déjà installé pour obtenir les dépendances virtuelles.
Bruno Michel
Regis wrote:
Bonjour,
J'ai réussi à installer une gentoo 2004.1 sur mon ibook G4, tous fonctionne parfaitement (mis à part l'heure mais je ferais un autre post) mais quand je fait un :
ibook root # emerge --pretend --update --deep world
These are the packages that I would merge, in order:
Calculating world dependencies ...done! [ebuild N ] media-sound/alsa-driver-0.9.8
Mais le problème est que je n'en ai pas besoin de ce fichus paquet or je n'arrive pas à trouver dans la doc comment je peux éviter d'installer de paquet :-(
En fait j'aimerais bien marquer quelques part que je ne veux jammais installer ce paquet
Donc si vous avez une solus ,-))
Merci d'avance
-- mailing list
-- mailing list
Regis
> tu peux rajouter/modifier les lignes suivantes dans le fichier /var/cache/edb/virtuals : virtual/alsa-drivers sys-kernel/development-sources virtual/alsa sys-kernel/development-sources
Je te remercie ça marche ,-)
Normalement, ce fichier devrait disparaitre dans une prochaine version de portage : portage regardera ce qui est déjà installé pour obtenir les dépendances virtuelles.
Donc si je veux un paquet à la place d'un autre j'utilise ce fichier ?
Or que xine-lib-1_rc5-r2 lui est déjas installer et il me convient parfaitement donc je ne veux pas de xine-lib-1_rc4-r1 (qui plus est il ne veux pas compiler (!!! Parallel make failed)
Donc j'ai essayé ceci :
virtual/xine-lib media-libs/xine-lib-1_rc5-r2
Mais ca ne marche pas :-( systématiquement il revient à la charge avec son rc4 :-((
A+
-- mailing list
> tu peux rajouter/modifier les lignes suivantes dans le fichier
/var/cache/edb/virtuals :
virtual/alsa-drivers sys-kernel/development-sources
virtual/alsa sys-kernel/development-sources
Je te remercie ça marche ,-)
Normalement, ce fichier devrait disparaitre dans une prochaine version
de portage : portage regardera ce qui est déjà installé pour obtenir les
dépendances virtuelles.
Donc si je veux un paquet à la place d'un autre j'utilise ce fichier ?
Or que xine-lib-1_rc5-r2 lui est déjas installer et il me convient
parfaitement donc je ne veux pas de xine-lib-1_rc4-r1 (qui plus est il ne
veux pas compiler (!!! Parallel make failed)
Donc j'ai essayé ceci :
virtual/xine-lib media-libs/xine-lib-1_rc5-r2
Mais ca ne marche pas :-( systématiquement il revient à la charge avec son
rc4 :-((
> tu peux rajouter/modifier les lignes suivantes dans le fichier /var/cache/edb/virtuals : virtual/alsa-drivers sys-kernel/development-sources virtual/alsa sys-kernel/development-sources
Je te remercie ça marche ,-)
Normalement, ce fichier devrait disparaitre dans une prochaine version de portage : portage regardera ce qui est déjà installé pour obtenir les dépendances virtuelles.
Donc si je veux un paquet à la place d'un autre j'utilise ce fichier ?
Or que xine-lib-1_rc5-r2 lui est déjas installer et il me convient parfaitement donc je ne veux pas de xine-lib-1_rc4-r1 (qui plus est il ne veux pas compiler (!!! Parallel make failed)
Donc j'ai essayé ceci :
virtual/xine-lib media-libs/xine-lib-1_rc5-r2
Mais ca ne marche pas :-( systématiquement il revient à la charge avec son rc4 :-((
A+
-- mailing list
Bruno Michel
>>Normalement, ce fichier devrait disparaitre dans une prochaine version de portage : portage regardera ce qui est déjà installé pour obtenir les dépendances virtuelles.
Donc si je veux un paquet à la place d'un autre j'utilise ce fichier ?
Or que xine-lib-1_rc5-r2 lui est déjas installer et il me convient parfaitement donc je ne veux pas de xine-lib-1_rc4-r1 (qui plus est il ne veux pas compiler (!!! Parallel make failed)
Donc j'ai essayé ceci :
virtual/xine-lib media-libs/xine-lib-1_rc5-r2
Mais ca ne marche pas :-( systématiquement il revient à la charge avec son rc4 :-((
Le fichier virtuals sert à indiquer quel paquet utiliser pour une dépendance virtuelle, mais pas à indiquer quelle version d'un paquet installer.
Pour cela, il faut utiliser le fichier /etc/portage/package.mask pour masquer les versions à ne pas utiliser. Si le fichier /etc/portage/package.mask n'existe pas, il suffit de le créer (et de même pour le répertoire /etc/portage).
Dans ton cas, je pense que mettre : >=media-libs/xine-lib-1_rc5 dans ce fichier devrait marcher.
Par contre, si jamais de nouvelles versions de xine-lib devaient sortir, elles seraient masquées, donc emerge -u world ne te le proposerait pas. Si tu veux les installer, remplacer le >= par = .
-- Bruno Michel
-- mailing list
>>Normalement, ce fichier devrait disparaitre dans une prochaine version
de portage : portage regardera ce qui est déjà installé pour obtenir les
dépendances virtuelles.
Donc si je veux un paquet à la place d'un autre j'utilise ce fichier ?
Or que xine-lib-1_rc5-r2 lui est déjas installer et il me convient
parfaitement donc je ne veux pas de xine-lib-1_rc4-r1 (qui plus est il ne
veux pas compiler (!!! Parallel make failed)
Donc j'ai essayé ceci :
virtual/xine-lib media-libs/xine-lib-1_rc5-r2
Mais ca ne marche pas :-( systématiquement il revient à la charge avec son
rc4 :-((
Le fichier virtuals sert à indiquer quel paquet utiliser pour une
dépendance virtuelle, mais pas à indiquer quelle version d'un paquet
installer.
Pour cela, il faut utiliser le fichier /etc/portage/package.mask pour
masquer les versions à ne pas utiliser. Si le fichier
/etc/portage/package.mask n'existe pas, il suffit de le créer (et de
même pour le répertoire /etc/portage).
Dans ton cas, je pense que mettre :
>=media-libs/xine-lib-1_rc5
dans ce fichier devrait marcher.
Par contre, si jamais de nouvelles versions de xine-lib devaient sortir,
elles seraient masquées, donc emerge -u world ne te le proposerait pas.
Si tu veux les installer, remplacer le >= par = .
>>Normalement, ce fichier devrait disparaitre dans une prochaine version de portage : portage regardera ce qui est déjà installé pour obtenir les dépendances virtuelles.
Donc si je veux un paquet à la place d'un autre j'utilise ce fichier ?
Or que xine-lib-1_rc5-r2 lui est déjas installer et il me convient parfaitement donc je ne veux pas de xine-lib-1_rc4-r1 (qui plus est il ne veux pas compiler (!!! Parallel make failed)
Donc j'ai essayé ceci :
virtual/xine-lib media-libs/xine-lib-1_rc5-r2
Mais ca ne marche pas :-( systématiquement il revient à la charge avec son rc4 :-((
Le fichier virtuals sert à indiquer quel paquet utiliser pour une dépendance virtuelle, mais pas à indiquer quelle version d'un paquet installer.
Pour cela, il faut utiliser le fichier /etc/portage/package.mask pour masquer les versions à ne pas utiliser. Si le fichier /etc/portage/package.mask n'existe pas, il suffit de le créer (et de même pour le répertoire /etc/portage).
Dans ton cas, je pense que mettre : >=media-libs/xine-lib-1_rc5 dans ce fichier devrait marcher.
Par contre, si jamais de nouvelles versions de xine-lib devaient sortir, elles seraient masquées, donc emerge -u world ne te le proposerait pas. Si tu veux les installer, remplacer le >= par = .
-- Bruno Michel
-- mailing list
Regis
> Dans ton cas, je pense que mettre : >=media-libs/xine-lib-1_rc5
Justement non puisque je veux ce paquet ,-) c'est celui ci que je ne veux pas xine-lib-1_rc4-r1
En fait portage veux me downgrader car pour lui (si j'ai bien compris) xine-lib-1_rc5-r2 est masked
Donc j'ai mis dans /etc/portage/package.mask cette ligne :
=media-libs/xine-lib-1_rc4-r1
Mais ça ne me change rien :-(
Mais si dans /etc/portage/package.mask je met cette ligne :
=media-libs/xine-lib-1_rc4
Il veux me downgrader en rc3
En regardant mieux la doc j'ai vu qu'il y'avait la possibillité de faire un package.unmask
Je me suis empréssé de mettre dans /etc/portage/package.unmask cette ligne :
=media-libs/xine-lib-1_rc5
Mais ça ne me change rien emerge veux absolument me faire un downgrade :-(
Bref je n'y comprend rien :-(
A+
-- mailing list
> Dans ton cas, je pense que mettre :
>=media-libs/xine-lib-1_rc5
Justement non puisque je veux ce paquet ,-) c'est celui ci que je ne veux pas
xine-lib-1_rc4-r1
En fait portage veux me downgrader car pour lui (si j'ai bien compris)
xine-lib-1_rc5-r2 est masked
Donc j'ai mis dans /etc/portage/package.mask cette ligne :
=media-libs/xine-lib-1_rc4-r1
Mais ça ne me change rien :-(
Mais si dans /etc/portage/package.mask je met cette ligne :
=media-libs/xine-lib-1_rc4
Il veux me downgrader en rc3
En regardant mieux la doc j'ai vu qu'il y'avait la possibillité de faire un
package.unmask
Je me suis empréssé de mettre dans /etc/portage/package.unmask cette ligne :
=media-libs/xine-lib-1_rc5
Mais ça ne me change rien emerge veux absolument me faire un downgrade :-(
> Dans ton cas, je pense que mettre : >=media-libs/xine-lib-1_rc5
Justement non puisque je veux ce paquet ,-) c'est celui ci que je ne veux pas xine-lib-1_rc4-r1
En fait portage veux me downgrader car pour lui (si j'ai bien compris) xine-lib-1_rc5-r2 est masked
Donc j'ai mis dans /etc/portage/package.mask cette ligne :
=media-libs/xine-lib-1_rc4-r1
Mais ça ne me change rien :-(
Mais si dans /etc/portage/package.mask je met cette ligne :
=media-libs/xine-lib-1_rc4
Il veux me downgrader en rc3
En regardant mieux la doc j'ai vu qu'il y'avait la possibillité de faire un package.unmask
Je me suis empréssé de mettre dans /etc/portage/package.unmask cette ligne :
=media-libs/xine-lib-1_rc5
Mais ça ne me change rien emerge veux absolument me faire un downgrade :-(
Bref je n'y comprend rien :-(
A+
-- mailing list
Yoann Pannier
Regis wrote:
En fait portage veux me downgrader car pour lui (si j'ai bien compris) xine-lib-1_rc5-r2 est masked
S'il veut downgrader, c'est probablement parce que ton système se veut "stable" alors que ce xine-lib ne l'est pas. Il te faut spécifier, en connaissance de cause et surtout d'effets éventuels, que tu veux installer ce paquet même s'il est considéré comme non-stable.
/etc/portage/package.keywords? #man portage
(éventuellement combiné avec /etc/portage/package.unmask, pour les paquets 'hard masked' (super-masqués?), qui, il faut le noter, le sont rarement pour rien).
-- Yoann Pannier
-- mailing list
Regis wrote:
En fait portage veux me downgrader car pour lui (si j'ai bien compris)
xine-lib-1_rc5-r2 est masked
S'il veut downgrader, c'est probablement parce que ton système se veut
"stable" alors que ce xine-lib ne l'est pas. Il te faut spécifier, en
connaissance de cause et surtout d'effets éventuels, que tu veux
installer ce paquet même s'il est considéré comme non-stable.
/etc/portage/package.keywords? #man portage
(éventuellement combiné avec /etc/portage/package.unmask, pour les
paquets 'hard masked' (super-masqués?), qui, il faut le noter, le sont
rarement pour rien).
En fait portage veux me downgrader car pour lui (si j'ai bien compris) xine-lib-1_rc5-r2 est masked
S'il veut downgrader, c'est probablement parce que ton système se veut "stable" alors que ce xine-lib ne l'est pas. Il te faut spécifier, en connaissance de cause et surtout d'effets éventuels, que tu veux installer ce paquet même s'il est considéré comme non-stable.
/etc/portage/package.keywords? #man portage
(éventuellement combiné avec /etc/portage/package.unmask, pour les paquets 'hard masked' (super-masqués?), qui, il faut le noter, le sont rarement pour rien).
-- Yoann Pannier
-- mailing list
Yoann Pannier
Regis wrote:
Or que xine-lib-1_rc5-r2 lui est déjas installer et il me convient parfaitement donc je ne veux pas de xine-lib-1_rc4-r1 (qui plus est il ne veux pas compiler (!!! Parallel make failed)
Si la 1_rc4-r1 ne compile pas malgré le fait qu'elle soit considérée comme stable (je suppose), c'est qu'il y a un problème chez toi ou dans l'ebuild ---> http://bugs.gentoo.org/
Ca te permettra peut-être de corriger ton problème (si c'est un bug connu), ou bien ca fera savoir aux personnes concernées qu'il y en a un, ce qui est bien pour tout le monde.
-- Yoann Pannier
-- mailing list
Regis wrote:
Or que xine-lib-1_rc5-r2 lui est déjas installer et il me convient
parfaitement donc je ne veux pas de xine-lib-1_rc4-r1 (qui plus est il ne
veux pas compiler (!!! Parallel make failed)
Si la 1_rc4-r1 ne compile pas malgré le fait qu'elle soit considérée
comme stable (je suppose), c'est qu'il y a un problème chez toi ou dans
l'ebuild ---> http://bugs.gentoo.org/
Ca te permettra peut-être de corriger ton problème (si c'est un bug
connu), ou bien ca fera savoir aux personnes concernées qu'il y en a un,
ce qui est bien pour tout le monde.
Or que xine-lib-1_rc5-r2 lui est déjas installer et il me convient parfaitement donc je ne veux pas de xine-lib-1_rc4-r1 (qui plus est il ne veux pas compiler (!!! Parallel make failed)
Si la 1_rc4-r1 ne compile pas malgré le fait qu'elle soit considérée comme stable (je suppose), c'est qu'il y a un problème chez toi ou dans l'ebuild ---> http://bugs.gentoo.org/
Ca te permettra peut-être de corriger ton problème (si c'est un bug connu), ou bien ca fera savoir aux personnes concernées qu'il y en a un, ce qui est bien pour tout le monde.
-- Yoann Pannier
-- mailing list
Regis
> Si la 1_rc4-r1 ne compile pas malgré le fait qu'elle soit considérée comme stable (je suppose), c'est qu'il y a un problème chez toi ou dans l'ebuild ---> http://bugs.gentoo.org/
Ca te permettra peut-être de corriger ton problème (si c'est un bug connu), ou bien ca fera savoir aux personnes concernées qu'il y en a un, ce qui est bien pour tout le monde.
Mon probléme vient d'un de mes cflags qui empéchaient de compiler -mcput50.
Effectivement mon le bug est répertorié ,-)
Comme je n'avais pas tellement envie d'enlever le flag de make.conf j'ai fait un :
Est ce que j'ai eu raison ou alors est ce que je devrais carrément le suprimmer de make.conf ?
Merci de votre aide à tous ,-)
-- mailing list
> Si la 1_rc4-r1 ne compile pas malgré le fait qu'elle soit considérée
comme stable (je suppose), c'est qu'il y a un problème chez toi ou dans
l'ebuild ---> http://bugs.gentoo.org/
Ca te permettra peut-être de corriger ton problème (si c'est un bug
connu), ou bien ca fera savoir aux personnes concernées qu'il y en a un,
ce qui est bien pour tout le monde.
Mon probléme vient d'un de mes cflags qui empéchaient de compiler -mcput50.
Effectivement mon le bug est répertorié ,-)
Comme je n'avais pas tellement envie d'enlever le flag de make.conf j'ai fait
un :
> Si la 1_rc4-r1 ne compile pas malgré le fait qu'elle soit considérée comme stable (je suppose), c'est qu'il y a un problème chez toi ou dans l'ebuild ---> http://bugs.gentoo.org/
Ca te permettra peut-être de corriger ton problème (si c'est un bug connu), ou bien ca fera savoir aux personnes concernées qu'il y en a un, ce qui est bien pour tout le monde.
Mon probléme vient d'un de mes cflags qui empéchaient de compiler -mcput50.
Effectivement mon le bug est répertorié ,-)
Comme je n'avais pas tellement envie d'enlever le flag de make.conf j'ai fait un :
Est ce que j'ai eu raison ou alors est ce que je devrais carrément le suprimmer de make.conf ?
De mémoire je crois que le fichier package.use situé dans /etc/portage est fait pour toi.
Mmmm, non, package.use est pour les USE flags, pas pour les CFLAGS.
A ma connaissance, il n'y a pas moyen de spécifier des CFLAGS par paquet, uniquement en global, dans make.conf.
Cela dit, retirer -mcpu de make.conf impacte les optimisations de tous le système. Alors le faire uniquement pour xine, ça me parait excessif. D'autant que sa prochaine version compilera peut-être normalement ?
Moi, pour un paquet, je passerai les CFLAGS en ligne de commande, et je ferai attention a la prochaine mise a jour/ré-installation de ce paquet.
Ou alors pour faire plus propre, je copierai l'ebuild en question dans mon repertoire d'overlay, et le modifierai pour qu'il filtre le -mcpu. (PORTDIR_OVERLAY=/usr/local/portage dans make.conf, man make.conf, man portage, et doc sur les ebuilds sur gentoo.org pour le filtrage).
-- Yoann Pannier
-- mailing list
Christophe Garault wrote:
Regis a écrit :
Comme je n'avais pas tellement envie d'enlever le flag de make.conf
j'ai fait un :
Est ce que j'ai eu raison ou alors est ce que je devrais carrément le
suprimmer de make.conf ?
De mémoire je crois que le fichier package.use situé dans /etc/portage
est fait pour toi.
Mmmm, non, package.use est pour les USE flags, pas pour les CFLAGS.
A ma connaissance, il n'y a pas moyen de spécifier des CFLAGS par
paquet, uniquement en global, dans make.conf.
Cela dit, retirer -mcpu de make.conf impacte les optimisations de tous
le système. Alors le faire uniquement pour xine, ça me parait excessif.
D'autant que sa prochaine version compilera peut-être normalement ?
Moi, pour un paquet, je passerai les CFLAGS en ligne de commande, et je
ferai attention a la prochaine mise a jour/ré-installation de ce paquet.
Ou alors pour faire plus propre, je copierai l'ebuild en question dans
mon repertoire d'overlay, et le modifierai pour qu'il filtre le -mcpu.
(PORTDIR_OVERLAY=/usr/local/portage dans make.conf, man make.conf, man
portage, et doc sur les ebuilds sur gentoo.org pour le filtrage).
Est ce que j'ai eu raison ou alors est ce que je devrais carrément le suprimmer de make.conf ?
De mémoire je crois que le fichier package.use situé dans /etc/portage est fait pour toi.
Mmmm, non, package.use est pour les USE flags, pas pour les CFLAGS.
A ma connaissance, il n'y a pas moyen de spécifier des CFLAGS par paquet, uniquement en global, dans make.conf.
Cela dit, retirer -mcpu de make.conf impacte les optimisations de tous le système. Alors le faire uniquement pour xine, ça me parait excessif. D'autant que sa prochaine version compilera peut-être normalement ?
Moi, pour un paquet, je passerai les CFLAGS en ligne de commande, et je ferai attention a la prochaine mise a jour/ré-installation de ce paquet.
Ou alors pour faire plus propre, je copierai l'ebuild en question dans mon repertoire d'overlay, et le modifierai pour qu'il filtre le -mcpu. (PORTDIR_OVERLAY=/usr/local/portage dans make.conf, man make.conf, man portage, et doc sur les ebuilds sur gentoo.org pour le filtrage).
-- Yoann Pannier
-- mailing list
Christophe Garault
Yoann Pannier a écrit :
Mmmm, non, package.use est pour les USE flags, pas pour les CFLAGS.
Mon dieu mai qu'ais-je écris? Heu... bon, si personne n'y voit d'inconvénient on va mettre ça sur le compte du manque de sommeil Ok? ;-) Evidemment qu'il n'y a pas de méthode 'spécifique' pour modifier les CFLAGS d'un package, hormis bien sur la modification manuelle de l'ebuild et de la variable ${CFLAGS}. Maintenant j'ai tellement honte que je vais aller me coucher pour oublier .
-- Christophe Garault
-- mailing list
Yoann Pannier a écrit :
Mmmm, non, package.use est pour les USE flags, pas pour les CFLAGS.
Mon dieu mai qu'ais-je écris? Heu... bon, si personne n'y voit
d'inconvénient on va mettre ça sur le compte du manque de sommeil Ok? ;-)
Evidemment qu'il n'y a pas de méthode 'spécifique' pour modifier les
CFLAGS d'un package, hormis bien sur la modification manuelle de
l'ebuild et de la variable ${CFLAGS}.
Maintenant j'ai tellement honte que je vais aller me coucher pour oublier .
Mmmm, non, package.use est pour les USE flags, pas pour les CFLAGS.
Mon dieu mai qu'ais-je écris? Heu... bon, si personne n'y voit d'inconvénient on va mettre ça sur le compte du manque de sommeil Ok? ;-) Evidemment qu'il n'y a pas de méthode 'spécifique' pour modifier les CFLAGS d'un package, hormis bien sur la modification manuelle de l'ebuild et de la variable ${CFLAGS}. Maintenant j'ai tellement honte que je vais aller me coucher pour oublier .
