Introducing autoepatch

As I blogged before, I started the actual work on autoepatch, an implementation of the kind of patching that elibtoolize do already, but outside ebuild scope.

The idea is to be able to run it after src_unpack so that the code is always patched, even when the maintainers forgot to call elibtoolize, and even when elibtoolize is called before autotools are ran (as long as their are called in src_unpack as they should be). One of the advantages is that you have not to restrict on the size of the patches as they are carried through rsync and gentoo-x86 module, and the idea was to make sure that we could also use it to patch some other files, not limited in scope to libtool patches (two things I can think of are KDE admindir and configures to be patched to avoid hidden visibility to be enabled when not the case, to always allow to disable aRTs if not used, and to be fixed with respect to autoconf version; and the fixage for packages that needs an LC_ALL for flex tests).

We discussed about this idea with Mike (SpanKY) for a while in the past, but nobody had time, or a good enough idea, to start working on it; as I start to feel the need to cleanup KDE’s eclass for the future, I decided to pour some time on this; the result is that the autoepatch repository is now available, and a basic implementation is now available. I’ve added support for the fbsd-conf patch (that I wrote myself so I know well enough), for a KDE admindir patch (for Autoconf 2.6) and for a non-patch, an extension I desired to further simplify kde.eclass, that allows a “patchset” to actually represent a script that’s run on some kind of targets; in this case it’s a script that transform one of the KDE’s admin scripts to a dummy version that allows us to use our own autotools wrappers.

Beside the ability to apply larger patches (that’s somewhat difficult to do anyway as they rarely are generic enough), the approach of having the patches (and the code to patch them) in its own package, allows us to add patches that needs to be tested, or change the code in a still not totally tested way, without breaking the stable: while a change to libtool.eclass, kde.eclass or the ELT (no, not Every Little Thing) patches themselves currently in the tree would apply at the same time to all the users, and thus might end up breaking stuff around, if we have a package with the data on it, we can get through the usual ~arch time before stable.

Now the problem is just to port all the elibtoolize patches to autoepatch, and decide whether we still need extra parameters to the command to enable some of the patches. At the same time, I’d like to cleanup libtool.eclass so that it can be maintained, as we cannot make use of autoepatch at least until Portage supports it (and it will probably be 2.2 or something like that, not the current release candidate for sure) and we can’t get rid of the use of libtool and similar till that’s stable for a few months at least (as the change is not going to suddenly break everything, but would just miss some features and bugfixes , it should be enough to wait for 6 months, if a KDE user get an autoconf failure I can just tell them to shut up and update portage 🙂 ).

Also, I’m having some big troubles trying to find a way to document how autoepatch works; I’m a firm maintainer that software and practises have to be documented, as you cannot always be around to fix and enact them… and especially if I’ll retire (I’m still thinking of it, although I want to thank all the users who supported and continue supporting me, you’re the reason I always endured my work.. and the only reason at this point I can consider enduring it more still), I want autoepatch to be a simpler piece of code to maintain compared with the current libtool.eclass, who almost only Martin (Azarah) has a clue about, and he’s MIA for a while now. Similarly this applies to kde.eclass that’s a real mess, and should have been modularised a long time ago.