[Rd] the case of building R snapshot without svn nor network connection.
simon.urbanek at r-project.org
Sat Mar 16 15:39:42 CET 2013
On Mar 16, 2013, at 10:13 AM, Hin-Tak Leung wrote:
> Network access is *not* a given, nor is the privilege of installing arbitrary "uncertified" and "non-essential" tools - whatever the meaning of "uncertified" and "non-essential" are, those being defined, as is "design goal", etc, by some small committee.
> It is a very common scenario, e.g. banks & telecom, some part of public/government service and health care. This does not seem to sink in without repeating.
Network access is not needed to build R - apparently that fact did not seem to sink in, either. This entire thread is based on false assumptions and as such the only place for it is /dev/null
> --- On Sat, 16/3/13, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:
>> I'll quantify the first part - R is
>> perhaps the only public software project hosted on a
>> subversion repository for which the result of 'svn export
>> ...' does not build. Not only that it does not build, but
>> make it a feature that it does not build.
>> Very few other projects actively try to go in that
>> --- On Fri, 15/3/13, Hin-Tak Leung <hintak_leung at yahoo.co.uk>
>>> The decision to actively discourage
>>> non-subsersion usage of snapshot build is already made
>>> (r62183). So I am just here to register a differing
>>> - it is not about subversion vs
>>> There are two parts of R's dev build process which
>>> an active network connection - tools/rsync-recommended
>>> capturing `svn info` into R's headers. The former can
>>> overridden with "./configure
>>> --with-recommended-packages=no". A few changes had been
>>> in the last 6 months to make the latter mandatory. It
>>> to be optional.
>>> --- there are genuine needs for testing snapshots in a
>>> non-networked minimalist environment - e.g. banks or
>>> industries - where one wants a "standardised host"
>>> and often it means an "outdated host"; or in a virtual
>>> machine environment - which are non-networked for
>>> reasons, and also do not have tools beyond necessary
>>> compiling and building. This is quite a common
>>> --- AFAIK, 6 months ago, a snapshot copied to an
>>> non-networked host will build with "./configure
>>> --with-recommended-packages=no". Of course copying
>>> recommended package tar balls across would be nicer.
>> This is
>>> sadly no longer the case.
>>> - dependent on `svn info` and sitting on top of a svn
>>> checkout possibly also affects cross-compiling. But
>> then, it
>>> is not clear whether it is still possible to
>>> R, since quite a few changes have been made to remove
>>> capability of cross-compiling R for windows on unix
>> hosts in
>>> the last few years.
>>> - testing dev snapshots is about trying things and
>>> bugs before release. Making it difficult for non-core
>>> to "try", seem to go against that ethos. If that's the
>>> maybe the repository could be closed off to anonymous
>>> outs altogether, just to make it clear that testing
>>> snapshots before releases or even close to release, is
>>> welcomed. Just a thought.
>>> - although the official repository of the "main" linux
>>> kernel branch is git-based, there are mercurial
>>> AFAIK the digital video broadcasting hardware support
>> of the
>>> linux kernel is officially in mercurial repositories,
>>> have git mirrors; likewise much of Xorg's is in
>>> but have git mirrors. I haven't heard of any much
>>> public projects than R where some actively discourage
>>> - To be honest r62183 itself is probably a good reason
>>> move away from server-side repositories to distributed
>>> repositories (hg/git/arch/bzr). Local enhancements -
>> i.e. an
>>> in-house fork - some of which are never going upstream,
>>> as a local revert of r62183 (or a local revert of any
>>> upstream commits) is one reason why some have
>>> Lastly, a minor grip. The current head of the HK
>>> is probably sometimes called "HK Leung", just as some
>>> call a certain old lady "UK Windsor" and a certain
>>> person "US Obama".
> R-devel at r-project.org mailing list
More information about the R-devel