| 1 |
Regarding the etc-update issue, here are some of my thoughts. |
| 2 |
|
| 3 |
1. etc-update should check modify dates and overwrite if not modified. |
| 4 |
|
| 5 |
2. Part of the problem is that make.conf has so many options (ie. its a |
| 6 |
large file.) What if we split it up into smaller files... Something |
| 7 |
like: |
| 8 |
|
| 9 |
/etc/make.conf.d/USE |
| 10 |
/etc/make.conf.d/CFLAGS |
| 11 |
... |
| 12 |
/etc/make.conf.d/FEATURES |
| 13 |
etc... |
| 14 |
|
| 15 |
I would guess that a large portion of users never modify the features |
| 16 |
and other settings of make.conf. This way, etc-update could update only |
| 17 |
the portions that need updating without overwriting USE flags, etc. |
| 18 |
This would also make it easier to parse the files for any automated |
| 19 |
install (GLIS), etc. |
| 20 |
|
| 21 |
3. Another option is to have a file that contains the users settings, |
| 22 |
seperate from config files themselves... For instance, what if we had a |
| 23 |
file, say /etc/customsettings, that contained all the updated options |
| 24 |
for config files. It could perhaps contain a syntax like the following: |
| 25 |
|
| 26 |
/etc/make.conf:USE="X gnome gtk alsa" |
| 27 |
/etc/make.conf:FEATURES="distcc sandbox buildpkg" |
| 28 |
/etc/conf.d/net:IFACE="dhcp" |
| 29 |
|
| 30 |
Then etc-update could not only replace the old file with the update, but |
| 31 |
could also update it with the user's specific values. It could find the |
| 32 |
line with the "USE=" text and replace it with the full customized |
| 33 |
replacement. |
| 34 |
|
| 35 |
My $.02. |
| 36 |
-- |
| 37 |
Nathaniel McCallum |
| 38 |
npmccallum@×××××××××××××××××.net |
| 39 |
http://glis.sourceforge.net |
| 40 |
|
| 41 |
|
| 42 |
-- |
| 43 |
gentoo-dev@g.o mailing list |
Archives