From simon.urbanek at r-project.org  Sat Mar 16 15:39:42 2013
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Sat, 16 Mar 2013 10:39:42 -0400
Subject: [Rd] the case of building R snapshot without svn nor network
	connection.
In-Reply-To: <1363443222.94887.YahooMailClassic@web172302.mail.ir2.yahoo.com>
References: <1363443222.94887.YahooMailClassic@web172302.mail.ir2.yahoo.com>
Message-ID: <2F0444D6-24AC-44B0-8413-8F41A2B5D983@r-project.org>

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
>> direction.
>> 
>> --- On Fri, 15/3/13, Hin-Tak Leung <hintak_leung at yahoo.co.uk>
>> wrote:
>> 
>>> The decision to actively discourage
>>> non-subsersion usage of snapshot build is already made
>>> (r62183). So I am just here to register a differing
>>> opinion.
>>> 
>>> - it is not about subversion vs
>> other-version-control-tools.
>>> There are two parts of R's dev build process which
>> requires
>>> an active network connection - tools/rsync-recommended
>> and
>>> capturing `svn info` into R's headers. The former can
>> be
>>> overridden with "./configure
>>> --with-recommended-packages=no". A few changes had been
>> made
>>> in the last 6 months to make the latter mandatory. It
>> used
>>> to be optional.
>>> 
>>> --- there are genuine needs for testing snapshots in a
>>> non-networked minimalist environment - e.g. banks or
>> telecom
>>> industries - where one wants a "standardised host"
>> build,
>>> and often it means an "outdated host"; or in a virtual
>>> machine environment - which are non-networked for
>> security
>>> reasons, and also do not have tools beyond necessary
>> for
>>> compiling and building. This is quite a common
>> scenario.
>>> 
>>> --- AFAIK, 6 months ago, a snapshot copied to an
>>> non-networked host will build with "./configure
>>> --with-recommended-packages=no". Of course copying
>> those
>>> 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
>> cross-compile
>>> R, since quite a few changes have been made to remove
>> the
>>> capability of cross-compiling R for windows on unix
>> hosts in
>>> the last few years. 
>>> 
>>> - testing dev snapshots is about trying things and
>> fixing
>>> bugs before release. Making it difficult for non-core
>> people
>>> to "try", seem to go against that ethos. If that's the
>> case,
>>> maybe the repository could be closed off to anonymous
>> check
>>> outs altogether, just to make it clear that testing
>>> snapshots before releases or even close to release, is
>> not
>>> welcomed. Just a thought.
>>> 
>>> - although the official repository of the "main" linux
>>> kernel branch is git-based, there are mercurial
>> mirrors;
>>> AFAIK the digital video broadcasting hardware support
>> of the
>>> linux kernel is officially in mercurial repositories,
>> but
>>> have git mirrors; likewise much of Xorg's is in
>> mercurial
>>> but have git mirrors. I haven't heard of any much
>> bigger
>>> public projects than R where some actively discourage
>>> others.
>>> 
>>> - To be honest r62183 itself is probably a good reason
>> to
>>> 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,
>> such
>>> as a local revert of r62183 (or a local revert of any
>> other
>>> upstream commits) is one reason why some have
>> distributed
>>> repositories.
>>> 
>>> Lastly, a minor grip. The current head of the HK
>> government
>>> is probably sometimes called "HK Leung", just as some
>> might
>>> call a certain old lady "UK Windsor" and a certain
>> black
>>> person "US Obama".
>>> 
>> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 



[Rd] the case of building R snapshot without svn nor network connection.
Simon Urbanek