[R-pkg-devel] R CMD check NOTE - Long paths in package
On Tue, Oct 13, 2015 at 4:16 AM, Dirk Eddelbuettel <edd at 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)? 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