Tree cleanup

You might have not noticed it, but the tree is slimming down, and not just because me and Samuli are removing broken packages (it has been actually a while since I sent my last QA last rite), but also because I started removing duplicate files and moving some of them to the mirrors. Indeed, it seems like the tree has been accumulating layers of crap, like unused patches, duplicated files, huge files, and huge duplicated files, which are the worst.

Now, while a lot of big files are just there because they are legacy stuff, there are also files that have been added recently, and sometimes they are not even borderline with the warning (repoman warns for files bigger than 20K; if the size – not occupied space – of the files/ directory is over 20K, though, we ŕe already in trouble; I found files added recently that were well over 40K! This mostly means that my fellow developers ignore warnings from repoman about file size systematically and that is something that really upsets me.

But it’s not just that the problem; another common problem is that quite a bit of ebuilds are committed to the tree without even being tried, or without even thinking twice about it. And this is not something limited to a bunch of developers, but starts to feel like it’s also something quite widespread. If you use ~arch you probably noted the bump of sys-libs/db to 4.8 version, when stuff like Python, OpenOffice and APR failing to build; you might also remember that db 4.7 was kept in package.mask for quite some time to give time to the reverse dependencies to be fixed; that’s what is called QA, and that seems to be definitely lacking.

Sometimes, problems are due to ebuilds written or heavily modified by users and committed straight away, without thinking. For instance, the iscan ebuild I had to heavily edit for QA because it was committed more or less straight from a bug, and had the usual round of problems with autotools (configure executed three times — don’t say that autotools are slow, if packagers don’t even note that stuff), libtool 2 failures and overcomplex handling of USE flags (we have package.use.mask for that, stop using arch-conditionals!).

In general, I have to say that Gentoo’s QA is on a slippery slope and it’s falling down from time to time, even though me, Mark, Samuli and others are putting on great effort to get it right. Sigh.

I really need to find a way to get the tinderbox’s log cleared up by the way, making sure that only the last merge log (not unmerge!) of a given package/slot combination is kept, ignoring older previous merges (might have been fixed already) and older versions than those now available; if I could also note the revision of the individual ebuild, it would be even better, but that’d be quite too much I’m afraid, and it wouldn’t work quite as well.