| 1 |
Maciek Borowka wrote: |
| 2 |
>> anyways, i see |
| 3 |
>> no reason why you couldn't make the ebuild scripts interactive |
| 4 |
> |
| 5 |
>You're right - the technical possibility exists, the problem is that no |
| 6 |
>ebuild script does actually use it... |
| 7 |
> |
| 8 |
>> ebuild scripts to check for $EMERGE_INTERACTIVE in the user's |
| 9 |
>> environment e.g - if "1" then ask your questions else build "as normal". |
| 10 |
> |
| 11 |
>I agree absolutely - interactivity is only an option... |
| 12 |
|
| 13 |
I would like to add a suggestion. Use config files with defaults. I have |
| 14 |
the following reasons for doing that: |
| 15 |
- Interactivity is not nescesarry when default config is preferred |
| 16 |
- It is possible to preconfigure a number of packages at once and than put |
| 17 |
the computer to work for the night. |
| 18 |
- It might be possible to upgrade old preferences |
| 19 |
|
| 20 |
The system could than get the following specifications: |
| 21 |
- An extra interactive_config() function added to the ebuild with the |
| 22 |
following specs: |
| 23 |
* Every option is specified with an add_option(name, type, |
| 24 |
default), where "name" is the name of the option, "type" is the |
| 25 |
datatype of the option eg: boolean, string, int. "default" is |
| 26 |
the default value of the option. Boolean options can be passed |
| 27 |
in the USE variable for optimal consistency, the other types are |
| 28 |
more rare. |
| 29 |
* An optional description can be given with a |
| 30 |
describe_option(name, description) function. This clarifies the |
| 31 |
option so maybe should not be optional |
| 32 |
* An optional option_compat(name, version) function can be used to |
| 33 |
specify a version of the package for which re-evaluation of the |
| 34 |
option is not necesarry. (And for which it is) |
| 35 |
|
| 36 |
- The config file should specify all options and the chosen values. |
| 37 |
|
| 38 |
- For default builds no config file should be made. |
| 39 |
|
| 40 |
- As stated above the option file should be tied to a package version. |
| 41 |
Possibly the same naming as the digest file (but then with config) is |
| 42 |
useful. |
| 43 |
|
| 44 |
If anyone has any comments on this, please let me hear them (by posting to |
| 45 |
the mailing list) |
| 46 |
|
| 47 |
Paul |
| 48 |
|
| 49 |
ps. I also send this to gentoo-dev because I think this mail is more |
| 50 |
appropriate there, although it reacts on gentoo-user |
| 51 |
|
| 52 |
-- |
| 53 |
___ |
| 54 |
/~~~\ | Paul de Vrieze |
| 55 |
| O-O | | Student of information management and technology |
| 56 |
| _ | | Mail: Paul@××××××××.net |
| 57 |
\___/ | Homepage: http://www.devrieze.net |
Archives