1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 28/06/12 09:41 PM, Kent Fredric wrote: |
5 |
> I was doing a fresh Gentoo install today, following the manual, and |
6 |
> it appeared to me that the manual suggests to install a "logger" |
7 |
> and a "cron", and gives some defacto suggestions. |
8 |
> |
9 |
> However, the available packages that provide this facility(s) are |
10 |
> not overly obvious from a portage standpoint. |
11 |
> |
12 |
> The best index I can find presently for a list of things that |
13 |
> provide these facilities are virtual/cron , and virtual/logger , |
14 |
> and only then by perusing the source. |
15 |
> |
16 |
> And if you tell somebody to install "virtual/cron", you'll get the |
17 |
> first thing in the ||( ) list, not an elective choice of which to |
18 |
> install. |
19 |
> |
20 |
> It makes sense to me that there are some circumstances, where it |
21 |
> makes sense to, instead of simply picking the first match, present |
22 |
> the user with the option of one of them ( somehow ). |
23 |
> |
24 |
> ie: emerge -pv virtual/cron could, instead of the current |
25 |
> behaviour of installing vixie-cron,show a list with the non-chosen |
26 |
> alternatives: |
27 |
> |
28 |
> What we presently get is this: |
29 |
> |
30 |
> [ebuild N ] sys-process/vixie-cron-4.1-r12 USE="pam -debug |
31 |
> (-selinux)" 0 kB [ebuild N ] virtual/cron-0 0 kB |
32 |
> |
33 |
> Where it might be nice to instead give: |
34 |
> |
35 |
> [ebuild N ] sys-process/vixie-cron-4.1-r12 USE="pam -debug |
36 |
> (-selinux)" 0 kB [ebuild ? ] sys-process/cronie-1.4.8 |
37 |
> USE="inotify pam" ( virtual/cron ) [ebuild ? ] |
38 |
> sys-process/dcron-4.5 44 kB ( virtual/cron ) [ebuild ? ] |
39 |
> sys-process/fcron-3.0.6-r1 USE="pam -debug (-selinux)" |
40 |
> LINGUAS="-fr" 540 kB ( virtual/cron ) [ebuild ? ] |
41 |
> sys-process/bcron-0.09 57 kB ( virtual/cron ) [ebuild N ] |
42 |
> virtual/cron-0 0 kB |
43 |
> |
44 |
> As a way to show that vixie-cron is being chosen as the default, |
45 |
> but there are other things that can optionally provide that virtual |
46 |
> too. |
47 |
> |
48 |
> (* important: dependent children of the alternatives should not be |
49 |
> computed or displayed, as this will only add confusion, not to |
50 |
> mention headaches, as all the above crons have blockers on each |
51 |
> other to stop them being installed together ) |
52 |
> |
53 |
> This is the "Simplest" option I could think of that made it more |
54 |
> "User facing" that these virtuals exist to provide a given feature |
55 |
> using a mechanism of the users choice. |
56 |
> |
57 |
> You could take this further and make an interactive choice system, |
58 |
> which was only presented in certain conditons, ie: if the ||( ) |
59 |
> condition was not already satisfied, or if the users command |
60 |
> indicated they want to choose virtuals themselves: |
61 |
> |
62 |
> emerge --virtuals=auto # current behaviour emerge |
63 |
> --virtuals=pick-missing # interactive choice only if the |
64 |
> conditionals are not already satisfied emerge |
65 |
> --virtuals=pick-specified # interactive choice only for virtuals |
66 |
> listed on the invocation line emerge --virtuals=pick-all # |
67 |
> interactive choice every time |
68 |
> |
69 |
> Theres possibly other avenues I haven't thought of that might also |
70 |
> be useful. |
71 |
> |
72 |
> The pick interface could be something like |
73 |
> |
74 |
> virtual/cron can be provided by one of the following 1) |
75 |
> sys-process/vixie-cron (4.1-r12): Paul Vixie's cron daemon, a fully |
76 |
> featured crond implementation 2) sys-process/bcron (0.09): A new |
77 |
> cron system designed with secure operations in mind by Bruce |
78 |
> Guenter 3) sys-process/cronie (1.4.8): Cronie is a standard UNIX |
79 |
> daemon cron based on the original vixie-cron. 4) sys-process/dcron |
80 |
> (4.5): A cute little cron from Matt Dillon 5) sys-process/fcron |
81 |
> (3.0.6-r1): A command scheduler with extended capabilities over |
82 |
> cron and anacron choice[1]: |
83 |
> |
84 |
> *( list taken liberally from eix -c ) |
85 |
> |
86 |
> Then the documentation could be updated to simply tell the user |
87 |
> |
88 |
> emerge --virtuals=pick-specified virtual/cron virtual/logger |
89 |
> |
90 |
> And they could then just use the defaults ( by pressing enter ), |
91 |
> or choosing their favourite. |
92 |
> |
93 |
> Also, perhaps "Virtuals" is a poor name for what mechanism I am |
94 |
> describing. There are potentially many things that want an |
95 |
> elective process like this on many packages, but it seems a |
96 |
> mechanism more prevalent in virtuals. Especially as this facility |
97 |
> is mostly provided by the "USE" mechanism in most other places. |
98 |
> However, in VIRTUALS where you have a list of mutually exclusive |
99 |
> alternates, a long list of USE flags with one of them defaulted via |
100 |
> IUSE seems bad. Not to mention, the mechanism for displaying what |
101 |
> each individual USE flag will get you is a bit messy at present. ( |
102 |
> Being, you have to invoke some other portage command, and this |
103 |
> requires you finding applicable documentation for that command, to |
104 |
> work out how to query what each individual USE flag means , and |
105 |
> then run a different command for each package you want to consider |
106 |
> to see its description ) |
107 |
> |
108 |
> |
109 |
|
110 |
The reason for the virtual itself is so that all of the various |
111 |
packages that can satisfy the virtual will satisfy all the consumers |
112 |
(rdeps) of that virtual. It's not so much for providing a shortcut |
113 |
for the user; I haven't checked but I expect that the handbook still |
114 |
recommends direct emerge of 'vixie-cron' or 'syslog-ng' (or whatever |
115 |
alternatives a user wants to choose) rather than emerging the virtual. |
116 |
|
117 |
Perhaps it would be best to tell users that if they'd like to see the |
118 |
possible choices they can run ie 'qdepends -r virtual/cron' |
119 |
|
120 |
This doesn't seem like something to me that portage should bother to |
121 |
do directly, however I could see this being of benefit to a ui-wrapper |
122 |
of portage (if such a thing were to exist)? |
123 |
-----BEGIN PGP SIGNATURE----- |
124 |
Version: GnuPG v2.0.19 (GNU/Linux) |
125 |
|
126 |
iF4EAREIAAYFAk/tn/MACgkQ2ugaI38ACPCupQD/Rg9YLSXkAWFgcs4p0hUGqOiy |
127 |
0SSdW3mnuY4gdavXU3EA/RDv7+rejB9S53yquF8GpZWmzuTuMJF6oP3r8ho7mjBz |
128 |
=47wa |
129 |
-----END PGP SIGNATURE----- |