I'm thinking about whether we should get rid of the distprep target, the
step in the preparation of the official source tarball that creates a
bunch of prebuilt files using bison, flex, perl, etc. for inclusion in
the tarball. I think this concept is no longer fitting for contemporary
software distribution.
There is a lot of interest these days in making the artifacts of
software distribution traceable, for security and legal reasons. You
can trace the code from an author into Git, from Git into a tarball,
somewhat from a tarball into a binary package (for example using
reproduceable builds), from a binary package onto a user's system.
Having some mystery prebuilt files in the middle there does not feel
right. Packaging guidelines nowadays tend to disfavor such practices
and either suggest, recommend, or require removing and rebuilding such
files. This whole thing was fairly cavalier when we shipped gram.c,
scan.c, and one or two other files, but now the number of prebuilt files
is more than 100, not including the documentation, so this is a bit more
serious.
Practically, who even uses source tarballs these days? They are a
vehicle for packagers, but packagers are not really helped by adding a
bunch of prebuilt files. I think this practice started before there
even were things like rpm. Nowadays, most people who want to work with
the source should and probably do use git, so making the difference
between a git checkout and a source tarball smaller would probably be
good. And it would also make the actual tarball smaller.
The practical costs of this are also not negligible. Because of the
particular way configure handles bison and flex, it happens a bunch of
times on new and test systems that the build proceeds and then tells you
you should have installed bison 5 minutes ago. Also, extensions cannot
rely on bison, flex, or perl being available, except it often works so
it's not dealt with correctly.
Who benefits from these prebuilt files? I doubt anyone actually has
problems obtaining useful installations of bison, flex, or perl. There
is the documentation build, but that also seems pretty robust nowadays
and in any case you don't need to build the documentation to get a
useful installation. We could make some adjustments so that not
building the documentation is more accessible. The only users of this
would appear to be those not using git and not using any packaging.
That number is surely not zero, but it's probably very small and doesn't
seem worth catering to specifically.
Thoughts?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services