Re: Why not install pgstattuple by default?
От | Tom Lane |
---|---|
Тема | Re: Why not install pgstattuple by default? |
Дата | |
Msg-id | 3287.1304722078@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Why not install pgstattuple by default? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Why not install pgstattuple by default?
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, May 6, 2011 at 5:58 PM, Josh Berkus <josh@agliodbs.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-preferredls -R .../sharedir >contrib.files.for.server-packagemake install-contrib-second-class-citizensls-R .../sharedir >all.contrib.files... and then some magic with "comm" to separateout 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
В списке pgsql-hackers по дате отправления: