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. --- On Sat, 16/3/13, Hin-Tak Leung <ht...@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_le...@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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
