May binaries be built from generated "source" code?
 

=?ISO-8859-1?Q?Bj=F6rn?= Persson <bjorn@xn--rombobjrn-67a.se> writes:
> The Packaging Guidelines require that all binary programs and libraries be
> built from source code. How should this requirement be interpreted when some
> of the "source code" is itself automatically generated from other sources?

> [ details snipped ]

> Thus, none of the stated reasons seem to be relevant to this case, and I can
> see only one thing that could mean that I have to run the code generation as a
> part of the build, namely the term "source code".

You are overlooking one good reason for running the code generator
during package build: it ensures that what you compile actually matches
the sources it's claimed to be generated from. I've seen more than a
few cases where allegedly-automatically-built derived files shipped in
an upstream tarball were not up to date.

Now, whether it's worth doing that during package build is a tradeoff.
You have to think about what are the odds that this particular upstream
could screw up in that fashion; depending on how much you know about
their tarball creation and testing process, you might legitimately
conclude that the odds of this scenario are too small to worry about.
(Or you might be able to convince yourself that if the files *were*
out of sync, you'd get a compile failure; this seems possibly relevant
here, depending on how tightly tied these files are to the GTK+ API.)
And you have to consider how much time it adds to the package build
and whether the code generator's own needs will materially bloat the
package's BuildRequires footprint. These costs are probably
substantial, else upstream would not have chosen to ship derived files
in the first place. It might be worth it, or it might not.

Anyway, this is just to point out that regenerating derived files does
sometimes have practical value, quite independent of how narrowly
somebody wants to read the "build from source" policy.

regards, tom lane
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

May binaries be built from generated "source" code?
 

Tom Lane wrote:
> You are overlooking one good reason for running the code generator
> during package build: it ensures that what you compile actually matches
> the sources it's claimed to be generated from. I've seen more than a
> few cases where allegedly-automatically-built derived files shipped in
> an upstream tarball were not up to date.

I'm aware of that. I didn't mention it because it wasn't mentioned in the list
of reasons for this policy.

On the one hand the generated files might be outdated. On the other hand they
might become *too* up to date if I regenerate them. There has always been
version skew between GTKada and GTK+ in Fedora, and it will probably remain
that way. It has at times been necessary to patch GTKada to get it to build
with a newer GTK+. If I take the GIR file from Fedora's GTK+ package and feed
that to the code generator, then there will also be version skew between the
generated files and the hand-written parts of GTKada, which might be a problem
or not depending on (among other things) how stable the GIR file is.

If it turns out that I have a choice, then I'll try to figure out which
approach gives a lower risk of problems, but first I want to find out whether
the policy allows me a choice at all.

Björn Persson

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

May binaries be built from generated "source" code?
 

Tom Callaway wrote:
> It is my interpretation here that you do have a choice, but I would
> strongly encourage you to generate the source code on each build unless
> there is a specific (and notable) downside to doing so.

OK, thanks.

Björn Persson

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging