Some packages ship from upstream with code generated from templates (such as bison, jison, gdbus-codegen, etc.). We have no formal policy or recommendation on how to handle this code, such as whether to require that it be regenerated as part of the RPM build or if it is acceptable to just use the pre-generated version from the tarball.
I think there is a spectrum of possible answers to a number of relevant questions here:
I think it's important that we be able to patch things as necessary, which does mean being able to patch the "source" of the autogenerated code. Which implies that we really need to have access to the the entire build chain.
I don't think there are clear answers to all of these. Currently I think the best interpretation of what the guidelines say is Q1: c, Q2: no, Q3: no, though there are some legal issues for GPL'ed code due to the phrase "the preferred form of the work for making modifications" which I don't think we want to get into here.
Personally for Q1, I lean towards '''b'''. For Q2 I say '''yes'''. For Q3, I say '''c'''.
If there's consensus I can throw together a draft.
Note that autotools falls into this category, and I'm not even sure I want to know if java/ruby do anything weird as std. here.
I think I'd prefer a 1.d. option: Do whatever upstream expects, unless you have a good reason.
I can buy that, except that really I don't think it would be common to know what upstream expects. I guess if upstream ships them, then you can intuit that they expect you to use them. However, my experience is that most of these things are generated at release time simply to reduce the dependency footprint of the source release. Often times if you want to package a snapshot or do some patching you have to end up generating everything anyway. So "what upstream expects" probably isn't going to be consistent in any case.
I also know there are issues surrounding autotools (which I don't really understand) that make any kind of guideline around this really tricky.
Even glossing over the first question, which could perhaps be considered a separate issue, I think that it is worth addressing the second and third.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-12-03/fpc.2015-12-03-17.00.txt):
Proposal: a new section immediately before "Spec File Naming:
== Use of pregenerated code ==
Often a package will contain code which was itself generated by other code. This often takes the form of configure files or parsing code generated by bison/yacc or lex/flex.
It is required that the original source files from which the code was generated be included in the srpm. Generally these files are part of the source archive supplied by upstream, but it may be necessary to fetch those files from an upstream source repository and include them in the srpm as separate Source: entries.
It is suggested, but not required, that such code be regenerated as part of the build process. The means for doing this are entirely specific to the individual package being built, but it may happen automatically if the necessary dependencies are present at build time.
Also, I did open https://fedorahosted.org/fesco/ticket/1514 some time ago.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-01-07/fpc.2016-01-07-17.00.txt):
A section on the treatment of pregenerated code has been added to the main guideline page.
Metadata Update from @tibbs: - Issue assigned to tibbs
Login to comment on this ticket.