On 13 Oct 2015, at 09:42 , Uwe Ligges <lig...@statistik.tu-dortmund.de> wrote:
> > > On 13.10.2015 09:01, Barry Rowlingson wrote: >> On Tue, Oct 13, 2015 at 4:16 AM, Dirk Eddelbuettel <e...@debian.org> wrote: >>> >>> On 12 October 2015 at 13:13, Charles Determan wrote: >>> | Greetings, >>> | >>> | I have a package which provides headers for a C++ library (similar to the >>> | BH package). However, the C++ library has some heavily nested components >>> | within its' structure so when I run R CMD check I get the following NOTE: >>> | >>> | Tarballs are only required to store paths of up to 100 bytes and cannot >>> | store those of more than 256 bytes, with restrictions including to 100 >>> | bytes for the final component. >>> | >>> | Is this a major problem? >>> >>> Yes. >>> >>> | As this is a 'NOTE' I am under the impression >>> | that the long paths are not critical but I want to make sure. >>> >>> Wrong. >>> >>> 'BH' is called 'BH', believe it or not, to save a few letters, or else I >>> would have a dozen or more files complain for the very same reason (and CRAN >>> reject it for non-suitable path/filenames). Hence not 'BoostHeaders' but >>> just 'BH'. And see the ChangeLog of BH and revel in how _each_ release has >>> to >>> rename one of the Runge-Kutta integration files to make the 'net' path >>> length >>> be suitable for R packing. >>> >>> There is no point in ignoring the output of R CMD check unless you _really_ >>> know better. >> >> But is it worth asking if the NOTE's restriction could be lifted, >> given that from what I read on wikipedia that the "tar" file format >> has been happy with long path names since 2001? Given that R-Core/CRAN >> sometimes refer to R versions from a year ago as "obsolete", how can >> they complain about sticking with a file format restriction from the >> last century? I've just happily made a tar file with a path that is >> 1300 chars long containing a file with a name of 160 chars . >> >> Or are there still old versions of tar around, or other file systems >> with restrictive naming practices (in which case the error should be >> about the names/paths of the files themselves, not that old versions >> of tar can't cope with them)? > > Yes, some Unixes seem to have old tar versions installed. Yes, it is somewhat harder to deem entire OSs obsolete... But: How old versions and how common is the issue? Mainstream Unix is essentially Linux and OS X these days. OS X seems to be stuck in 2010 (BSD tar 2.8.3), at least up until Yosemite. Linux distros usually keep themselves up to date, except for the enterprise/long upgrade cycle ones that can be like 5 years outdated. Less common, but still in use, are FreeBSD, Solaris and AIX. It _is_ a valid question for how long we want out-of-the-box support for OSs that use obsolete tools. At some point we could decide that the more obscure Unices would have to install a recent version (with the R configuration arranging to set TAR=/usr/local/bin/gtar or somesuch). -pd > > Best, > Uwe Ligges > >> >> It now seems to have bothered at least two people and Dirk sounds >> like he's had to implement a little hack to keep the path names down. >> >> Barry >> >> ______________________________________________ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd....@cbs.dk Priv: pda...@gmail.com ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
