[R-pkg-devel] long file names in tar

You could go down this rabbit hole if you like, but I suspect it has something to do with maintaining compatibility with multiple operating systems and I doubt R Core will explore the consequences of this change for you. Windows, for example, allows long file names but has some nasty corners that break if your  total path+filename is 260+ characters and packages do get installed in directories fairly deep into the directory structure on a regular basis (e.g. packrat). Other tools that the R ecosystem depends on could also have internal constraints that come up when one tool builds on another and so on.

Have fun with that!

On April 18, 2019 11:02:15 AM PDT, Steven Scott <steve.the.bayesian at gmail.com> wrote:

Thanks Dirk,
Yes, I've done the same, and I agree the rules are the rules.  Rules
should
be updated when they're no longer helpful, or when their cost outweighs
their benefit.  I'm curious whether that might be the case here.
Cheers,
Steve


On Thu, Apr 18, 2019 at 10:54 AM Dirk Eddelbuettel <edd at debian.org>
wrote:

On 18 April 2019 at 10:37, Steven Scott wrote:
| My Boom package makes a C++ library available to package authors

(mainly

| me).  The wrapped library is used outside of R and must comply with
| external style rules such as UseLongDescriptiveNames, and files

must be

| named for the class they contain.  From time to time a
| LongDescriptiveFileName, when paired with its full directory path,
exceeds
| 100 characters.
|
| This creates a conflict with CRAN's rules about long file names,

which

| stems from tar.  I'm wondering what this community thinks about

asking

for
| that rule to be relaxed.  Both gnu tar and posix tar now allow

unlimited

| length filenames, and the ustar format allows names up to 256

characters.

|
| I'm interested in the opinions of people on this list about whether

this

| rule has outlived its usefulness.  Thanks.

There are no "opinions". There is CRAN Repo Policy.

The BH package your Boom depends upon is actually named BH in part

because

having a two-letter name shrunk the set of files violating this very
constraint.  Yet at every release I still get to renamed one file,

and

update
one include statement.  All documented in the ChangeLog.

So I would change the filenames, and move on.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

	[[alternative HTML version deleted]]