Am 07.05.2011 12:53, schrieb Enrico Weigelt: > > Hi folks, > > > just an idea spinning around in my head: > > Is it possible to influence the dependency resolution (eg. on virtuals) ? > > For example, several weeks ago somebody here asked on how to switch > from jpeg to jpeg-turbo. For such cases it IMHO would be fine if > there was some eselect which controls the behaviour of the > virtual/jpeg package. Once he switched over via eselect, it would > trigger the other jpeg implementation and (if necessary) rebuild > of all depending packages on next emerge world. > > Could the current eselect + portage system provide this ? >
I might be wrong here but it is my understanding that eselect is Gentoo-specific. The portage tree, the ebuild format and the corresponding EAPIs are not. Mixing those concepts might be troublesome and need some standardization process. However, what you want can still be done without touching the ebuilds because it would really just be an alias for `emerge --one-shot <new_alternative> && emerge --depclean <old_alternative> && revdep-rebuild` (in the easiest, non-blocking case). I personally wouldn't want to automate this. The problem is that different virtuals need different switching strategies. Converting from jpeg to jpeg-turbo is relatively straight-forward. Switching between httpd-basic implementations, on the other hand, needs manual work to carry over config files and such. Maybe it would be a better idea to teach emerge to warn the user when a default virtual implementation is about to be installed and show the different alternatives. Similarly emerge --sync or eix-sync could inform the user when a new alternative package for an already installed virtual is available. > The whole idea could also be extended to packages which frequently > require revdep-rebuild (eg. poppler): those packages would be > slotted for parallel installation and an new virtual is introduced > where clients will depend on (instead of the actual package directly) > When new versions come out, the user will be tolld (eg. via eselect > news) that he can now switch his system. Once he does the switch, > new builds will be made against the new version and remaining > packages (still linking to the old library) will be triggered > for update. > > > cu Isn't that problem resolved in portage-2.2 by keeping the old library file around until all packages have been re-emerged? Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
