On Fri, 26 May 2000, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > /lib/cpp -M -I. -I../backend executor/spi.h |xargs -n 1|grep \\W|grep -v ^/|grep -v spi.h | sort |cpio -pdu
$RPM_BUILD_ROOT/usr/include/pgsql
> > This could easily enough be included in the make install, couldn't it?
> > (Tom? Anyone?) I realize that GNU grepisms (or is \W common?) are
> > used above,
> That's just the tip of the iceberg of the portability problems in the
> above. If you want to propose that we actually do something like that
> during 'make install', you're gonna have to work a lot harder.
:-) I expect no less (than to work harder, of course....). Why not do
something like that, other than the 'out-of-sight, out-of-mind' problem? Or,
to put it far more bluntly, the SPI installation is very broken if the SPI
developer has to go around manually installing header files that make install
should have automatically taken care of.
> (However, as a non-portable trick for getting a list of files that need
> to be included in a hand-generated makefile, it's not bad.)
I take that as high praise :-). No, really it IS a quick hack -- I got tired
of generating the list by hand, so I automated it. And, when the list shrinks
down to nearly nothing (10-15 includes, maybe?), I won't have to change a thing.
> The more serious problem is "what else might an SPI module need besides
> spi.h".
What else indeed. Isn't spi.h the exported SPI itself? We seem to have a very
poorly defined line between exported and private interfaces -- back to my point
about the assumption that the whole source tree is available for any little
program's whim (such as the regression test suite, which was _interesting_ to
get working without a bunch of the source tree around.) Mike Mascari may be
able to answer more about what SPI programs require, as he is doing SPI
development.
> Also, it disturbs me a lot that spi.h pulls in 80+ include
> files in the first place --- there's got to be stuff in there that
> needn't/shouldn't be exported.
Such as lztext.h?
> rather than fall back on automation that will let the list bloat even
> more without anyone much noticing...
Part of that would be to think more like a packager or user, rather than a
developer. That was the first thing I learned when tackling the RPM's, was,
that I was a packager -- while that does involve knowledge of the guts of the
package, it also requires a mindset very different from development -- more
user-oriented, I suppose.
A packager for RedHat will start thinking about what can be partitioned out,
saving the user's HD space. A packager will start thinking about how the
package _can_ be partitioned, and logical partitioning (for instance, the
absolutely worst possible packaging for PostgreSQL in RPM form would be a
single RPM with everything in it -- thus, requiring a database server to have a
full-bore X11 installation for pgaccess (which requires tk and tcl, as well),
when that database server may have absolutely no need for pgaccess.)). I am
now even considering splitting out pltcl into a separate package -- as pltcl
implicitly requires the server package, it makes the whole tcl package require
the server package -- and someone may have legitimate need for a postgresql
client machine _without_ the server AND need the tcl client. Maybe a
pgaccess-based administration client, perhaps?).
Those who build from the source have the configure options to eliminate (in
their opinion) the cruft they don't need -- RPM users don't have that option --
so, I build everything, and split the distribution.
Some issues I have seen along these lines are:
1.) The header situation -- assumes a source tree somewhere so that you
can pull in things....
2.) The regression tests -- you know, someone MIGHT want to _run_ those
tests on a database server in a production situation where there is no make, no
compiler, and no PostgreSQL source tree (where config.guess resides). The
installation can and should prebuild all necessary binaries and should
preconfigure the results of a config.guess -- and the shell script should not
need to be invoked by make. (Yes, the RPMset does all this (except eliminate
the need for config.guess), and it's packaged as the postgresql-test rpm, which
is an optional 1.5MB package -- I wimped out and packaged the whole test
subtree....)
While I am all for source availability and the whole open source (free
software) model, I am also for easily installed and upgraded packages for users
who simply want to use the package in a production environment. I've been
there and done that -- and was more than a little frustrated at the state of
the RPM packaging. Thus my current situation :-).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
