| 1 |
Am 07.05.2011 12:53, schrieb Enrico Weigelt: |
| 2 |
> |
| 3 |
> Hi folks, |
| 4 |
> |
| 5 |
> |
| 6 |
> just an idea spinning around in my head: |
| 7 |
> |
| 8 |
> Is it possible to influence the dependency resolution (eg. on virtuals) ? |
| 9 |
> |
| 10 |
> For example, several weeks ago somebody here asked on how to switch |
| 11 |
> from jpeg to jpeg-turbo. For such cases it IMHO would be fine if |
| 12 |
> there was some eselect which controls the behaviour of the |
| 13 |
> virtual/jpeg package. Once he switched over via eselect, it would |
| 14 |
> trigger the other jpeg implementation and (if necessary) rebuild |
| 15 |
> of all depending packages on next emerge world. |
| 16 |
> |
| 17 |
> Could the current eselect + portage system provide this ? |
| 18 |
> |
| 19 |
|
| 20 |
I might be wrong here but it is my understanding that eselect is |
| 21 |
Gentoo-specific. The portage tree, the ebuild format and the |
| 22 |
corresponding EAPIs are not. Mixing those concepts might be troublesome |
| 23 |
and need some standardization process. |
| 24 |
|
| 25 |
However, what you want can still be done without touching the ebuilds |
| 26 |
because it would really just be an alias for `emerge --one-shot |
| 27 |
<new_alternative> && emerge --depclean <old_alternative> && |
| 28 |
revdep-rebuild` (in the easiest, non-blocking case). |
| 29 |
|
| 30 |
I personally wouldn't want to automate this. The problem is that |
| 31 |
different virtuals need different switching strategies. Converting from |
| 32 |
jpeg to jpeg-turbo is relatively straight-forward. Switching between |
| 33 |
httpd-basic implementations, on the other hand, needs manual work to |
| 34 |
carry over config files and such. |
| 35 |
|
| 36 |
Maybe it would be a better idea to teach emerge to warn the user when a |
| 37 |
default virtual implementation is about to be installed and show the |
| 38 |
different alternatives. Similarly emerge --sync or eix-sync could inform |
| 39 |
the user when a new alternative package for an already installed virtual |
| 40 |
is available. |
| 41 |
|
| 42 |
> The whole idea could also be extended to packages which frequently |
| 43 |
> require revdep-rebuild (eg. poppler): those packages would be |
| 44 |
> slotted for parallel installation and an new virtual is introduced |
| 45 |
> where clients will depend on (instead of the actual package directly) |
| 46 |
> When new versions come out, the user will be tolld (eg. via eselect |
| 47 |
> news) that he can now switch his system. Once he does the switch, |
| 48 |
> new builds will be made against the new version and remaining |
| 49 |
> packages (still linking to the old library) will be triggered |
| 50 |
> for update. |
| 51 |
> |
| 52 |
> |
| 53 |
> cu |
| 54 |
|
| 55 |
Isn't that problem resolved in portage-2.2 by keeping the old library |
| 56 |
file around until all packages have been re-emerged? |
| 57 |
|
| 58 |
Regards, |
| 59 |
Florian Philipp |
Archives