I think that there are few "classes" of pregenerated code (depending on what it is used for) that deserve completely different handling. 0. Build scripts 1. Documentation, artwork, fonts, and other "content" 2. Anything code that is executed by users For clases 0. and 1. we have to be able to verify that code is not doing something malicious, but IMHO being able to regenerate is not really required. It's definitely "nice to have" of course. In case of class 2 our ability to fix issues hinges on being able to regenerate from the source code, so, IMHO, we should not use pregenerated sources. One question would be whether to allow using pregenerated sources in class 2 if it was possible to regenerate stuff "in principle". I think we shouldn't allow that, to ensure that we have mechanism to build the package from original sources at any time. The time to work on the build system is during initial packaging, and not when an issue has been found and needs fixing. An exception could be made if the pregenarated sources are really small and simple and can be fixed by hand without too much trouble. I don't know if such cases exist in practice. On Fri, Dec 18, 2015 at 02:13:54PM -0500, Stephen Gallagher wrote: > * Code produced by gdbus-codegen (class 2) > * Code generated by a YACC implementation such as bison or jison. (class 2) > * Autotools scripts such as libtool (class 0) > * Man-pages that are built from templates such as Docbook. (class 1) > * Minified JavaScript or CSS Somewhere between class 1 and 2. I'd put CSS in class 1, and even treat javascript which is only used locally (e.g. in documentation packages) the same. OTOH, JavaScript which is served remotely should be minified during the build process. We have minification software packages and we should make use of it. > There are many other examples, but those are readily called to mind. > This brings up several important questions: > > 1) Do we require that the original data used to generate this code is > included in the SRPM? > > 2) Do we require that whatever tools are necessary to generate this > code is packaged in Fedora (with all the legal and policy requirements > that this implies)? If we do not, do we require that the code used by > upstream is free software? > > 3) Do we require that building in Fedora always requires regeneration > of this code from the original data? IMHO, yes — for all three. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
