Re: Why not install pgstattuple by default?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, May 6, 2011 at 5:58 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> Yeah, I wasn't thinking of including all of contrib. There's a lot of
>> reasons not to do that.

> Slightly off-topic, but I really think we would benefit from trying to
> divide up contrib. [ snip ]
> I think
> it would make things a lot easier for both packagers and actual users
> if we separated these things into different directories, e.g.:

> debugging and instrumentation tools -> src/debug
> server functionality -> contrib
> server functionality (deprecated) -> contrib/deprecated
> examples & regression test suport -> src/test/examples

From a packager's standpoint, that would be entirely worthless. The
source tree's just a source tree, they don't care what lives where
within it. I was just thinking about what it'd take to actually
repackage things for Fedora, and the main problem is here:

%files contrib
...
%{_datadir}/pgsql/contrib/
...

If you're not adept at reading RPM specfiles, what that is saying
is that everything that "make install" has stuck under
${prefix}/share/pgsql/contrib/ is to be included in the contrib RPM.
To selectively move some stuff to the server RPM, I'd have to replace
that one line with a file-by-file list of *everything* in share/contrib,
and then move some of those lines to the "%files server" section, and
then look forward to having to maintain that list in future versions.
I'm already maintaining a file-by-file list of contrib's .so's, and I
can tell you it's a PITA.

As a packager, what I'd really want to see from a division into
recommended and not-so-recommended packages is that they get installed
into different subdirectories by "make install". Then I could just
point RPM at those directories and I'd be done.

I don't know how practical this is from our development standpoint,
nor from a user's standpoint --- I doubt we want to ask people to use
different CREATE EXTENSION commands depending on the preferredness of
the extension.

A possibly workable compromise would be to provide two separate makefile
installation targets for preferred and less preferred modules. The RPM
script could then do something like

make install-contrib-preferred
ls -R .../sharedir >contrib.files.for.server-package
make install-contrib-second-class-citizens
ls -R .../sharedir >all.contrib.files
... and then some magic with "comm" to separate out the contrib
... files not mentioned in contrib.files.for.server-package ...

Pretty grotty but it would work. Anyway my point is that this is all
driven off the *installed* file tree. A specfile writer doesn't know
nor want to know where "make install" is getting things from in the
source tree.

regards, tom lane