Re: [gentoo-user] eselect for managing virtuals
* Florian Philipp li...@binarywings.net wrote: 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). No, this isn't enough. I want an stable method which never leaves the system in an inconsistent state. When revdep-rebuild is required, there's normally a period of time where some installed packages are broken (okay, preserved-libs makes it better), exactly what I never want on a productive system. 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. I didn't intend to do this fully automatic, for all virtuals. Just a bunch of special ones which just handle the scenarios of exchanging libraries (also on different/incompatible ABIs). 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. Indeed, that would be a good feature. Isn't that problem resolved in portage-2.2 by keeping the old library file around until all packages have been re-emerged? The preserve-libs stuff ? I'm not sure how it actually works under the hood, but as far as I can see it, it's just done for certain critical libs yet (eg. openssl), and the package manager doesn't know much of it, just keeps certain files around. So manual revdep-rebuild runs and removals of old libs is still required. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
[gentoo-user] eselect for managing virtuals
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 ? 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 -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-user] eselect for managing virtuals
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
