[Bug 675050] Review Request: cloudfs - Cloud Filesystem

[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=675050

--- Comment #5 from Jeff Darcy <jdarcy at redhat.com> 2011-02-04 10:14:47 EST ---
(In reply to comment #4)
> /usr/include/glusterfs/iatt.h
> contains
> #include "uuid.h"
> 
> This means this file want to include /usr/include/uuid.h

To be more precise, it means that it wants to include uuid.h from the first
place in its include path where it exists, where said include path by default
has /usr/include and some gcc-version-specific directories unless -nostdinc is
used.  It's not uncommon at all for programs to include their own headers
without full qualification, and the use of quotes instead of angle brackets is
commonly taken as a hint that they're doing so.

> This also is a questionable and error-prone design, because 
> passing -I/usr/include/glusterfs then will shadow /usr/include/uuid.h, 
> i.e. render including both headers from inside of the same build directory will
> become difficult.

I completely agree.  Nonetheless, they are the upstream for that package and
that's the way their headers are structured.  I guess the most relevant issue
is whether this questionable practice in the glusterfs package should be a
blocker for cloudfs.  They might understandably be reluctant to change a
working (though inelegant) header structure for Fedora-packaging purposes, and
rearranging the headers ourselves in our glusterfs package would seem to
violate the "stay close to upstream" guideline.

What I can do, within cloudfs, is eschew "-I/usr/include/glusterfs" in the
makefiles and use "#include <glusterfs/..." instead.  Would that be
satisfactory?

> I'd recommend glusterfs to change their headers to using <glusterfs/...h>.
> 
> > This file was not installed
> > prior to glusterfs-devel-3.1.2-2, which is why I mentioned it above, but with
> > that version it does build.
> In this case, your build requires are not strict enough.

Thanks for catching that.  I did update Requires, but I see that I missed
updating BuildRequires as well.

> Probably - I was building your package in mock with what was current then 
> (And yes, Fedora's repos being out of sync and/or being broken is an often
> occuring and long-term persisting issue to me).

FWIW, I did compile using a virtual machine that had never even seen mock
before, to ensure that it was a clean environment.  As long as I mock-installed
last night's version of glusterfs-devel first (pulled via wget) the cloudfs
SRPM seemed able to compile fine.

-- 
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.