On Fri, May 6, 2011 at 6:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Well, that might be good, too. But, right now, if someone pulls up our documentation, or our source tree, they could easily be forgiven for thinking that hstore and dummy_seclabel are comparable, and they aren't. > 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. Certainly not. > 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. This isn't any uglier than some other RPM hacks I've seen, and less ugly than some, but you'd have a better sense of that than I do. At any rate, having the various categories separated in the source tree can't possibly hurt the effort to make something like this work, and might make it somewhat easier. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
