Tom Lane wrote:
> That sounds more like dogmatism than practical thinking. It's common to
> pre-generate some of the files in a distribution tarball, just so that
> users aren't required to have specific tools in order to build the code
> (unless they want to modify the input files for those tools, of course).
> This is not more nor less than simplifying life for your users.
Users shouldn't be building the code directly from the tarball, that's what
packages are for, and there it's just a matter of adding a BuildRequires.
Shipping generated crap just to avoid a BuildRequires is unhelpful and
actually makes it harder to modify the affected files (e.g. because nobody
actually tests whether they can be regenerated with the current versions of
the tools).
> The autoconf case is exactly this, really. In principle you could
> distribute only configure.ac and require recipients to run their own
> copy of autoconf in order to build. In practice it's better to ship
> the generated configure script too. That makes for one less build
> dependency and one less potential source of version-skew issues.
… until the day where you need to modify configure.ac and then hit those
exact version-skew issues, because nobody else tested regenerating the file.
> However, anybody who has a need to adjust configure.ac is going to do so
> and then run autoconf locally.
… and watch it crash and burn because nobody tested it.
The best way to ensure that the file can be regenerated whenever needed is
to just ALWAYS regenerate it, then you notice immediately when regenerating
it stops working, not only the next time you need to change it.
This is exactly the same argument as for why fixing FTBFS bugs is important.
> It doesn't seem to me to be sensible to expect Fedora packagers to do
> differently when they need to adjust the configure script.
Well, it's really unfortunate that autotools upstream is encouraging that
stupid practice of shipping generated files and optimizing the design of
their tools for that broken use case (e.g. through the use of shell, along
with an unreadable mess of workarounds for various buggy proprietary shells,
instead of a decent implementation language, and by giving insufficient
importance to backwards compatibility).
Really, building from the actual source code shouldn't be something expected
of only Fedora packagers, but of EVERYONE.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
