Robert Haas <[email protected]> writes:
> On Fri, May 6, 2011 at 5:58 PM, Josh Berkus <[email protected]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
