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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
