[gentoo-dev] Feature Request/RFC : "Elective" virtuals

[Kent Fredric]

I was doing a fresh Gentoo install today, following the manual, and it
appeared to me that the manual suggests to install a "logger" and a
"cron", and gives some defacto suggestions.

However, the available packages that provide this facility(s) are not
overly obvious from a portage standpoint.

The best index I can find presently for a list of things that provide
these facilities are virtual/cron , and virtual/logger , and only then
by perusing the source.

And if you tell somebody to install "virtual/cron", you'll get the
first thing in the ||( ) list, not an elective choice of which to
install.

It makes sense to me that there are some circumstances, where it makes
sense to, instead of simply picking the first match, present the user
with the option of one of them ( somehow ).

ie:   emerge -pv virtual/cron  could, instead of the current behaviour
of installing vixie-cron,show a list with the non-chosen alternatives:

What we presently get is this:

[ebuild  N     ] sys-process/vixie-cron-4.1-r12  USE="pam -debug
(-selinux)" 0 kB
[ebuild  N     ]  virtual/cron-0  0 kB

Where it might be nice to instead give:

[ebuild  N     ] sys-process/vixie-cron-4.1-r12  USE="pam -debug
(-selinux)" 0 kB
[ebuild  ?     ] sys-process/cronie-1.4.8  USE="inotify pam" ( virtual/cron )
[ebuild  ?     ] sys-process/dcron-4.5  44 kB ( virtual/cron )
[ebuild  ?     ] sys-process/fcron-3.0.6-r1  USE="pam -debug
(-selinux)" LINGUAS="-fr" 540 kB ( virtual/cron )
[ebuild  ?     ] sys-process/bcron-0.09  57 kB ( virtual/cron )
[ebuild  N     ]  virtual/cron-0  0 kB

As a way to show that vixie-cron is being chosen as the default, but
there are other things that can optionally provide that virtual too.

(* important: dependent children of the alternatives should not be
computed or displayed, as this will only add confusion, not to mention
headaches, as all the above crons have blockers on each other to stop
them being installed together )

This is the "Simplest" option I could think of that made it more "User
facing" that these virtuals exist to provide a given feature using a
mechanism of the users choice.

You could take this further and make an interactive choice system,
which was only presented in certain conditons, ie: if the ||( )
condition was not already satisfied, or if the users command indicated
they want to choose virtuals themselves:

   emerge --virtuals=auto  # current behaviour
   emerge --virtuals=pick-missing # interactive choice only if the
conditionals are not already satisfied
   emerge --virtuals=pick-specified # interactive choice only for
virtuals listed on the invocation line
   emerge --virtuals=pick-all # interactive choice every time

Theres possibly other avenues I haven't thought of that might also be useful.

The pick interface could be something like

    virtual/cron  can be provided by one of the following
    1) sys-process/vixie-cron (4.1-r12): Paul Vixie's cron daemon, a
fully featured crond implementation
    2) sys-process/bcron (0.09): A new cron system designed with
secure operations in mind by Bruce Guenter
    3) sys-process/cronie (1.4.8): Cronie is a standard UNIX daemon
cron based on the original vixie-cron.
    4) sys-process/dcron (4.5): A cute little cron from Matt Dillon
    5) sys-process/fcron (3.0.6-r1): A command scheduler with extended
capabilities over cron and anacron
     choice[1]:

*( list taken liberally from eix -c  )

Then the documentation could be updated to simply tell the user

          emerge --virtuals=pick-specified virtual/cron virtual/logger

And they could then just use the defaults ( by pressing enter ), or
choosing their favourite.

Also, perhaps "Virtuals" is a poor name for what mechanism I am
describing. There are potentially many things that want an elective
process like this on many packages, but it seems a mechanism more
prevalent in virtuals. Especially as this facility is mostly provided
by the "USE" mechanism in most other places.  However, in VIRTUALS
where you have a list of mutually exclusive alternates, a long list of
USE flags with one of them defaulted via IUSE seems bad.  Not to
mention, the mechanism for displaying what each individual USE flag
will get you is a bit messy at present. ( Being, you have to invoke
some other portage command, and this requires you finding applicable
documentation for that command, to work out how to query what each
individual USE flag means , and then run a different command for each
package you want to consider to see its description )


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz