Bug 620039

Before going into deeper analysis, I think that the license tag should probably be more similar to "BSD and LGPLv3 and Public Domain". Also, have you considered including the tests ( "integrationtests") ?

The license for this package is complicated, see image_LICENSE.txt, BSD and LGPLv3 and Public Domain is not enough(e.g. images from cristalproject is licensed under LGPLv2+).

Doing tests in %check will pull in a lot of other ETS packages, normally I'd like to do it on a local machine which is already installed the whole ETS stacks. For no core python packages, I think doing tests is not a good idea, because most Requires are not listed in BuildRequires.

(In reply to comment #2)
> The license for this package is complicated, see image_LICENSE.txt, BSD and
> LGPLv3 and Public Domain is not enough(e.g. images from cristalproject is
> licensed under LGPLv2+).
I've seen that. But AFAIK, LGPLv2+ + LGPLv3 kind of equals LGPLv3. But by all means please correct me if I am wrong


> 
> Doing tests in %check will pull in a lot of other ETS packages, normally I'd
> like to do it on a local machine which is already installed the whole ETS
> stacks. For no core python packages, I think doing tests is not a good idea,
> because most Requires are not listed in BuildRequires.
But you can add them as BR, as needed. AFAIK running the embedded tests is encouraged for all software ( unless it is prohibitive or cannot be done in koji)

(In reply to comment #3)
> (In reply to comment #2)
> > The license for this package is complicated, see image_LICENSE.txt, BSD and
> > LGPLv3 and Public Domain is not enough(e.g. images from cristalproject is
> > licensed under LGPLv2+).
> I've seen that. But AFAIK, LGPLv2+ + LGPLv3 kind of equals LGPLv3. But by all
> means please correct me if I am wrong
If LGPLv2+ and LGPLv3 source files are compiled into one binary, then the license for this binary should be LGPLv3. If those files are not compiled into one file, then they are still licensed under their original license. 

> > Doing tests in %check will pull in a lot of other ETS packages, normally I'd
> > like to do it on a local machine which is already installed the whole ETS
> > stacks. For no core python packages, I think doing tests is not a good idea,
> > because most Requires are not listed in BuildRequires.
> But you can add them as BR, as needed. AFAIK running the embedded tests is
> encouraged for all software ( unless it is prohibitive or cannot be done in
> koji)    

Right, it'll be better to do %check in spec if it's convenient to do so. This package will pull in >200M addtional deps for tests, I don't think it's really worth to do so.  For C/C++ packages, doing tests normally won't pull in many additional buildrequires. However, for some python packages, I think doing tests is impossible under some circumstance(e.g. Zope2 requires donzes of tiny python modules, all those modules depends on a large amount of other modules, obviously we can't do tests for all those modules).

I am sorry, but due to lack of time I have to abandon this review.

I don't see any issue about this package, approved!

Thank you for your great work, Manuel Wolfshant.

New Package CVS Request
=======================
Package Name: python-Enable
Short Description: Drawing and interaction packages
Owners: supercyper
Branches: F-13 F-14
InitialCC:

Git done (by process-git-requests).