I’ve seen a lot of people thinking that the split between src_unpack and src_compile functions is mostly useless, as they can’t find any good reason for not patching during src_compile.
There are, though, a few ineresting and useful reasons for that, which I’ll try to explain here so that they can be put up to debate if needed, and at least unofficially documented in public.
The first obvious reason is that, if I am to check someone else’s package for a bug that I might be involved in (for instance if I maintain the backend library causing the failure), the easyest way for me to look at the source where the error is would be to just run ebuild foo-1.ebuild unpack and then check the source out. If patches are applied during src_compile phase rather than src_unpack, then I’d be looking at the wrong sources, maybe looking at the wrong line number (this actually happened to me a couple of times before).
But this is true even for non-human tests. Take for instance the default-bsd profile. That profile has a very simple check for a very broken source file, that would compile, and then fail at runtime. This is very unfortunate, but might be very widely used because it’s part of gnulib. The test is done at the start of the compile phase, so to at least catch most of the use cases.
If a software has a broken gnulib, and the patch to fix that was applied during compile phase, then the test will trigger false positives, as the patches wouldn’t be applied, yet. Even worse, if the software is not using gnulib out of the box, but the support for gnulib is patched in, for instance because it’s used by an half-fork by Debian – metamail comes to mind -, and the patch is applied in src_unpack, then the sanity check will let the build compile, while it shouldn’t have.
But this relates to patch, while my entry titles “A good reason to run autotools during src_unpack”. In truth, what I said applies to autotools exactly for the same reason.
You can’t really do any sanity check using bashrc on autotools at the moment because a lot of packages re-run them during src_compile phase rather than during the src_unpack phase, so finding known-broken packages is difficult. I’ve been thinking about resuming the work on autoepatch, but for that to work, we’d have to be able to be able to properly check after src_unpack, and expect not to have autotools ran afterward.
At the moment one of the biggest violators of this idea is KDE, and that’s also partly my fault for not looking for a better way to handle it. But beside that, if you know of anything that runs autotools during src_compile, it’s a good idea to submit patches at least to the latest ebuilds to move the run in src_unpack at least. Same for stuff patching during src_compile.
I suppose one way to fix this would be to start launching QA warnings about use of autotools.eclass functions during non-unpack phases, as well as epatch. Or we could try with developer-designed bashrc entries that mark all the source file as read-only after src_unpack phase.
Suggestions about this are welcome as usual. More work will certainly follow.
Update: I’ve talked with Halcy0n, the current QA team leader, and I’ve now added a warning when the autotools.eclass functions are ran outside the unpack phase. I suppose I should say to feel free to report bugs about those ebuilds from now on.
Good work. Patching should indeed be done before the compilation and moving it all to src_unpack seems like a good idea since well we do not have a src_patch :PGood that the warning are added which will speed up the process of all ebuild moving the patches to an other section.
Yeah we don’t have src_patch but we have src_prepare 🙂
unpack, patch/prepare, and compile should really all be separate phases. i can’t count the number of times i’ve gone through ebuilds commenting out epatch lines and sed calls.