How to ease maintainance a bit

A foreword, this post is mainly aimed at fellow devs or people doing a lot of ebuild work.

As many of you might know, bumping ebuilds is often not the hardest thing to do but to ensure a good QA, a number of little things have to be checked. There are various ways to go with QA, in no specific order:

  • build with stricter package manager settings than usual (think FEATURES=”test stricter”)
  • carefully read/grep throug build.log (a lot more tedious)
  • verifying some files don’t contain known bugs (gtk-doc, intltool)
  • check that the user just gets the locales s/he asked for
  • check that no lib is using a built-in when it should use a system lib
  • check that RDEPEND/DEPEND actually match what the ebuild needs

and there is obviously a lot more that could go wrong that you don’t always think about. Sure that’s what ~arch and the infamous tinderboxes are for, some might say, but what if you could check for most of this with no extra cost for you than renaming the ebuild and trying to build it. Here comes the portage hooks (don’t know if other PM supports this).

Let’s take a real world example, recently intltool had a seriously buggy release (filled as gentoo bug #577133) and now most upstreams using intltool are shipping tarballs with these broken rules. With portage hooks, I wrote a little snipped that would tell me if there was not enough or actually too much locales installed for a given LINGUAS setting (ok that’s not exactly it, but let’s say it works this way). Then collected a list of md5sum of problematic files and wrote the following in /etc/portage/bashrc:


post_src_prepare() {
if [ ! -e "${S}/po/" ]; then
return 0

checksum=$(md5sum "${S}/po/" | cut -f1 -d' ')

cat >> $tempfile <<EOF

if grep -q "$checksum" $tempfile; then
eerror "Bad intltool rules detected"
die "Bad intltool rules detected"

And then any package using those bad rules will just die after src_prepare. No wasted time building broken stuff anymore. This example is obviously not perfect, yadi yada, but it’s just here to show a lot can be achieved without touching portage code directly. Actually interesting tests would probably be gladly integrated into a PM so don’t hide it if you write some. I’ll try to drop a rewrite of this using my git hooks model in my dev space if there is interest in it.