>>>>> Simon Urbanek <simon.urba...@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 >> <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 >> >> > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel