On 12/29/2017 08:12 AM, Tels wrote: > On Thu, December 28, 2017 10:14 pm, Tom Lane wrote: >> Craig Ringer <cr...@2ndquadrant.com> writes: >>> Another option might be to teach the TAP infrastructure and the >>> buildfarm >>> client how to fetch cpanminus and build DBD::Pg against our build-tree, >>> so >>> we could use Perl DBI. >> As a buildfarm owner, I'd take a *really* dim view of the buildfarm >> trying to auto-fetch code off the internet. As a developer, the >> idea that "make check-world" would try to do that is even scarier. >> Buildfarm owners are likely to have taken at least some steps to >> sandbox their builds, but developers not so much. >> >> I do not think we should even think about going there. > Well, while I couldn't agree more on the "running code from the internet > is dangerous" thing, there are a few points for it, tho: > > * if you use Perl modules on your system, you are likely doing already, > anyway, as the Perl modules come, you guessed it, from the internet :) > Just because a random $PackageMaintainer signed it does mean it is really > safe. > > * And a lot of Perl modules are not in say, Debian repositories, so you > need to use CPAN (or re-invent everything). Unfortunately, the trend for > other languages seems to go into the same direction, with Ruby gems, the > python package manager, and almost everybody else re-inventing their own > packaging system, often poorly. So you might already have fallen in the > trap of "use random code from the internet". (Of course, that is not > really an argument for doing it, too...) > > * the other option seems to be "re-invent the wheel, again, locally", > which isn't always the best, either. > > I do agree tho that having "setup" or "make check" auto-fetching stuff > from the internet is not a good idea, however. Mostly because it becomes > suddenly much harder to run in closed networks w/o access and such > side-loading installations can bypass your systems packaging system, which > doesn't sound good, either. > > OTOH, it is possible to setup local repositories, or maybe even > pre-bundling modules into some sort of "approved TAP bundle" hosted on an > official server. > > The last resort would be to pre-bundle the wanted modules, but this has > the risk of outdating them fast. Plus, pre-bundled modules are not more > security vetted than the ones from the internet, so you might as well use > the CPAN version directly. > > The best course seems to me to have dependencies on the OS packackes for > the Perl modules you want to use. Not sure, however, if the build farm > client has "proper" Debian etc. packages and if it is even possible to add > these dependencies in this way. >
The buildfarm client isn't even packaged as a CPAN module let alone as a bunch of OS-level packages (and if I supported Debian packaging I'd need to support every other packaging system on the planet too, including Windows). It's always seemed to me unnecessary to use something beyond a simple tarball for something that has a target of less than 100 tolerably savvy users and which requires no actual build. In any case, I agree with Craig that we'd be much better off spending time working out why we can't get IPC::Run to do everything we want on Windows. As for out-dating, if we used DBD::PgPP we'd not be not in great danger there - it doesn't appear to have changed for many years - latest version is dated 2010. If we were to use it we'd have a dependency on DBI, but that in itself doesn't seem a great burden. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
