Archive for the ‘CCP’ Category

Why GNA! is better than Savannah

Sunday, April 23rd, 2006

In the beginning there was…blah, okay I won’t go that far. Though, the first host provider I used was SourceForge.net. I used that for three projects:
GFSGL, GFSI and GoldenFiles. Mostly random stuff there, not too large projects.

Then one day I thought about this and well, using a proprietary website to produce and manage a free software project makes…well…no sense. So then I started looking at the alternatives. I landed on Savannah. My first Savannah project was GoldenPod. Followed by the (mostly dead) GoldenBackup (no link due to no website nor release, it does have a CVS though). Then followed by the common configuration parser. Then I had my disagreements with Savannah (as some of you might remember).

Then I started looking at GNA! which I am now using for my most active project, Day planner. Now what does GNA! have to offer that Savannah doesn’t?
Well, it offers easier access to the downloads directory, I can simply rsync/scp stuff from my box to the GNA! download directory. It also has SVN which is imho MUCH better than CVS (I’ve never used Arch, so I won’t say anything about that). They also offer download/website statistics, something Savannah doesn’t. The only plus of Savannah I can find is some of their admins. I’ve spoken with a few of them and they where very nice, savannah also has an IRC channel (#savannah on freenode) which is rather nice. Though currently, I’ll take my GNA! without my Savannah if that is possible thank you very much.

CCP 0.3

Monday, January 23rd, 2006

CCP 0.3 is out! The major new feature in this release is the addition of automatic uncommenting support.
CCP will now try to detect which options the user has uncommented from –oldfile and automatically uncomment them in the resulting –newfile. This should *greatly* decrease the amount of oprhaned options that occurs. Also added is an automatic testsuite to avoid regressions between versions and a –bug option that outputs a file containing useful information that can help fix a bug or solve a problem.

CCP can be downloaded from http://ccp.nongnu.org/download.html

CCP 0.2 released

Saturday, January 7th, 2006

This version contains multiple bugfixes, some which could cause various configuration files to not upgrade correctly. Among others, it fixes bug #15364.
In other news, the first package using CCP in Mandriva is out – which is squirrelmail :)

CCP 0.1 released

Tuesday, January 3rd, 2006

CCP version 0.1 has been released!
It can be downloaded from http://ccp.nongnu.org/download.html.

It’s also in Mandriva Linux (cooker) contrib.
The first package to use it is squirrelmail, which I updated today.

CCP can now autogenerate templates :)

Monday, January 2nd, 2006

CCP can now autogenerate the templates, so it’s pretty much ready for real-life testing.
Here’s the same example used in earlier posts.

[0 zerodogg@drizzt ccp]$ cat example.conf
# Example configuration file
SystemVersion = 0.1
Mode = public
Extensions = off

[0 zerodogg@drizzt ccp]$ cat example.conf.rpmnew
# Example configuration file
SystemVersion = 0.1
Mode = private
Extensions = on
AllowUsers = yes

[0 zerodogg@drizzt ccp]$ ./ccp --oldfile example.conf --newfile example.conf.rpmnew
Merging changes between "example.conf" and "example.conf.rpmnew"...done

[0 zerodogg@drizzt ccp]$ cat example.conf
# Example configuration file
SystemVersion = 0.1
Mode = public
Extensions = off
AllowUsers = yes
[0 zerodogg@drizzt ccp]$

A working copy of CCP

Thursday, December 29th, 2005

CCP (as I wrote about earlier) now has a project on savannah. It now works! It can be downloaded from the CVS repository.
However, it doesn’t use libconf yet, and thus only supports key = value files. It also doesn’t know how to create the templates by itself so those have to be written by hand for now (but this should be easy(ish) to implement I think).

Like i said it currently supports key = value files. Any format will do. It can for instance handle any of the following:

$Key = Value;
$Key=Value
$Key='Value'
$Key="Value"
$Key ="Value"
Key = Value
Key=Value
# Comment
: Comment
; Comment
[Section header that gets ignored]

It doesn’t support comments on the same line as a config option, but this can probably be added at some later time.
I haven’t written any documentation yet – but here’s the same usage sample I used before (edited to suit the way ccp now works).

/etc/example.conf:

# Example configuration file
SystemVersion = 0.1
Mode = public
Extensions = off

/etc/example.conf.rpmnew:

# Example configuration file
SystemVersion = 0.1
Mode = private
Extensions = on
AllowUsers = yes

/usr/share/example/config.ccptemplate:

# Example configuration file
SystemVersion = {CCP::CONFIG:SystemVersion}
Mode = {CCP::CONFIG::Mode}
Extensions = {CCP::CONFIG::Extensions}
AllowUsers = {CCP::CONFIG::AllowUsers}

Command:

$ ccp --template /usr/share/example/config.ccptemplate --oldfile /etc/example.conf --newfile /etc/example.conf.rpmnew
Merging changes between "/etc/example.conf" and "/etc/example.conf.rpmnew"...done

Resulting /etc/example.conf:

# Example configuration file
SystemVersion = 0.1
Mode = public
Extensions = off
AllowUsers = yes

Common configuration parser (CCP)

Thursday, September 29th, 2005

I’ve been thinking about ways to upgrade configuration files lately and I’ve come up with the idea for CCP (common configuration parser). The idea is to take one template file, one old configuration file, one definition file and one mode. To give a better example of how this would work:
ccp --type basic --mode rpmnew --template /usr/share/example/config.ccptemplate --oldfile /etc/example.conf
This here would tell ccp to work with the configuration type “basic”, in the mode rpmnew (upgrade if a rpmnew file is found), use the template file /usr/share/example/config.ccptemplate and upgrade the old configuration file /etc/example.conf. Settings not found in /etc/example.conf would then be taken from /etc/example.conf.rpmnew. For an even better understanding of the idea lets look at it some more. For example before the upgrade /etc/example.conf could look like this:

# Example configuration file
SystemVersion = 0.1
Mode = public
Extensions = off

/etc/example.conf.rpmnew could look like this:
# Example configuration file
SystemVersion = 0.1
Mode = private
Extensions = on
AllowUsers = yes

/usr/share/example/config.ccptemplate could look something like this:
# Example configuration file
SystemVersion = $CCP::CONF:SystemVersion
Mode = $CCP::CONF::Mode
Extensions = $CCP::CONF::Extensions
AllowUsers = $CCP::CONF::AllowUsers

ccp would read these files and write the new /etc/example.conf as:
# Example configuration file
SystemVersion = 0.1
Mode = public
Extensions = off
AllowUsers = yes

More advanced files could be supported by different –type’s. This is still mostly an idea that’s growing in my head but this is the basic thought of it. Quite possibly –template wouldn’t be needed and it would autogenerate a template on-the-fly by using the .rpmnew (or whichever file is the new one – ccp is not rpm specific, it is just one of multiple modes it would be able to run in).