On 06/22/2012 06:02 AM, Akim Demaille wrote: > Still, I have been asked to address many issues in relpath before > a possible integration. One issue was making it library-ready, > which I partly did by eliminating xalloc.h. But there are other > issues, including the fact that relpath relies on non-library-ready > modules. > > So I am questioning the relevance of making relpath xalloc.h free, > as it makes the code more complex for no palatable advantage. > > Before addressing other issues in my proposal, I would like to know > if everybody agrees that being lgpl, being xalloc/error free, etc. > is irrelevant for relpath?
At this moment, I'm okay if relpath stays GPL-only, as it is turning into something complex enough that it adds value, and is not duplicating a glibc interface. It does limit who can use it (only top-level GPL programs, and not libraries), but I don't know of any library asking to use it at the moment. And if others agree that keeping it GPL-only is worthwhile, then refactoring to avoid xalloc is not worth the effort. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
