Many packages use autotools (automake, autoconf, libtool, etc.) to generate their packages. In many cases, packages in Fedora are using bundled copies of the pre-generated Makefile and libtool scripts to build the packages.
First, I will make the claim that this behavior falls afoul of http://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries since the local copy of libtool in the tarball is a pre-built binary (the fact that it is a script is immaterial).
It's also an example of bundling, since we have a forked version of libtool to contend with, which may have security or bugs that the Fedora copy does not.
With this in mind, I would like to add language to the packaging guidelines to require that maintainers MUST run 'autoreconf -if' (or autogen.sh, as appropriate) if doing so does not break the build on Fedora. If doing so causes the build to be nonfunctional, the maintainer MUST open a BZ to track the issue (which should be kept open until it is fixed) and SHOULD contact the upstream to try and fix this.
I don't believe this process needs to be so heavyweight as to require an FPC exception.
-1
The autotools are designed to generate files which are to be bundled with a package (aka. generated sources).
The autotools are not desiged to be regenerate these pre-generated source. This sometimes works in trivial cases, but in many doesn't work.
Ralf: you're arguing the same flawed case that is used to defend the use of bundled code in packages. "Upstream decided that this is the exact version we work with, so we're going to bring it with us". I think this is a bit self-contradictory.
Also, a reference to Debian's policy (which has worked well for them): http://linux.sns.it/cgi-bin/dwww?type=file&location=/usr/share/doc/autotools-dev/README.Debian.gz
Of particular note: {{{ Basic summary of packaging source that uses autotools:
You have two good choices, and one bad choice for packaging upstream source which uses automake and autoconf and contains generated files:
Tolerate the big diff size, and run the autotools stuff before you create the debian source package. This is what I usually do.
Patch the autotools files (.in, .am) at build time, make sure all the build dependencies are 100% correct (hint: conflicting with autoconf2.13 is always a good idea if you're not using autoconf 2.13 and automake 1.4). This means that the autobuilders will have to rerun the entire thing, and so will the users, etc.
When you're doing a full dpatch-based packaging, this choice makes sense.
They are absolutely correct that not regenerating sources when libtool is in use is unacceptable. It leads to difficulty fixing issues like those seen in https://bugzilla.redhat.com/show_bug.cgi?id=978949
Replying to [comment:2 sgallagh]:
Ralf: you're arguing the same flawed case that is used to defend the use of bundled code in packages. "Upstream decided that this is the exact version we work with, so we're going to bring it with us". I think this is a bit self-contradictory. No, This is not self-contradictory. It's a side-effect of the limitations of reality.
A package which has adopted a source code generator 10 years ago cannot comply to the limitations and incompatiblities which have been added to successors of this code generator.
Also, a reference to Debian's policy (which has worked well for them): This is a lie. This policy does not work for them. Mailing lists are full of Debian packagers complaining about them hitting the limitations. They are absolutely correct that not regenerating sources when libtool is in use is unacceptable. It leads to difficulty fixing issues like those seen in https://bugzilla.redhat.com/show_bug.cgi?id=978949
Also, a reference to Debian's policy (which has worked well for them): This is a lie. This policy does not work for them. Mailing lists are full of Debian packagers complaining about them hitting the limitations.
The only way to address such cases is to handle them case by case.
I stay with what I wrote before: Very hard -1.
Replying to [comment:3 corsepiu]:
I really don't buy this. Your argument really sounds to me like we want to encourage upstreams not to fix their build systems so that they take advantage of the many and varied improvements offered by '''the same tools they are already using'''. This seems extremely wrong-headed. I'd much rather put in the requirement that they use the updated tools and work with the upstreams to fix their code so it's not so brittle.
Besides, my original proposal still covers this: it leaves an automatic exemption for packages that do not build successfully to continue behaving as they are, except that the package maintainer is required to open a bug to track the issue (and if this gets passed, I'll create a Tracker bug to organize these).
Furthermore, if this gets approved, I'll file a Fedora 21 System-Wide Change similar to what we did for the systemd conversion to encourage people to try and fix this and file those bugs if it doesn't work.
After much discussion this did not pass. There's a mixture of precedent, thinking that this would fall under the copylibs exception if it was viewed in the light of the bundled library rule, backwards compatibility problems in autotools, and the problem of autotools issues not showing up as build failures but unexpected differences in how the code is compiled all contributing to this decision.
tibbs noted that this is not a ban on packagers doing this if they want (there have been earlier proposals to ban the practice of running autotools in packages which have similarly been defeated in FPC in the past); it is merely declining to make it official policy that all packagers must attempt this.
Vote was: (-1:3, 0:3, +1:0)
Login to comment on this ticket.