[Fedora-packaging] python bundled library question

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20111112/b8ef395b/attachment.bin