On Wed, Sep 11, 2019 at 05:12:31PM +0200, Johannes Schindelin wrote: > On Tue, 10 Sep 2019, SZEDER Gábor wrote: > > > On Tue, Sep 10, 2019 at 12:51:01AM +0200, Johannes Schindelin wrote: > > > On Fri, 6 Sep 2019, SZEDER Gábor wrote: > > > > > > > On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gábor wrote: > > > > > > > Let's install P4 from the package repository, because this > > > > > approach seems to be simpler and more future proof. > > > > > > > > > > Note that we used to install an old P4 version (2016.2) in the > > > > > Linux build jobs, but with this change we'll install the most > > > > > recent version available in the Perforce package repository > > > > > (currently 2019.1). > > > > > > > > So I'm not quite sure whether we really want this patch. It > > > > depends on how important it is to test 'git-p4' with an old P4 > > > > version, but I don't really have an opinion on that. > > > > > > I'd rather have that patch. It seems to be a much better idea to use > > > the package management system than to rely on one host, especially > > > when said host already displayed hiccups. > > > > Well, I'm not so sure. As far as I remember this was the first time > > that this Perforce filehost was inaccessible and a simple "Restart > > job" could not rectify the situation, because it was inaccessible for > > about a day or more. > > Right. > > > OTOH, transient errors or timeouts from 'apt-get update' or 'install' > > from the official Ubuntu package repositories are not uncommon (at > > least on Travis CI), although in those cases it's usually enough to > > just restart the errored job. > > My impression precisely. I trust the Ubuntu package servers to have > transient, _short-lived_ problems ;-)
Heh, that's true, but note that we won't install P4 from the Ubuntu package servers, but from the Perforce package repository, so I doubt we can expect any improvements in this regard. OTOH, instead of issuing only two HTTP requests to download those two binaries we'll issue a total of 9 requests (1 pubkey, 2 package lists, 6 packages) that could go wrong. I'm undecided, and at the very least the proposed commit message should be updated.
