Ahh shoot, I forgot Bugzilla takes out all > lines. This should have read:
> That's what I am doing and it's even better to have a separate colorgcc package. What? > Because otherwise you would have config files defining the same bits but gcc paths, which is insane (duplicate). I assume you're talking about colorgccrc point to the actual binaries instead of the alternativized symlinks, which you're right, makes no sense. Oh, but right now the alternative points to colorgcc, which wouldn't work. Ahh, but I see that the paths to the gcc binaries are also in /usr/bin/colorgcc itself, so I guess colorgccrc just lets you change those, but the lines for the compiler paths don't really need to be there in colorgccrc (they could be removed or commented out). > I am also removing alternatives from the colorgcc package. The program is called colorgcc, the user needs to use it explicitly. Well that's no good. Basically nobody will do that and it'll be like getting rid of it entirely :o( It shouldn't be necessary as long as there's a solution to the problem discussed above, and I think I proposed a sufficient one. > There may be one problem left though. e.g. user edited colorgccrc files. Just make /etc/colorgcc a config(noreplace) file. This should be OK, so long as colorgccrc is fixed in regards to compiler paths discussed above. __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
