From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why not install pgstattuple by default? |
Date: | 2011-05-06 22:47:58 |
Message-ID: | 3287.1304722078@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2011-05-06 22:55:16 | Fix incorrect description at SECURITY LABEL documentation |
Previous Message | Greg Smith | 2011-05-06 22:32:38 | Re: Why not install pgstattuple by default? |