python bundled library question
On 11/12/2011 09:28 PM, Toshio Kuratomi wrote:
> On Sat, Nov 12, 2011 at 08:41:38AM +0100, Brendan Jones wrote:
>> I'm in the middle of reviewing
>> https://bugzilla.redhat.com/show_bug.cgi?id=751925 python-tables and
>> came Toshio's useful link
>> http://fedoraproject.org/wiki/User:Toshio/Unbundling_Python_Modules
>>
>> The maintainer has licensed the package as multi-license BSD and AFL -
>> on investigating it seems to included another file from a package here
>> http://evan.prodromou.name/Software/Python/LRUCache, however the
>> python-table developers have modified it significantly for there own
>> use, albeit with the same file and class name.
>>
>> Does this still constitute a bundled library or is it OK to include as is?
>>
> Yes, it still counts as a bundled library. The modification does not look
> that drastic (then again, the entire code of LRUCache is pretty small :-)
>
> The three things I see are
>
> * the removal of mtime as an attribute (a brief glance doesn't show any
> conflicts with the new code. Perhaps, this was just not being used so
> they felt they were "cutting fat".)
> * the addition of the pop() method. (This doesn't appear to conflict)
> * Substituting an incrementing integer sequence number instead of using
> timestamps. The reason for this is unclear. Perhaps it's a performance
> optimization (replacing call to time.time() with integer addition or
> perhaps they have external code that messes with the internals of the
> object or perhaps they implemented their own python extension module to
> take the place of LRUCache (lrucacheExtension) and they wanted both to
> use the same internal algorithm.
>
> The tables upstream should send their changes to the lrucache upstream to
> see if any or all of their changes could be incorporated in later upstream
> versions. The changes look like they could benefit any users of the code.
>
> This aside, though, there appears to be an easy out for the Fedora package.
> If I'm reading the python-tables code correctly, lrucache.py is only used in
> ./tables/file.py and only if the extension module that the python-tables
> authors wrote is not present (For instance, if the extension would not
> compile on a particular system.) So we can probably get rid of lrucache.py
> altogether.
>
> This should still be brought up to upstream. They may tell us that lrucache
> is being used in some manner that I'm not seeing. Or they may realize that
> they can get rid of the bundled copy of lrucache upstream (which would allow
> them to drop the AFL license conditions as well :-). I see that another
> file in the module: ./tables/table.py is importing tables.lrucacheExtension
> unconditionally so that's either a bug and they need to include a fallback
> on misc.lrucache there or they have already decided that they must have
> their extension and misc.lrucache.py has simply been left in the upstream
> module by accident.
>
>> The file in question lrucache.py is released under the AFL license and
>> is attributed correctly in the python-tables source (by way of a copy
>> of the original lrucache license).
>>
> I'm glad to see that it includes a copy of the license itself -- it's
> licensed under the AFL-v2.1 which isn't easily available online anymore
> (having been deprecatd by its author who promotes AFLv3 in its place).
>
> -Toshio
>
Thanks for the thorough answer! That gives me enough to put the packager
in the right direction. I'll pass on your analysis and recommend
containing upstream.
Thanks again,
Brendan
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
|
