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

[Martin Maechler]

>>>>> Simon Urbanek <simon.urbanek at r-project.org>
>>>>>     on Sat, 16 Mar 2013 10:39:42 -0400 writes:

    > 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

Indeed!

Hin-Tak, do you really think that we, R core, would cripple
ourselves in such a way ??
I bet that almost all of us build R (from svn) without internet
connection many times a year.

But we do follow the build presciptions (*) which you have taken
enormous lengths *not* to go along with.

Martin

---
(*) builddir != srcdir


    >> --- 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
    >> 
    >> 

    > ______________________________________________
    > R-devel at r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel