#1159 Ban use of %configure in %prep
Opened 7 months ago by tibbs. Modified 4 months ago

It's been sort of an unwritten rule that %prep should be limited to unpacking, patching, moving source files into place and removing unwanted content (vendored libraries, prebuilt binaries, etc.) and that %configure should be called in %build and never in %prep.

There's now a PR open against redhat-rpm-config which enforces this: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/172

The questions for FPC are:

  • Do we care?
  • Should this be explicitly banned?

If the latter, a simple bit in the Macros section (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_macros) about %configure should be sufficient. (and I'll send a PR). Though it occurs to me that we really say very little about %configure, and that would be a good place to say other things in the future if we wanted to do so.


We should definitely do that and have a section about Autotools in our docs like we do for Meson and CMake.

I've always enforced this when reviewing packages. Few do it, max 5 cases over thousands of packages.

Metadata Update from @james:
- Issue tagged with: meeting

6 months ago

FPC was receptive to a ban, so I will work on a PR.

I do like the idea of having an Autotools section but to be honest I don't know what would actually be said in it. Autotools isn't exactly simple and there is more magic crammed into the %configure macro than ever before. Does that need to be discussed or is it sufficient to just say: "call %configure, %make_build and %make_install in the right places (never %prep); here's a template"?

That sounds good to me. The more specific the guidance, the likelier it is wrong in more cases, where autotools are concerned ... (since their usage is extremely heterogeneous ...)

Similarily, I've seen packages run autoreconf in %prep. Should that be discouraged? (It fails when you fedpkg prep without autoconf.

Sure .. I don't think people should run any build tools in %prep, but just basic shuffling things around so the sources, files, and directory layout is prepared (i.e. running programs like tar, cp, mv, unzip is expected, but running autoreconf is not).

IMO configure was out because that can call gcc to do tests ... autoreconf ... eh. I think it should be in build but I'm not as strongly for it.

+1 for banning %configure in %prep.

As for autoreconf, I always run it in %prep since typically it's required because of patches for autotools. It just generates configure - which otherwise you wouldn't need to touch - and it therefore makes sense to have it in %prep. It's not configuring the build, it's preparing the source tree.

I think running %configure in %prep is closely analogous to running %cmake or %meson; all of these are build system generators that accept configuration options and emit files consumed by the “real” build system (make or ninja). I don’t think anyone would argue for running %cmake or %meson in %prep.

As far as autoreconf is concerned, I have an aesthetic preference for only doing unpacking and patching in %prep, but I also don’t like doing other things there for the practical reason @churchyard mentioned: it increases the number of packages that have to be manually installed on a developer’s system to run fedpkg prep or fedpkg srpm. For autoreconf, this is at least autoconf/automake/libtool, but it can even include some -devel BR’s that provide their own m4 macros in aclocal, e.g. libgpg-error-devel.

For some context, we used to have some useful tooling which would try to run spectool -g and run the %prep phase of everything (in a relatively basic system without trying to install build dependencies). This might even have been pre-fedpkg. So from my perspective, there is utility in keeping the dependency set needed to run %prep as small as possible but I never really got around to proposing any guidelines to that effect. (And I'm not sure it's particularly useful to just say "try to keep %prep simple.")

Yes, %configure and the like do not belong in %prep.

On a related note: rpm >= 4.18 will have a new spec section %conf specifically for configuring the build. Of course it'll be a while before it can be used throughout Fedora, never mind EL variants, but just FYI.

On a related note: rpm >= 4.18 will have a new spec section %conf specifically for configuring the build

What is the usecase? Do you want to change Fedora policy to start using this feature?

As above ./configure is kind of weird in that it'll often end up compiling and running arbitrary programs, so separating it from build seems kind of weird unless you want to save the result of configure in some way.

%conf is primarily preliminaries for a future feature, and it'd be premature to start pushing Fedora policies around it now. Just wanted to mention it in now to raise awareness and to avoid perhaps decisions that would make its adoption more difficult later.

Configuration is a separate step from the build though, so even now it's beneficial for the same reasons that configure/make are separate, when working on a spec. Of course for --rebuild kind of use there's no difference.

Yeah we'll probably want to mention it when F37 progresses a bit. Someone will certainly be asking if it can be used but we certainly wouldn't want to change any examples and such until closer to the time F36 goes EOL (if at all).

But I imagine we will want to work on using that build templating feature soon after it's available,

Login to comment on this ticket.

Metadata