[gentoo-user] eselect for managing virtuals

[gentoo-user] eselect for managing virtuals

[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 ?

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: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-user] eselect for managing virtuals

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] eselect for managing virtuals

[Enrico Weigelt]

* Florian Philipp <lists@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: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------