| 1 |
Hello, |
| 2 |
|
| 3 |
Too me, it sounds like your method of merging changes might be the problem. |
| 4 |
I haven't noticed a problem myself. I use etc-update with vimdiff. |
| 5 |
vimdiff folds all common text between files and so all I have to look at |
| 6 |
are the new changes (make.conf doesn't seem any worse than many other config |
| 7 |
files in this respect) if I decide to update the _whole_ file then I |
| 8 |
quite vimdiff and tell etc-update I want the old replaced, if I only |
| 9 |
want _some_ of the new changes then I take what I like from the new |
| 10 |
config file and edit my original config. Then when I quit vimdiff I can then |
| 11 |
tell etc-update to discard the update. |
| 12 |
|
| 13 |
That seems easy, I particularly like seeing any changes to the make.conf |
| 14 |
file just so that no new gentoo features slip by unnoticed (which could |
| 15 |
happen with the proposed seperate file setup, because I also like to |
| 16 |
have comments autmerged on unedited files) |
| 17 |
|
| 18 |
Rob |
| 19 |
|
| 20 |
On Tue, Jul 01, 2003 at 02:58:24AM -0700, Seemant Kulleen wrote: |
| 21 |
> Hi All, |
| 22 |
> |
| 23 |
> Before I go and invalidate a bug, I thought I might take the idea around here to see if it has any merit in terms of usefulness/interest. |
| 24 |
> |
| 25 |
> The idea stems from the fact that etc-updating a make.conf file can be a bit of a stressful event. And as portage's set of features grows, so too will the size of the make.conf file. I get the impression that the make.conf file is a little hard to parse, with the huge comment blocks etc etc. So my proposal is this: a make.conf.d directory which contains files for each section of the make.conf: use, flags, fetch, packagevars. That way, USE flags can be explained and specified in use, compiler flags in the flags file, fetch will contain the fetchcommands, mirrors (both distfiles and rsync), and packagevars can contain things like ALSA_CARDS for those of us on 2.4 kernels, and VIDEO_CARDS for those of us who have xfree/xfree-drm/whatever-future-windowing-system-we-add, and so on. This way, the actual make.conf file (which tends to be about 10 lines of uncommented items in the usual case) can be dynamically generated from the information in those files. |
| 26 |
> |
| 27 |
> Anyway, it's not an urgent issue by any means, but a thought. |
| 28 |
> |
| 29 |
> Ciao, |
| 30 |
> |
| 31 |
> -- |
| 32 |
> Seemant Kulleen |
| 33 |
> Developer and Project Co-ordinator, |
| 34 |
> Gentoo Linux http://www.gentoo.org/~seemant |
| 35 |
> |
| 36 |
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E |
| 37 |
> Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E |
| 38 |
|
| 39 |
|
| 40 |
|
| 41 |
-- |
| 42 |
gentoo-dev@g.o mailing list |
Archives