Feature Request/RFC : "Elective" virtuals
 

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

Feature Request/RFC : "Elective" virtuals
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/06/12 09:41 PM, Kent Fredric wrote:
> 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 )
>
>

The reason for the virtual itself is so that all of the various
packages that can satisfy the virtual will satisfy all the consumers
(rdeps) of that virtual. It's not so much for providing a shortcut
for the user; I haven't checked but I expect that the handbook still
recommends direct emerge of 'vixie-cron' or 'syslog-ng' (or whatever
alternatives a user wants to choose) rather than emerging the virtual.

Perhaps it would be best to tell users that if they'd like to see the
possible choices they can run ie 'qdepends -r virtual/cron'

This doesn't seem like something to me that portage should bother to
do directly, however I could see this being of benefit to a ui-wrapper
of portage (if such a thing were to exist)?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/tn/MACgkQ2ugaI38ACPCupQD/Rg9YLSXkAWFgcs4p0hUGqOiy
0SSdW3mnuY4gdavXU3EA/RDv7+rejB9S53yquF8GpZWmzuTuMJF6oP3r8ho7mjBz
=47wa
-----END PGP SIGNATURE-----

Feature Request/RFC : "Elective" virtuals
 

>
> Perhaps it would be best to tell users that if they'd like to see the
> possible choices they can run ie 'qdepends -r virtual/cron'
>

Quite, perhaps it could be a seperate mechanism, it would just seem
that for virtuals that just provide a list of alternatives, having a
seperate package that gives the *choice* of one of those alternatives
seems like redundant code. ( Most virtuals are simple non-exclusive
ors, so the packages that satisfy them can all be installed
simultaneously, however, there are a few virtuals that are inherently
exclusive-ors, as all the dependents exclude each other )

Perhaps it could be an additional metafield, upon which the choice of
one of several choices could be presented to the user by using a
different tool.

All packages which have an "alternatives" mechanism like this could
then also be indexed and the user could then only enter the selection
process with a separate tool which is a wrapper for portage.

I'm not sure if it makes sense or not to make it as an eselect
submodule that lets the user make choices and then have something else
apply them, or a dedicated tool; ie:

eselect alternatives list # list all the "things" that have
dependents that are mutually exclusive choices
eselect alternatives set cron --auto # selects vixie-cron
eselect alternatives set cron cronie
emerge -uvatDN @changed_alternatives

Or something like that.

You could drive it of course using external metadata not bundled with
the virtual's themselves, the benefit being you avoid the need to trip
the whole change process for virtuals and stabilisation, but the
downside is of course possible desynchronisation of choice metadata
with choices that are available via the virtual.

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