https://bugzilla.redhat.com/show_bug.cgi?id=957693 --- Comment #7 from Adrien Devresse <adev88@xxxxxxxxx> --- Thank you for your comments Mario > The library is private in terms of not intended to be present in a common library path. It has to become "invisible". See http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering for how to do so. Done > This is vaild for EPEL 5, and *only* for that branch. Of course, you can leave it as is for el5. But for all newer releases, a doc package which contains no binaries should be noarch. Fix the other issues, and I will do the final review. I resolved the issue by excluding the BuildArch: noarch with a conditional on EL5. Several packages like json-c uses the same approach. > Keep in mind, different branches need different spec files in certain cases. Have a look at the guidelines where are some special parts for EPEL 5 which are not intended to be entrained through all newer branches. Times have changed ;) Yes, but even in this case I prefer use only one spec file with conditionals statements instead of branching my spec. And I'm not preferring this just in to contradict you or because I'm lazy :) With the frequency of our updates and the number of our the grid middlewares components, it's just impossible to maintain without becoming mad if we start to branch for each plateform. Updates : SRPM: grid-deployment.web.cern.ch/grid-deployment/dms/lcgutil/tar/gfal2-python-1.2.1-1.el5.centos.src.rpm SPEC : grid-deployment.web.cern.ch/grid-deployment/dms/lcgutil/tar/gfal2-python-1.2.1-1.el5.centos.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=iRCWVwAmjV&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review