#358 Please make some autotools guidelines.
Closed: Fixed None Opened 10 years ago by leamas.

The way we use autotools lacks proper guidelines. Without such GL informal documents and drafts are used with sometimes questionable results. This is bad, autotools are commonly used and partly tricky, mostly because of less than ideal upstream practices.

I understand that this has been discussed earlier and more or less failed to come to any conclusion because of different views on how to use these tools - basically if we should run autoreconf or not. However, this was discussed in [1] and I think we found an overall agreement here on this. That's certainly no GL, but perhaps a starting point.

I also understand that finding the resources to write this isn't easy. Nevertheless, they are needed IMHO.

[1] https://lists.fedoraproject.org/pipermail/devel/2013-June/184098.html


Replying to [ticket:358 leamas]:

The way we use autotools lacks proper guidelines. Without such GL informal documents and drafts are used with sometimes questionable results. This is bad, autotools are commonly used and partly tricky, mostly because of less than ideal upstream practices.

I understand that this has been discussed earlier and more or less failed to come to any conclusion because of different views on how to use these tools

Well, I don't know how to answer.

  1. The autotools are a set of tools with all can be used in different ways. All of these ways have different consequences.

  2. There are interdependencies between these tools and incompatibilities between different versions of these tools.

  3. There are interdependencies between autotool-user provided files (configure.ac, Makefile.am, Makefile.in, etc) and different versions of these tools.

  • basically if we should run autoreconf or not.
    autoreconf is a "big and dangerous gun" which might explode into your face, kill your pets and eat your family. It's NOT SAFE to use without understanding the tools underneath. It's designed to be a package author's (upstream) tool, who is supposed to test and evaluate the results.

As Fedora tends to ship the "bleeding edge", running autoreconf is fairly safe for packages, whose upstreams follow the "bleeding edge". The older a package's sources are (Debian packages typically are "old"), the more complex a package is, the more likely it is running autoreconf will be harmful.

Very oversimplified: autoreconf on Fedora is like running a "bleeding edge" compiler over old source code. It sometimes will work, but the older the code base is, the more likely it is to get stuck in problems and incompatibilities.

IMO, best practice is
a) to avoid autoreconf and to use the autotool generated sources upstreams bundle.
b) if regeneration autotools-generated sources is inevitable, use the version of the autotools upstream had used when generating their tarballs and use patches in specs.
c) ...

How is bundled prebuilt autocrap different from other bundled prebuilt crap (JARs, SWFs etc.) which we explicitly ban (and require built from their true sources)? It's a PITA to make any changes in those generated files.

In addition, both the prebuilt files (or rather the copied snippets they contain) and the files copied wholesale are subject to the same issues as bundled libraries, e.g. that bugs need to be fixed in every package that bundles the stuff. See e.g. the rpath mess.

We have had this discussion before e. g., see [1] [2]. Reading threads I tend to think that the overall conclusion is that this must be handled on a case-by-case basis. One could could argue that guidelines are not required then. My point is that they are even more needed in this situation, especially with controversial drafts etc floating around.

[1] ​https://lists.fedoraproject.org/pipermail/devel/2013-June/184098.html

[2] https://lists.fedoraproject.org/pipermail/devel/2011-July/153687.html

I wasn't aware of [1] at the time of writing. I presume the FPC is, but for others reading this I add the link.

[1] https://fedorahosted.org/fpc/ticket/329

FPC talked briefly about this at today's meeting. I'll try to make time to writeup a draft.

action abadger1999 to write up some guidelines based on past FPC decisions. It will allow both strategies.

To document the direction we want to take in case raptors get me and someone else has to pick this up:

  • Document both running autoreconf in spec file and running autoreconf and then patching configure/Makefile.in as valid strategies but point out the downsides of each
  • if you do run autoreconf, validate that what you've created works
  • "if it's not broke, don't fix it". Tell people that if you don't need to modify the build scripts then there's really no reason to run autoreconf

Tell people that if you don't need to modify the build scripts then there's really no
reason to run autoreconf

There is one: bogus lib64 rpaths (if e.g. a Debian libtool was used by upstream), which would otherwise require hacks to get rid of. In addition, running autoreconf right from the start also makes it easier to make changes to the build scripts later when you actually need them (e.g. because you have a patch that adds a new source file).

http://fedoraproject.org/wiki/Packaging:Guidelines#Removing_Rpath recommends the other means besides autoreconf of removing rpath. If you want autoreconf mentioned in the autotools section, I think the plan should be:

  • Have FPC evaluate whether to add autoreconf as a strategy to the Removing_Rpath Guidelines.
  • If that's accepted, link from the autotools section to the Remove_Rpath Guidelines as an example of when you could use autoreconf.

"""

Sometimes, the code/Makefiles can be patched to remove the -rpath or -R flag from being called. This is not always easy or sane to do, however.

"""

This might actually cover the Removing_Rpath Guidelines portion but it probably needs to be more explicit in order to be suitable for linking to the autotools section.

Here's the start of a draft: https://fedoraproject.org/wiki/User:Toshio/Autotools_(draft)

I realized, though, that I can't do justice to the patching approach as I don't use it. Someone want to help with that? Examples of things I don't know:

  • Do people run autoreconf and then apply that patch to the configure script in the spec file?
  • Or do people write their own targeted patch of configure and Makefile.in?
  • Have to also write the configure.ac/Makefile.am patch so that it can be sent upstream?
  • Still have to validate everytime you generate a new patch via autoreconf?

Isn't there something useful in [1] on the patching scenario?

BTW, IMHO some more background should make this easier to understand:
- configure.ac is not only about generating configure, but also other files.
- There's typically more than one Makefile.
- There's not not only configure.ac but also some Makefile.am.
- The flow Makefile.am -> automake -> Makefile.in -> configure -> Makefile, since this essential to understand where to patch.

[1] https://fedoraproject.org/wiki/PackagingDrafts/AutoConf

Yeah, that page looks like it could be adapted for the patching section.

If anyone would like to work on the patching section (or the rest of it too) that would be helpful. I will try to get to finish this if no one else steps forward but my time is limited.

So... we need someone to write up the guidelines and I'm afraid I have too many other large guidelines to get working to get to it (SCLs followed by python update). It was proposed last week that if no one steps up, we close this and someone can reopen once the guidelines are written.

So I'll close in a week unless someone unless someone works on the draft before then.

It's been almost a year longer than a week, so I'm closing this.

Login to comment on this ticket.

Metadata