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 #6 from Ricardo Rocha <rocha.porto@xxxxxxxxx> 2012-04-14 12:42:06 EDT --- Hi. (In reply to comment #5) > 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 A patch would have been fine too. I see you updated the tarball without changing the version - probably not a good idea to do it again i guess, otherwise you'll get inconsistencies between what is pointed by the spec and what's in the srpm. If you're building the tar upstream from an evolving branch, consider adding a date, as in: http://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control I think it would be cleaner, it will help you debug later. > > 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. Ok, i'll let you decide if you want to add a bug upstream to fix it later. > > 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. Ok. > > > 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. You seem to have added for all but gfal2 and gfal2-transfer. Maybe add it there too? Let me know what you think, this should be pretty much done. Regards, Ricardo > > 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