[Bug 809614] Review Request: gfal2 - Grid file access library 2.0

[bugzilla at redhat.com]

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 at gmail.com> 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.