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

[Charles Determan]

I'm glad to see this discussion.  Unfortunately in the short term I cannot
remove the nested files (as Dirk implies with the BH package) as it would
require restructuring the c++ library and make it far more difficult to
maintain.  Unless there are other suggestions I will need to hold off on
submission until such a time that OSs that use obsolete tools are no longer
supported out-of-the-box (as Peter says).  I will likely just continue to
maintain the package on my gitub until CRAN would accept the longer paths.

Charles

On Tue, Oct 13, 2015 at 4:02 AM, peter dalgaard <pdalgd at gmail.com> wrote:

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

	[[alternative HTML version deleted]]