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=809614 --- Comment #5 from adev <adev88@xxxxxxxxx> 2012-04-13 18:40:08 EDT --- Thank you a lot Ricardo for this review, I have updated the sources from your comments. Spec URL: http://firwen.org/home/specs/gfal2.spec SRPM URL: http://firwen.org/home/specs/gfal2-2.0.0-0.6.beta.el5.centos.src.rpm > W: spelling-error -> all corrected, descriptions have been updated for more explicit ones. > gfal2.x86_64: W: no-manual-page-for-binary gfal2_version -> done > gfal2-core.x86_64: W: executable-stack /usr/lib64/libgfal2.so.2.0.0 GFAL 2.0 uses a lot the GCC C nested functions in the current state, the nested functions usage needs an executable-stack. This cannot be avoided. > MUST: The package must be named according to the Package Naming Guidelines. > Sorry for pointing this again, but i find it confusing to have a new package > due to a backwards incompatible change. Proceed to a so bump will break existing working packages that relies on gfal ( 1.0 ) functionalities that has been suppressed on gfal 2.0. this will probably cause more troubles than benefits. Concerning the versioning the old gfal, several externals meta-packages ( EMI project, glite-projects ) depends directly on the gfal package names in differents project, and I wish to not not break this. Indeed, several populars packages like glib -> glib2, gtk -> gtk2, sqlite -> sqlite2, glade -> glade2, ... etc.. proceed in the same way than gfal -> gfal2. I think that the changes between gfal 1.0 and gfal 2.0 are too big to be considered like a simple update, or a transparent name swap. > MUST: In the vast majority of cases, devel packages must require the base > package using a fully versioned dependency: Requires: %{name} = > %{version}-%{release} -> corrected too. Thank you again. -- 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