https://bugzilla.redhat.com/show_bug.cgi?id=804125
--- Comment #11 from Gianluca Sforna <gia...@gmail.com> --- (In reply to Jason Tibbitts from comment #10) > "cal 2012" tells me that October 21st 2012 was a Sunday, not a Wednesday. Fixed > > One new non-executable-script complaint: > > python-rdkit.x86_64: E: non-executable-script > /usr/lib64/python2.7/site-packages/rdkit/Chem/MCS.py 0644L /usr/bin/env > > and one old one: > > python-rdkit.x86_64: E: non-executable-script > /usr/lib64/python2.7/site-packages/rdkit/utils/pydoc_local.py 0644L > /usr/bin/env > > Not sure what you want to do with those. The first one is really a python module, so I removed the shebang. The second I am not sure, asked upstream. > > Still some spurious-executable-perm complaints in the debuginfo package. > Why would cpp and header files be executable in the source tree? not intentional I guess, reported upstream > > Could you comment on the purpose of these? Would it not be better for these > to be packaged as documentation? Actually, that pretty much goes for the > rest of the stuff in rdkit-extras; at least the Contrib stuff doesn't seem > to be terribly useful just sitting under /usr/share. > > rdkit-extras.noarch: W: devel-file-in-non-devel-package > /usr/share/RDKit/Contrib/PBF/PBFRDKit.h > rdkit-extras.noarch: W: devel-file-in-non-devel-package > /usr/share/RDKit/Contrib/PBF/demo.cpp > rdkit-extras.noarch: W: devel-file-in-non-devel-package > /usr/share/RDKit/Contrib/PBF/PBFRDKit.cpp > The extras are examples of actual rdkit usage. I am not sure where it is best to put them in the filesystem, but if consensus is they should go in docs I can surely move them. > Can you comment on the stuff in the External directory? I just want to make > sure none of it is bundled external code. > > Also on the subject of the External directory, some of it is differently > licensed (cmim is GPL, pymol is "Pymol", whatever that is). Can you be > certain that none of that is included in the final package? If not, the > License: tag will need modification. That is supposed to contain glue code to USE external code. For instance, inchi is pulled as a dep and linked as usual. pymol is code from upstream, I asked to put there a proper license. I also asked upstream about cmim, it seems from the build logs it is using just a couple modules from that, maybe it can be replaced or disabled. > > Why do all of the libraries seem to carry a "1beta1" when this is versioned > as a post-release package? not sure why it was there, but the suffix looks correct in the latest package > > I kind of wish the masses if library files all carried a some sort of > "libRD" prefix, because there are so many of them and they appear to be > rather generically named, especially "libhc.so". Yeah, I can propose upstream to add a prefix on all, nice to see no conflicts were found though. http://giallu.fedorapeople.org/rdkit.spec http://giallu.fedorapeople.org/rdkit-2013.03.2-1.fc18.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EQXr2PQ4JE&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
