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

[peter dalgaard]

On 13 Oct 2015, at 09:42 , Uwe Ligges <ligges at 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 <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.

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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
> ______________________________________________
> R-package-devel at 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.mes at cbs.dk  Priv: PDalgd at gmail.com