On Thu, 2005-09-08 at 13:26 +0900, Horms wrote: > Hi Andres, > > In the course of using split-config I have noticed a small problem. In > some cases it is not safe to remove an option from a config, unless it > is removed gloablly. When I say not safe, nothing particularly > catastropic happens, but each time you run split-config, you have to > wade through a mountain of "this option was removed, what shall i do", > messages. To demonstrate this, try split-config on arm/rpc, twice. Do you mean *removed* or *disabled*? If you mean removed; I changed split-config to ignore removals, it should be in svn (unless I only committed it to a local bzr repo, or it got lost in the shuffle..). If you mean disabled; I haven't seen that problem yet. If it is the case, I'll take a look. > > The patch below should aleviate this problem, by adding an annotation > to the debian configs if a option has been removed, but is not > removed globablly. Cool; feel free to commit if you think it's suitable, the worst that can happen is I revert it if it's broken. > > Its my first peek into the world or ruby, so please forgive any > stupidity on my part. > This brings up something I've been meaning to bring up. Right now, we've got a mix of python, ruby, shell, and perl in svn. I'd like to standardize on a language. Naturally, we'll still need to have things that end up being run on the user's system in perl or shell (shell for things that can't use or are too simplistic perl, and perl for other things). However, for our standard tools to manage various things (configs, control files, etc), we should choose either ruby or python. I don't want to see perl used, since I don't think perl is suitable for large scripts, and is difficult to maintain. I'm comfortable with either ruby or python; I suppose it depends on what others are more comfortable with. If necessary, I can rewrite split-config in python; I've already started toying around w/ python scripts (see scripts/testconfigs). Preferences? Once we have a common language, we can have a common library as well (ages ago, I wrote half a Kconfig parser in racc; that seems like it'd be useful for all kinds of scripts, but I'm not going to spend any more time on it until we decide whether I should continue in racc, or use something python-y). -- Andres Salomon <dilinger@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part