Re: TAP test module - PostgresClient

On 12/29/2017 08:12 AM, Tels wrote:
> On Thu, December 28, 2017 10:14 pm, Tom Lane wrote:
>> Craig Ringer <craig(at)2ndquadrant(dot)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