bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mkdir vs. GPL


From: Eric Blake
Subject: Re: mkdir vs. GPL
Date: Thu, 29 Oct 2009 22:01:09 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Jim Meyering <jim <at> meyering.net> writes:

> >       [3/5] dirname-lgpl: adjust clients that don't need full dirname
> > Fallout from the split.  In particular, test-mkdir and test-rename no longer
> > need libintl.  Meanwhile, openat and friends no longer drag in dirname, but
> > still drag in xalloc due to openat-die.

There's still a problem - rename depends on canonicalize-lgpl, but coreutils 
uses gnulib-tool --avoid=canonicalize-lgpl --import canonicalize.

On the surface, this works just fine - canonicalize_file_name is just as easy 
to write as a call to the more powerful canonicalize_filename_mode, rather than 
a wrapper around realpath.

Unfortunately, canonicalize_filename_mode is GPL, and liberally uses xmalloc.  
Which means that the GPL version of canonicalize_file_name(), and thus 
rpl_rename(), can now call exit() (making it unsafe for library use), and that 
test-rename fails to link for coreutils.  But we can't just solve it by adding 
@LIBINTL@ to the link line for test-rename, since then it would fail to compile 
when using just canonicalize-lgpl rather than canonicalize.  In other words, I 
don't know of any way to write modules/rename-tests to conditionally include 
@LIBINTL@ only if the GPL rather than the LGPL canonicalize_file_name is in use.

I think the only clean solution is to bite the bullet and decide that 
canonicalize-lgpl is the only module which can provide canonicalize_file_name, 
which in turn means that coreutils needs to quit doing --avoid canonicalize-
lgpl.

-- 
Eric Blake






reply via email to

[Prev in Thread] Current Thread [Next in Thread]