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

[Hin-Tak Leung]

--- On Sat, 16/3/13, Hin-Tak Leung <htl10 at users.sourceforge.net> 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.

Oh, and some might call using a tool beyond its initial purpose and context an enhancement, rather than 'misuse'. Quite a lot of words, like 'certified', 'essential', have no meaning outside the small group of people who use and misuse them, as is 'misuse'.

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