Created attachment 889395 [details]
glog source RPM

I should probably also mention, this is in fact my first package so according to the readme page I'll need someone to sponsor it.

Maintaining these packages is something I expect to be part of my full time job, so I will do my best to reply quickly during business hours M-F (US/Eastern) to anything that may need to be cleaned up in the specfiles.

Please, contact the package maintainers (https://admin.fedoraproject.org/pkgdb/acls/name/gflags?_csrf_token=a87fe13661189960a4e31319b84f44cc4a152014 and https://admin.fedoraproject.org/pkgdb/acls/name/glog?_csrf_token=a87fe13661189960a4e31319b84f44cc4a152014) to expose them these issues.

Please, read carefully http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Ensure_the_software_you_wish_to_package_is_suitable and http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

Also, all packages MUST be reviewed one by one.

This should not be a review request, just upgrade request. Reassign to the relevant component.

Dan, I've done some spec file cleanup (http://pkgs.fedoraproject.org/cgit/gflags.git/tree/gflags.spec) and pushed gflags 2.1.1 to rawhide (http://koji.fedoraproject.org/koji/taskinfo?taskID=6803019). Please try it.

But there are some problems with gflags2.
gflags.x86_64: E: invalid-soname /usr/lib64/libgflags_nothreads.so libgflags_nothreads.so
The soname of the library is neither of the form lib<libname>.so.<major> or
lib<libname>-<major>.so.
gflags.x86_64: E: invalid-soname /usr/lib64/libgflags.so libgflags.so
The soname of the library is neither of the form lib<libname>.so.<major> or
lib<libname>-<major>.so.

I'll ask upstream about this issue. I think it would be better if they add soname.

Asked: https://code.google.com/p/gflags/issues/detail?id=82

John, thanks for getting in touch regarding these issues and the related pull requests. I will be glad to help out modifying the CMake configuration where needed to facilitate a clean packaging for Fedora.

Dan, the glog related build conflicts with gflags 2 were fixed on the day these were reported (March 26th). Not sure how you come to the conclusion "it looks like they don't pay any attention to their issue tracker"... ;)

Andreas, thank you for your help and fast responses. I think, gflags package is good now :)

About glog. I applied Dan's patch (http://pkgs.fedoraproject.org/cgit/glog.git/plain/glog-0.3.3-gflags-namespace.patch) that fix build with new gflags. I didn't find related commits in glog repository. Could you give us link to it?

My bad, I was actually referring to the gflags issue tracker, unlike Dan who was talking about glog as I realized only after my comment.

The changes related to the gflags issues:
- https://code.google.com/p/gflags/issues/detail?id=79&can=1
- https://code.google.com/p/gflags/issues/detail?id=80&can=1
are meant to help users circumvent the issue with glog and to maintain backwards compatibility with gflags 1.x and gflags 2.0 (i.e., before CMake).

I think the option "-DGFLAGS_NAMESPACE:STRING=google" would be needed. However, as gflags is no longer maintained by Google and the header files are already for longer time in "include/gflags/", the namespace of the C++ symbols should reflect this as well. The gflags Fedora package should therefore probably use the default GFLAGS_NAMESPACE.

One other solution regarding glog/gflags namespace issue which does not require patching glog but modification of gflags instead could be to add the "using namespace gflags;" directly to the "gflags/gflags.h" header file... which of course is in general not desirable and thus must be optional. Maybe something like

  // set default for GFLAGS_USE_NAMESPACE during gflags build configuration
  #ifndef GFLAGS_USE_NAMESPACE
  #  define GFLAGS_USE_NAMESPACE @USE_NAMESPACE@
  #endif
  // import symbols into global namespace
  #if !GFLAGS_USE_NAMESPACE
  using namespace @GFLAGS_NAMESPACE@;
  #endif

Now this would of course either require the Fedora package to build gflags with GFLAGS_USE_NAMESPACE disabled and users would need to include it as follows if they don't want this

  #define GFLAGS_USE_NAMESPACE 1
  #include <gflags/gflags.h>

or, GFLAGS_USE_NAMESPACE is only disabled by default if GOOGLE_NAMESPACE is defined as done by glog's config.h, i.e.,

  #ifndef GFLAGS_USE_NAMESPACE
  #  ifdef GOOGLE_NAMESPACE
  #    define GFLAGS_USE_NAMESPACE 0
  #  else
  #    define GFLAGS_USE_NAMESPACE 1
  #  endif
  #endif

All this is of course not really ideal, but would somewhat enable the same gflags installation to be used by other Google projects which assume the deprecated "google" namespace for gflags and by projects that use the new "gflags" namespace. Most of the time, it is probably even ok to have the gflags library functions in the global namespace as all functions have the terms "flag" or "commandline" in their name and somebody is unlikely using two command-line parsing libraries together.

Any thoughts on these suggestions? (though for you it might be fine to just keep the patch)

With a bit more work, but cleaner, I could add a header file "gflags/gflags_google.h" that is included by "gflags/gflags.h" (if backwards compatibility set during gflags build configuration). This file could contain the following using statements:

// import all public symbols that existed before gflags 2.1
// from the new gflags namespace into the google namespace
namespace google {

  using gflags::RegisterFlagValidator;
  using gflags::CommandLineFlagInfo;
  // ...

}

I think this should do it and would probably be the best solution until all Google projects such as glog which use gflags are updated.

Andreas, thank you. I think keep patch in glog package is fine while we don't see any activity in glog upstream.

BTW, I like idea with gflags/gflags_google.h. It will help other projects to migrate to gflags2.

Sounds good.

Just for reference, here's the issue for tracking the addition of gflags/gflags_google.h to avoid the code breaking namespace change:

https://code.google.com/p/gflags/issues/detail?id=83&thanks=83&ts=1399025358