Release Tools

February 28, 2008

I’ve added some more functionality to the new LCFG release tools, in particular you can now use lcfg-reltool via a Makefile with ease.

Here are the setup details:

/* dependencies */

#include <ed/options/moose.h>
!profile.packages     mEXTRA(perl-Data-Structure-Util-0.12-2.fc6\

/* the buildtools packages */

!profile.packages     mEXTRA(perl-LCFG-Build-PkgSpec-0.0.4-1/noarch\

Once you have that installed you just need this in your Makefile:

include lcfg/

and you can do the usual make release, make majorversion, make minorversion with everything driven from lcfg.yml.

There is still lots more stuff to add to the buildtools suite for LCFG components but this should be quite useful for other software. There have also been changes to the LCFG-Build-PkgSpec toolset, the lcfg-pkgcfg script is now much more useful, here’s a synopsis:

           lcfg-pkgcfg --get=name

           lcfg-pkgcfg --get=name --in ~/cvs/lcfg-foo

           lcfg-pkgcfg --get=name --in ~/cvs/lcfg-foo/lcfg.yml

           lcfg-pkgcfg --set schema=2 --set license=gpl

           lcfg-pkgcfg --skeleton

           lcfg-pkgcfg --skeleton --set name=foo --set version=1.0.0

           lcfg-pkgcfg --in META.yml --out lcfg.yml


February 26, 2008

During the last weekend I attended FOSDEM in Brussels along with about 4000 other Free and Open Source software geeks/hackers. It was great fun with lots of nice beer and chocolate, I even managed to attend some interesting talks!

Particularly worth mentioning, I went to two talks on CMake, the first was by Bill Hoffman and was mostly an introduction to the possibilities the system provides. The second was "CMake: News and Secrets" by Alexander Neundorf who is a KDE developer. KDE are probably the biggest user of cmake and this talk covered a lot of the new features which will be available in CMake version 2.6, which is due out any day now. The new version will really be a huge improvement and provides many features which could be useful in making the buildtools project truly successful. The best bit was that after the talk I collared Bill Hoffman to ask how I could get hold of a copy of the "Mastering CMake" book since it has been out of print for ages. He immediately proceeded to give me a copy of the new edition, which is updated to cover version 2.6, hot off the presses all the way from South America!

Other talks I attended include one on Perl6, given by Patrick Michaud who is one of the lead developers of Perl6 and Parrot (which is the VM upon which Perl6 will run). The perl6 talk did not include much that was, for me, revelatory. It is pretty clear that development and maintenance of Perl5 is going to continue pretty much indefinitely and that Perl6 is going to be a completely new language. I did get the feeling from the talk though that the project has hit a critical point at which the rate of development is now accelerating rapidly. When they say that there should be something usable at the end of this year I actually felt, for the first time, that this is more than just them being over-hopeful. I am a little wary about recommending Perl6 to anyone yet as I feel that the huge number of ways to achieve the same thing in the new language are going to lead to great difficulties when developers want to read, understand and modify each others code. Any large-scale multi-developer project is going to require strict coding guidelines and a great deal of self-control from the developers to avoid complete confusion and incomprehensibility. That said there are clearly some huge improvements in the language, it is definitely much more consistent, a lot more powerful in terms of working with basic data structures such as lists and the object-oriented programming support is light years ahead of that provided in Perl5. Given my usage of Moose I am getting a feel for the new approach and I think I can say that it will work very nicely.

First release

February 19, 2008

As part of the buildtools project I’ve now tested and documented LCFG::Build::PkgSpec, here is the RPM and the SRPM. If you want to have a play you will need some extra packages installed on your machine. On DICE FC6 you can use ed/options/moose.h to pull in most of the stuff. You will then need to add these as well:

!profile.packages     mEXTRA(perl-Data-Structure-Util-0.12-2.fc6\

At this point the main two useful things to look at are the scripts lcfg-cfg2meta and lcfg-pkgcfg. If you are interested in how to use Moose take a look at LCFG/Build/, hopefully it is fairly clear and not too scary!

One cool thing I have just discovered is that because the lcfg.yml is similar to the META.yml used for Perl modules on CPAN, you can do this to generate a basic LCFG metadata file:

perl -MLCFG::Build::PkgSpec -e '$spec = LCFG::Build::PkgSpec->new_from_metafile("META.yml"); $spec->save_metafile("./lcfg.yml")'

Testing, testing…

February 19, 2008

I’ve been adding tests to one of the Perl modules I have written for the buildtools project. This is for two reasons, firstly, it’s good to have tests for the code as it helps spot bugs and makes it easier to add further functionality safe in the knowledge that none of the earlier work has been broken. Secondly, I wanted to try out a few testing strategies which might be useful when it comes to the LCFG core refactoring project. I have been playing with Devel::Cover which measures how much of the code is covered by the test suite – here’s some results. My initial trials suggest this is quite a good strategy as it encouraged me to think about all the different pathways through the code and it did find one rather nasty bug.


February 13, 2008

I’m going to FOSDEM, the Free and Open Source Software Developers’ European Meeting


February 11, 2008

I’ve now put together a first attempt at the “release tool” part of the LCFG buildtools project. This should allow developers to use a CVS repository and “standard” LCFG/DICE release version practices without being tied into all the other parts of buildtools. This also helps show that switching to a new meta-data file (lcfg.yml) as a replacement for parts of works rather well.

There is currently a Perl module, LCFG::Build::PkgSpec, which can be used to load and write out the meta-data file, this provides a reasonably nice interface to this specification. For example:

my $spec = LCFG::Build::PkgSpec->new_from_metafile('./lcfg.yml');
print 'Package name is: ' . $spec->name . "\n";
print 'Version Control System is: ' . $spec->get_vcsinfo('type') . "\n";

There is also an interface class for VCS handlers, LCFG::Build::VCS, this specifies what attributes and methods must be implemented. There is currently one Perl module, which supports CVS, which implements all the required functionality, LCFG::Build::VCS::CVS. Hopefully, with a bit of documentation, it will be relatively easy for developers to code a module to support their VCS of choice.

The release tool is used to carry out the three version altering functions previously done via the buildtools Makefile: release, majorversion, minorversion. It supports checking for uncommitted files and generating the ChangeLog file from the VCS log. For example:

lcfg-reltool --release ~/cvs/lcfg-foo
lcfg-reltool --majorversion .

None of this is documented or packaged yet, that’s the next stage, after that I will be looking for early adopters to give it a whirl. To ease adoption I intend to create a tool which will take the and generate the lcfg.yml meta-file.

Just to note, these modules are written using Moose it’s great!

perl module conflicts

February 1, 2008

In the process of packaging up the latest Moose and Class::MOP perl modules (and all the other dependencies) I discovered that the build process of some of them is asking for a version of Test::Simple which is more recent than that which is on SL5. Normally this would not be a problem, I would just grab the SRPM for that module, drop in the new source tar.gz and update version/changelog accordingly. There is a problem though with Test::Simple and some other modules as they are included as part of the RHEL/SL core perl package. Building my own package puts the perl modules into different locations but the manpages should go into the same directory /usr/share/man/man3 so we end up with file conflicts. I don’t see an easy way to resolve this issue and with the long lifetime of SL5 we are almost certainly going to be in this situation several times. At the moment this is not an important issue but what happens when we really need a newer version of a core module?

As an aside, it is interesting to contrast this with how Debian handle the problem so much better. The core versions of the modules are put into /usr/share/perl/5.8.8/ and /usr/lib/perl/5.8.8 (replace 5.8.8 with the current version of perl on any Debian system) and non-core modules go into /usr/share/perl5 and /usr/lib/perl5. They use the same manpage directory so file conflicts are avoided by the core versions using a .3perl file name suffix and non-core versions using the .3pm suffix. Why this is not the standard approach everywhere I cannot understand.