This Time Self-Hosted
dark mode light mode Search

Maintainer mode

Developers happen to edit and a lot during the development of any software. For this reason, a long time ago, autotools included a support called maintainer mode.

When maintainer mode is active, at a change to those files, as well as other autotools files, the proper tool is called (autoconf, automake, etc) to rebuild the whole series of files. This is useful because a simple make call does almost everything for the developer.

Recently, though, maintainer mode is no more optional by default, but it’s instead force-fed on every project, unless AM_MAINTAINER_MODE is explicitly called in the file.

This is all well and good, so why am I talking about this? Well because maintainer mode is bad to use in ebuilds. If you patch a or configure file, and you don’t explicitly rebuild autotools, maintainer mode will do it for you, but it causes a few problems this way.

The most annoying problem for users is that if the maintainer mode is triggered by an edit to, the build will run ./configure twice. It’s boring enough to run once.

But more problems arise for instance when a new version of autoconf or automake is released. Because in that case the versions will not be the same between the original and the one that would be built, aborting the whole build (see my autofailure guide that reports that for instance).

Also, if you leave the task up to maintainer mode, it won’t even take into consideration the WANT_AUTO* variables that we use to force a particular version of autoconf and automake, so you’ll have automagic dependencies. And most likely you’ll forget to add autotools to the dependencies of the ebuild.

Okay so we know why maintainer mode is bad, how do we make sure that ebuilds don’t trigger maintainer mode? Beside the fact that developers should know what they do, by rebuilding autotools explicitly when patching the files, it’s worth looking “postmortem” if an ebuild triggered the maintainer mode rebuild. It’s actually useful because sometimes upstream is crazy and fixes the tarball without going through make dist and maintainer mode is triggered for unpatched vanilla tarballs too (in that case you should rebuild autotools explicitly anyway).

To check if a build triggered maintainer mode, you can just grep the build log for the string missing --run, that is the announce that maintainer mode was triggered. If that’s the case… it’s time to file a bug to latch to this tracker.

I suppose I’ll have to fix bugs on a few more packages I don’t use or care about myself directly in the next weeks. Sigh, I need the new box.

Comments 4
  1. $ grep missing --run /dev/nullgrep: unrecognized option `--run'Usage: grep [OPTION]... PATTERN [FILE]...Try `grep --help' for more information.

    …I guess it works better with the quotes 😉

  2. The string is without quotes, the parameter has to have them 😉 My note was to avoid people using @grep ‘”missing –run”‘@ which wouldn’t get you anything useful 🙂

  3. Really not sure if this helps or if these are just known bugs… I’ve grepped my portage logs for this machine that has been installed just a few days ago. You might see it here:…Also, you’ve marked bug 225833 as a problem related to “maintainer mode”, but its log does not contain “missing --run“.

  4. For reference, many bugs were also filed for cases when not only was patched, but also Or configure and both were patched. I mean they were filed when this was done at all, and especially when an eautoreconf was not done.This is wrong. There is no reason to cause eautoreconf slowness on all users for no technical reason and no proof it’s necessary. I covered this at… but Diego has not answered.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.