Re: TAP test module - PostgresClient

From: "Tels" <nospam-abuse(at)bloodgate(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Craig Ringer" <craig(at)2ndquadrant(dot)com>, "Kyotaro HORIGUCHI" <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TAP test module - PostgresClient
Date: 2017-12-29 13:12:26
Message-ID: abbf81d68d18c27413b5bc6f84ebe000.squirrel@sm.webmail.pair.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

Best wishes,

Tels

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marco Nenciarini 2017-12-29 13:15:22 [PATCH] Logical decoding of TRUNCATE
Previous Message Alvaro Herrera 2017-12-29 13:02:13 Re: [HACKERS] path toward faster partition pruning