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=542990 --- Comment #5 from Mattias Ellert <mattias.ellert@xxxxxxxxxxxx> 2010-02-19 02:57:28 EST --- (In reply to comment #4) > Hi Mattias, > I make a scrutiny into your spec file, it's so sophisticated ^_^. > I have some problems about your spec. > 1.Did html.C generate all documention removed by patch10 to patch15? The patches removes pieces of the documentation markup that causes errors during documentation generation. They cause errors like: *** Interpreter error recovered *** Error in <TDocMacroDirective::HandleDirective_Macro>: Error processing macro MAC RO_TGraph2D_3! or: Error: illegal pointer to class object para 0x0 1367 MACRO_TParallelCoord_1.Cex ec:7: Error: illegal pointer to class object grade 0x0 1368 MACRO_TParallelCoord_1.Ce xec:8: Error: illegal pointer to class object para 0x0 1367 MACRO_TParallelCoord_1.Cex ec:9: Error: illegal pointer to class object para 0x0 1367 MACRO_TParallelCoord_1.Cex ec:10: Error: illegal pointer to class object para 0x0 1367 MACRO_TParallelCoord_1.Cex ec:11: Error: illegal pointer to class object age 0x0 1368 MACRO_TParallelCoord_1.Cexe c:12: > 2.What is the purpose of list libPyROOT.so twice? python binding normally can > only be used in python program, thus only need to be included in > python_sitearch. No, the Python interface in libPyROOT.so works both ways. You can load in Python to call root from Python, but you can also load it in root to call Python from root. > 3.There seems some dynamic libraries are plugins actually, they don't have > devel files. > See http://packages.debian.org/source/sid/root-system Most of roots libraries do double duty as plugins and dynamic libraries. It is difficult to distinguish if one of them is a plugin only. And some library that in one version of root is only a plugin can in the next version suddenly start being used as a dynamic library too. And a library that inside root is only a plugin can be used as a dynamic library by someone that develop their own software against the root libraries. Also, since root uses the C++ interpreter CINT it needs access to it's headers at runtime. So the headers can not be split off to devel packages without making the runtime and devel packages depend on each other - and then what is the use of doing the split. So in my mind there are no devel files at all, and hence I have not split off any devel packages. -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review