Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Feature Request/RFC : "Elective" virtuals
Date: Fri, 29 Jun 2012 12:32:52
In Reply to: [gentoo-dev] Feature Request/RFC : "Elective" virtuals by Kent Fredric
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-----


Subject Author
Re: [gentoo-dev] Feature Request/RFC : "Elective" virtuals Kent Fredric <kentfredric@×××××.com>