Thread: New Contrib Build?
Folks, Hey, I can see a way for /contrib to become a lot better option for stuff-we're-not-sure-whether-to-include. What if we could build contrib modules through a build-time switch for PostgreSQL? Like, ./configure --with-perl --with-dblink --with-newsysviews This would seem a *lot* more user friendly to me, and easier on the package builders. What's the technical obstacle to it? Also, I think that /contrib modules should have documentation included in the main docs, probably as an appendix. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus wrote: > Folks, > > Hey, I can see a way for /contrib to become a lot better option for > stuff-we're-not-sure-whether-to-include. > > What if we could build contrib modules through a build-time switch for > PostgreSQL? Like, > > ./configure --with-perl --with-dblink --with-newsysviews > > This would seem a *lot* more user friendly to me, and easier on the package > builders. What's the technical obstacle to it? > > Also, I think that /contrib modules should have documentation included in the > main docs, probably as an appendix. I could see --with-contrib but other than that... there are ALOT of packages in contrib. Sincerely, Joshua Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Wed, May 11, 2005 at 02:34:21PM -0700, Joshua D. Drake wrote: > I could see --with-contrib but other than that... there are ALOT of > packages in contrib. I'm not configure expert, but I think it wouldn't be hard to do something like --with-contrib='module1 module2 module3'. I believe there's existing syntax in gmake to control what directories you descend into, so this would just need to envoke that syntax. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Josh Berkus wrote: >Folks, > >Hey, I can see a way for /contrib to become a lot better option for >stuff-we're-not-sure-whether-to-include. > > First, I *really* wish we'd call it something else. Contrib conveys "unsupported" to people. Maybe we should call it "modules" or something like that. >What if we could build contrib modules through a build-time switch for >PostgreSQL? Like, > >./configure --with-perl --with-dblink --with-newsysviews > >This would seem a *lot* more user friendly to me, and easier on the package >builders. What's the technical obstacle to it? > > I honestly don't see that it buys a lot. (and the technical obstacle is that there's a maintenance cost, if nothing else). >Also, I think that /contrib modules should have documentation included in the >main docs, probably as an appendix. > > > No, not as an appendix, please. Again, that gives the wrong impression. Let's add another main section on optional modules. cheers andrew
Jim C. Nasby wrote: > On Wed, May 11, 2005 at 02:34:21PM -0700, Joshua D. Drake wrote: > >>I could see --with-contrib but other than that... there are ALOT of >>packages in contrib. > > > I'm not configure expert, but I think it wouldn't be hard to do > something like --with-contrib='module1 module2 module3'. I believe > there's existing syntax in gmake to control what directories you descend > into, so this would just need to envoke that syntax. That would work... with a --with-contrib='all' etc... -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Andrew, > First, I *really* wish we'd call it something else. Contrib conveys > "unsupported" to people. Maybe we should call it "modules" or something > like that. Agreed. > I honestly don't see that it buys a lot. (and the technical obstacle is > that there's a maintenance cost, if nothing else). It would save, me, personally a bunch o' time and troubleshooting, since I regularly install 5-6 different contrib modules. > No, not as an appendix, please. Again, that gives the wrong impression. > Let's add another main section on optional modules. OK by me. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Andrew Dunstan <andrew@dunslane.net> writes:
> Josh Berkus wrote:
>>What if we could build contrib modules through a build-time switch for
>>PostgreSQL? Like,
> I honestly don't see that it buys a lot. (and the technical obstacle is
> that there's a maintenance cost, if nothing else).
I'm with Andrew on this: what's the point? We don't currently have
any contrib modules that are noticeably harder to build than any others,
and I don't see any coming over the horizon.
regards, tom lane
On Wed, May 11, 2005 at 02:55:46PM -0700, Josh Berkus wrote: > > First, I *really* wish we'd call it something else. Contrib conveys > > "unsupported" to people. Maybe we should call it "modules" or something > > like that. > Agreed. Ditto > > I honestly don't see that it buys a lot. (and the technical obstacle is > > that there's a maintenance cost, if nothing else). > > It would save, me, personally a bunch o' time and troubleshooting, since I > regularly install 5-6 different contrib modules. Likewise, I think it would make our various OS ports cleaner. All port systems are setup to easily allow different optional config options, but it's generally more difficult to tie additional make steps in. This means that the only options I've seen for installing things out of contrib from a port system are to either install all contrib modules or to hunt down where the source was extracted to. > > No, not as an appendix, please. Again, that gives the wrong impression. > > Let's add another main section on optional modules. > > OK by me. Ditto. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>Josh Berkus wrote: >> >> >>>What if we could build contrib modules through a build-time switch for >>>PostgreSQL? Like, >>> >>> > > > >>I honestly don't see that it buys a lot. (and the technical obstacle is >>that there's a maintenance cost, if nothing else). >> >> > >I'm with Andrew on this: what's the point? We don't currently have >any contrib modules that are noticeably harder to build than any others, >and I don't see any coming over the horizon. > > I'd buy it more with Jim Nasby's suggested --with-contrib option. Or let's say --with-modules. One nice side effect would be that this info would get into pg_config's configure settings. That would also help to make the whole build more replayable. To be of any use I guess this should ensure that the specified modules are built, installed and tested from the main makefile. cheers andrew
Andrew Dunstan wrote: > First, I *really* wish we'd call it something else. Contrib conveys > "unsupported" to people. And that's exactly what it is supposed to mean. We say, these modules do not necessarily meet our standards with regard to code quality, portability, user interfaces, internationalization, documentation, etc. There is certainly a lot of good software in contrib and one could in individual cases consider moving them out of there, but contrib is what it is. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Josh Berkus wrote: > What if we could build contrib modules through a build-time switch > for PostgreSQL? Like, > > ./configure --with-perl --with-dblink --with-newsysviews > > This would seem a *lot* more user friendly to me, and easier on the > package builders. What's the technical obstacle to it? I don't see how this makes it any more user friendly or easier on package builders. Is your aim to make building contrib more accessible or building only specific contrib modules more accessible? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter, > I don't see how this makes it any more user friendly or easier on > package builders. Is your aim to make building contrib more accessible > or building only specific contrib modules more accessible? Building specific contrib modules. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> Peter,
>> I don't see how this makes it any more user friendly or easier on
>> package builders. Is your aim to make building contrib more accessible
>> or building only specific contrib modules more accessible?
> Building specific contrib modules.
On re-reading the thread, I'm more than a bit confused by this response.
I thought you were suggesting that the top-level configure should have
a simple option that says "please build and install all the contrib
modules while you are at it". Right now that requires a separate step
"cd contrib; make; make install" which I agree could be handled by a
top-level configure option. And it would also be reasonable for "make
check" at the top level to include running the contrib regression tests
if this option had been specified. (Memo to Andrew Dunstan: that should
also happen for the PL-specific tests, as soon as they've been
pg_regress-ified.)
What I'm not seeing anywhere here is an argument that we need a
configure option to build just selected ones of the contrib modules.
Certainly the RPM packagers would have no use for that.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> Andrew Dunstan wrote:
>> First, I *really* wish we'd call it something else. Contrib conveys
>> "unsupported" to people.
> And that's exactly what it is supposed to mean. We say, these modules
> do not necessarily meet our standards with regard to code quality,
> portability, user interfaces, internationalization, documentation, etc.
> There is certainly a lot of good software in contrib and one could in
> individual cases consider moving them out of there, but contrib is what
> it is.
Which is as it should be, I think. Contrib is essentially the "not
quite ready for prime time" area. If it were 100% up to speed then
it'd be in the core backend already ... while if we required it to be
100% in advance, then it'd not have gotten out there in the first place.
The real issue seems to be that we have a disconnect between what is
presently in contrib and what is on gborg or pgfoundry. There are
certainly many contrib modules that are only there on seniority: if
they were submitted today then they'd have gotten put on pgfoundry.
But I'm not sure that there's much value in an enforced cleanup.
regards, tom lane
Tom, > On re-reading the thread, I'm more than a bit confused by this response. > I thought you were suggesting that the top-level configure should have > a simple option that says "please build and install all the contrib > modules while you are at it". Right now that requires a separate step > "cd contrib; make; make install" which I agree could be handled by a > top-level configure option. And it would also be reasonable for "make > check" at the top level to include running the contrib regression tests > if this option had been specified. (Memo to Andrew Dunstan: that should > also happen for the PL-specific tests, as soon as they've been > pg_regress-ified.) Well, that depends on whether you're talking me, personally, or the packagers. I agree that the packagers are more likely to want a --make-all-contrib. I personally would prefer a --make-contrib="tsearch2,ltree,intarray" which allows me to build selected modules. Also, if we are going to add useful-but-potentially-dangerous stuff like the "admin commands" to /contrib, then even the packagers will want options. What could be a great all-around option would be to put stuff potentially in contrib into about 3 groups, like "datatypes", "sqltools" and "admintools". Then you'd have three options --with-contrib-types, --with-contrib-sql, and --with-contrib-admin, and of course --with-contrib-all. The reason for the distinction is that some packagers might want everything but the admin tools becuase those have potential security issues. Anyway, that's a bit incoherent, but do people see what I mean with this? -- Josh Berkus Aglio Database Solutions San Francisco
On Thu, 12 May 2005 02:44 pm, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Andrew Dunstan wrote: > >> First, I *really* wish we'd call it something else. Contrib conveys > >> "unsupported" to people. > [snip] > Which is as it should be, I think. Contrib is essentially the "not > quite ready for prime time" area. If it were 100% up to speed then > it'd be in the core backend already ... while if we required it to be > 100% in advance, then it'd not have gotten out there in the first place. > At which point do things move from no being 100% to being 100%. From what I understand some of the contrib modules have been there for a very long time. Some of the may be solved other ways. eg the new system views and dbsize. Other things like pg_crypto may enable simple things like changing somebodies username without redoing their password, as we could use those functions instead of the current ones. This may make some of our pg_shadow friends (with regard to recentish security threads) a bit happier as well. I suppose the question is, at what point are contrib modules re-reviewed for inclusion into core? And if they are continuing not to make it, is there something else that should be done with them? > The real issue seems to be that we have a disconnect between what is > presently in contrib and what is on gborg or pgfoundry. There are > certainly many contrib modules that are only there on seniority: if > they were submitted today then they'd have gotten put on pgfoundry. > But I'm not sure that there's much value in an enforced cleanup. Maybe not an enforced cleanup. But if there are people who manage certain modules, it may be work asking them the question about getting their contrib module onto pgfoundry if that is the best place for it. And then giving them a little bit of support in doing it. eg, getting the cvs history out of the PostgreSQL cvs tree. Regards Russell Smith
Russell Smith <mr-russ@pws.com.au> writes: > I suppose the question is, at what point are contrib modules > re-reviewed for inclusion into core? And if they are continuing not > to make it, is there something else that should be done with them? Basically, if someone wants a contrib module in core, they should step up, discuss on -hackers what needs to be done to make it core-ready, and submit patches for review. That's how all PG development works. :) -Doug
Tom Lane wrote: >Peter Eisentraut <peter_e@gmx.net> writes: > > >>Andrew Dunstan wrote: >> >> >>>First, I *really* wish we'd call it something else. Contrib conveys >>>"unsupported" to people. >>> >>> > > > >>And that's exactly what it is supposed to mean. We say, these modules >>do not necessarily meet our standards with regard to code quality, >>portability, user interfaces, internationalization, documentation, etc. >>There is certainly a lot of good software in contrib and one could in >>individual cases consider moving them out of there, but contrib is what >>it is. >> >> > >Which is as it should be, I think. Contrib is essentially the "not >quite ready for prime time" area. If it were 100% up to speed then >it'd be in the core backend already ... while if we required it to be >100% in advance, then it'd not have gotten out there in the first place. > >The real issue seems to be that we have a disconnect between what is >presently in contrib and what is on gborg or pgfoundry. There are >certainly many contrib modules that are only there on seniority: if >they were submitted today then they'd have gotten put on pgfoundry. >But I'm not sure that there's much value in an enforced cleanup. > > I think there probably is. Too much in there looks just abandoned. On the flip side, I know we're dealing with the pg_autovacuum issue, but we get lots of queries about crypto functions and text search because people don't know they are in contrib. BTW, I note that the TODO list has these delightfully non-specific items: * Move some things from /contrib into main tree * Move some /contrib modules out to their own project sites cheers andrew
On Thu, 12 May 2005, Andrew Dunstan wrote: > > > Tom Lane wrote: > >> Peter Eisentraut <peter_e@gmx.net> writes: >> >>> Andrew Dunstan wrote: >>> >>>> First, I *really* wish we'd call it something else. Contrib conveys >>>> "unsupported" to people. >>>> >> >> >>> And that's exactly what it is supposed to mean. We say, these modules do >>> not necessarily meet our standards with regard to code quality, >>> portability, user interfaces, internationalization, documentation, etc. >>> There is certainly a lot of good software in contrib and one could in >>> individual cases consider moving them out of there, but contrib is what it >>> is. >>> >> >> Which is as it should be, I think. Contrib is essentially the "not >> quite ready for prime time" area. If it were 100% up to speed then >> it'd be in the core backend already ... while if we required it to be >> 100% in advance, then it'd not have gotten out there in the first place. >> >> The real issue seems to be that we have a disconnect between what is >> presently in contrib and what is on gborg or pgfoundry. There are >> certainly many contrib modules that are only there on seniority: if >> they were submitted today then they'd have gotten put on pgfoundry. >> But I'm not sure that there's much value in an enforced cleanup. >> > > I think there probably is. Too much in there looks just abandoned. On the > flip side, I know we're dealing with the pg_autovacuum issue, but we get lots > of queries about crypto functions and text search because people don't know > they are in contrib. > > BTW, I note that the TODO list has these delightfully non-specific items: > > * Move some things from /contrib into main tree > * Move some /contrib modules out to their own project sites contrib was originally meant as a 'staging ground' for stuff to eventually go into core *or* just removed from contrib ... its turned into a 'final resting ground' ... Josh's point about 'different categories' is pertinent, except that all that should be in contrib is the stuff that is applicable to core, which is pretty much the 'datatype' stuff ... I really liked someone's idea of a 'modules' directory, that stuff like dbsize, earthdistance, tsearch2, etc could go under, but stuff like admintools should be on pgfoundry ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > ... but stuff like admintools should be on pgfoundry ... This is a quite *ix centric attitude. Please note that probably >90 % of win32 installations have them installed by default (from the win32 installer). People moving to Linux because they need better performance (which probably is recommended in many cases) will be surprised that it's add-on, instead of being core. Regards, Andreas
On Thu, 12 May 2005, Andreas Pflug wrote: > Marc G. Fournier wrote: > >> ... but stuff like admintools should be on pgfoundry ... > > This is a quite *ix centric attitude. Please note that probably >90 % of > win32 installations have them installed by default (from the win32 > installer). People moving to Linux because they need better performance > (which probably is recommended in many cases) will be surprised that it's > add-on, instead of being core. 'k, now i'm confused ... what are you looking at here, in contrib, as being 'admintools'? Right now, anything in contrib is 'add-on' anyway, so they'd still be as confused, I'd think ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > 'k, now i'm confused ... what are you looking at here, in contrib, as > being 'admintools'? Right now, anything in contrib is 'add-on' anyway, > so they'd still be as confused, I'd think ... Well at least it would be contained in the full tarball, not coming from a 3rd site (and will hopefully build with a --with-contrib or so, after some cleanup in contrib). To fix it finally, all admin related stuff should be in core, not contrib. I'm not too happy with admin tools needing additional stuff loaded in each backend to maintain them (and e.g. surveilling table sizes seems quite basic to me). Regards, Andreas
Andrew, > * Move some things from /contrib into main tree > * Move some /contrib modules out to their own project sites A contrib shuffle is on my personal TODO list. Look for a list in a couple weeks. -- Josh Berkus Aglio Database Solutions San Francisco
>./configure --with-perl --with-dblink --with-newsysviews This would make installing and upgrading BSD ports easier. David