Re: PGXN Hosting - Mailing list pgsql-www
From | Cédric Villemain |
---|---|
Subject | Re: PGXN Hosting |
Date | |
Msg-id | BANLkTimTUUEUdeUFdXf7XQLAQGZxR8tz7g@mail.gmail.com Whole thread Raw |
In response to | Re: PGXN Hosting (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Responses |
Re: PGXN Hosting
Re: PGXN Hosting |
List | pgsql-www |
2011/5/11 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>: > On 05/11/2011 09:25 PM, David E. Wheeler wrote: >> >> On May 11, 2011, at 12:18 PM, Stefan Kaltenbrunner wrote: >> >>>> Looks like 5.12.3 has been built for sid: >>>> >>>> http://packages.debian.org/search?keywords=perl >>>> >>>> Is that do-able? Would save me some effort to use that (effort better >>>> spent on community auth integration). >>> >>> I would stringly prefer to stay on 5.10 from squeeze if that is doable, >>> manual backporting of such a huge package like perl with its millions of >>> forward and reverse dependencies will cause no end of pain :( >>> Running the (available) postgresql 9.0 backport is a breeze compared to >>> that however. >> >> Well, if I could compile 5.12, I'd install it in /usr/local/. No need to >> replace the system Perl at all. That's how I generally work with this stuff: >> Leave the system Perl for system tasks; build my own Perl for the apps I >> build. > > yeah and now the fun starts... "ok we use the packaged postgresql - in need > plperl in ther to be 5.12", "we cannot use the packaged DBD::Pg because that > one needs to be compiled agains 5.12 as well", "an oh because it is simpled > we cannot use any packaged perl lib at all because it is so much easier if I > just install my own copy that will never be security tracked". > We(mostly magnus) basically spent man years to get the new infrastructure up > and long term maintainable and having to start supporting random hand > compiled complex packages (again) on them does not sound like the right > thing to do - it is where we came from and we defintely dont want to get > back there. > If it really needs perl 5.12 (and maybe other stuff) I would rather think it > is better to keep pgxn as a seperate entity for the time being. > Infrastructure is all about reliability, sustainability and manageability - > that often does not mix too well with developer needs but that is how it > is... hey ! you scared me : will sysadmin use pgxn to install non-security tracked extension stuff for their favorites developers and co-workers.... just a poll for sysadmins: * will you allow cpan usage ? * will you allow pgxn usage ? I though cpan has something to track the modules built locally and update them all. As probably have pgxn (if cpan has) or will have at some point. Am I wrong ? > > > Stefan > > > -- > Sent via pgsql-www mailing list (pgsql-www@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-www > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support