[R-pkg-devel] R CMD check NOTE - Long paths in package

Uwe Ligges ligges at statistik.tu-dortmund.de
Tue Oct 13 09:42:55 CEST 2015

On 13.10.2015 09:01, Barry Rowlingson wrote:
> 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)?

Yes, some Unixes seem to have old tar versions installed.

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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

More information about the R-package-devel mailing list