| 1 |
On Thu, 19 Jan 2006 12:11:55 +0100 |
| 2 |
Christophe Garault <christophe@×××××××.org> wrote: |
| 3 |
|
| 4 |
> Enfin je ne connais pas les arcanes de Portage et peut-être que |
| 5 |
> la modification manuelle du fichier world est à proscrire. |
| 6 |
|
| 7 |
Oh non, c'est tout à fait valide et même très pratique. Perso je |
| 8 |
fais souvent mes désinstallation via: |
| 9 |
- d'abord un petit coup de "sed" pour virer le(s) paquet(s) du |
| 10 |
world ; |
| 11 |
- ensuite un "depclean" pour ne les désinstaller que si il(s) |
| 12 |
est (sont) effectivement désinstallable sans rien casser |
| 13 |
d'autre. |
| 14 |
|
| 15 |
> si j'ai bien compris, un emerge -uD world m'aurait cette fois |
| 16 |
> bien mis à jour mon baselayout avec devfsd et non udev n'est-ce |
| 17 |
> pas? |
| 18 |
|
| 19 |
Oui. |
| 20 |
|
| 21 |
> Las, hélas je n'ai pas sauvegardé l'emplacement de devfsd dans le |
| 22 |
> fichier world et l'ai remis un peu au hasard. La question est |
| 23 |
> donc de savoir si l'ordre de tri dans world a son importance? |
| 24 |
|
| 25 |
Après petits test, la réponse est non, l'ordre dans le "world" |
| 26 |
n'influe pas. Par contre, l'ordre alphabétique dans les noms de |
| 27 |
paquets lui influe... Enfin, est-ce l'ordre alphabétique ou est-ce |
| 28 |
un autre ordre plus aléatoire (genre ordre d'énumération des |
| 29 |
clefs d'un dictionnaire), je ne sais pas, faudrait que je refoute |
| 30 |
mon nez dans le code, mais ce qui est sûr c'est que sur deux cas de |
| 31 |
tests en tout points similaire sinon le nom du paquet qui jouait le |
| 32 |
rôle de votre "devfsd", j'ai eu deux comportements différents : |
| 33 |
|
| 34 |
* 3 ebuilds bidons sans aucune dépendance : |
| 35 |
- test/disjA-1, qui tient le rôle de baselayout, |
| 36 |
- test/disjB-1, qui tient celui de udev, |
| 37 |
- test/disjC-1, qui tient celui de devfsd. |
| 38 |
|
| 39 |
* "emerge disjA disjC" |
| 40 |
|
| 41 |
* on bump disjA et disjC en version 1.1 |
| 42 |
|
| 43 |
* ajout à disjA-1.1 de la dépendance suivante : |
| 44 |
"|| ( test/disjB >=test/disjC-1.1 )" |
| 45 |
|
| 46 |
* "emerge -puD world" : |
| 47 |
[ebuild N ] test/disjB-1 |
| 48 |
[ebuild U ] test/disjA-1.1 |
| 49 |
[ebuild U ] test/disjC-1.1 |
| 50 |
(ici, "disjC" est bien mis à jour vu qu'il est dans world, mais |
| 51 |
trop tard pour empêcher l'activation de la dépendance |
| 52 |
"disjA --> disjB") |
| 53 |
|
| 54 |
* "emerge -C disjC" |
| 55 |
|
| 56 |
* on renomme partout "disjC" en "disj" (renommage des ebuilds, |
| 57 |
et correction de la dépendance de test/disjA-1.1) |
| 58 |
|
| 59 |
* "emerge =test/disj-1" (on est revenu à une situation similaire |
| 60 |
à la précédente, au renommage près) |
| 61 |
|
| 62 |
* "emerge -puD world" : |
| 63 |
[ebuild U ] test/disj-1.1 |
| 64 |
[ebuild U ] test/disjA-1.1 |
| 65 |
(cette fois par contre, "disj" se retrouve mis à jour en premier, |
| 66 |
et donc pas besoin d'installer "disjB") |
| 67 |
|
| 68 |
Bon, ça pour moi c'est quand même un bug. À mon avis, on éviterait |
| 69 |
cette indéterminisme si on réorganisait les éléments d'une |
| 70 |
disjonction en mettant en priorité les paquets installés. À voir si |
| 71 |
c'est faisable maintenant (je suis pas du tout familier avec le code |
| 72 |
du solveur de dépendances actuel, qui est vraiment assez galère). |
| 73 |
Mais j'irai au moins en discuter sur la ML gentoo-portage-dev@ |
| 74 |
quand j'aurai un moment (enfin, il faut que je reteste avec un |
| 75 |
portage à jour quand même avant, parceque là j'ai une version |
| 76 |
relativement ancienne que j'avais bidouillé un peu). |
| 77 |
|
| 78 |
-- |
| 79 |
TGL. |
| 80 |
|
| 81 |
-- |
| 82 |
gentoo-user-fr@g.o mailing list |
Archives