[Bug 472150] Review Request: coot - crystallographic macromolecular building toolkit

bugzilla at redhat.com bugzilla at redhat.com
Sun Nov 8 01:25:04 UTC 2009


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


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





--- Comment #53 from Jason Tibbitts <tibbs at math.uh.edu>  2009-11-07 20:24:58 EDT ---
I've had no time for reviews recently, but I have a little now.

This builds find on rawhide, but not F11 because of the clipper-devel
dependency.  A version build for F12 will install on F11 but won't run.  My
"not-quite-F12" boxes are all at work, which makes testing difficult; I can run
it remotely, but it fails with "*** Cannot find the double-buffered visual." 
Looks like you just can't go GLX over SSH, which I swear used to work OK. 
Unfortunately I can't really do a proper review if I can't do any testing.

Anyway, I can make a few comments:

The build is fine; rpmlint has just the expected unused-direct-shlib-dependency
complaints, along with a couple of shared-lib-calls-exit and a single
no-documentation complaint, all of which are OK.

When I installed this I tried to find the icon, only to find that it shows up
in the Graphics category.  Unfortunately the desktop file spec doesn't really
have a top-level category that fits this package, but I'd at least expect to
see "Graphics;Science;", maybe with Engineering or DataVisualization if they're
appropriate.

Honestly the only real issue I see at this point is the wholesale inclusion of
unrelated upstream projects in the coot/scheme directory.  Generally we don't
do that kind of thing; it's basically the situation from
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
I didn't really notice before that those were separate projects; I originally
thought they were part of coot but carried different licenses.  Now I see that
they are merely prerequisites that shouldn't be part of this package.

Honestly I don't know what to do about that.  I guess I'd package guile-gui,
goosh and net-http separately (although probably using a "guile-" prefix for
the latter two) and then figure out how to make this package use the packaged
versions.  Unfortunately I know very little about guile; jugding from the
guile-lib package, it should be as simple as sticking the scheme files in
%{_datadir}/guile/site/goosh or whatever.  Getting coot to use those files may
be more difficult; I'm not at all sure.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.




More information about the package-review mailing list