[Bug 866325] Review Request: ugene - genome analysis suite

bugzilla at redhat.com bugzilla at redhat.com
Tue Nov 13 08:59:54 UTC 2012


https://bugzilla.redhat.com/show_bug.cgi?id=866325

Peter Lemenkov <lemenkov at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|fedora-review?              |
              Flags|                            |fedora-review+

--- Comment #15 from Peter Lemenkov <lemenkov at gmail.com> ---
(In reply to comment #14)
> Peter, ping! What are our next steps?

Ok, I've just rebuilt your latest package:

* http://koji.fedoraproject.org/koji/taskinfo?taskID=4682123

So here is the short summary of what was done in regards to my prevoius
concerns:


===================================


* (Until we drop all bundled libs) please include LICENSE.3rd_party.


Done!


* What "UGENE_EXCLUDE_LIST_ENABLED" switch does? Are there any other
compile-time switches?


See src/ugene_globals.pri. This just excludes these three modules -
src/plugins/CoreTests, src/plugins/test_runner, src/plugins/perf_monitor,
src/plugins/GUITestBase, and it looks pretty harmless to me.


* You may drop %defattr line from the %files section - it's no longer needed
(even in EL5)


Done!


* Do you have plans to provide builds for EL5 or EL6? If no, then you may
remove %clean section entirely, "rm -rf %{buildroot}" from %install and kill
Buildroot directive as well.


Done as well.


* I really felt sad when I saw a bunch of bundled libraries residing within
your tarball. You really should drop them and compile against system-wide ones.
Is it possible? Did you patch them?


I'm mostly referring to src/libs_3rdparty/samtools, src/libs_3rdparty/sqlite3,
and src/libs_3rdparty/zlib. The other two libraries - src/libs_3rdparty/gtest,
which is used for testing, and src/libs_3rdparty/qscore, which isn't available
in Fedora afaik, aren't concerning me too much.

While zlib is definitely not even touched during compilation, the first two are
compiled into static libraries and the application is linked against them. As I
said I won't insist on compiling against system-wide copies right now. But I
really want you to do this in the future versions (as you already did with
zlib, e.g. add a compile-time switch to allow building against system-wide
copy). 


* The libraries - why not to install them into %{_libdir}? You will get rid of
all these LD_LIBRARY_PATH shell magic? I understand - the only application
which uses them is ugene itself, so someone might argue that it should go into
named subdirectory rather than into system-wide directory.


Now you installed them into %{_libdir}/%{name} w/o soname suffixes. This looks
much saner and I'll accept thet for now. However as a FutureFeature I still
believe there is a room for improvement here.


* Remove (or explain why it's impossible) two static libs. 


Done. They were simply removed.


===================================


I don't see any other issues and assuming that this is a huge and complex
application with some legacy which cannot be easily thrown away/fixed I declare
this package as 


APPROVED.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



More information about the package-review mailing list