Bug 6229 - Installing GPT in /usr
: Installing GPT in /usr
Status: NEW
: Installation
: unspecified
: PC Linux
: P3 enhancement
: ---
Assigned To:
  Show dependency treegraph
Reported: 2008-07-16 01:16 by
Modified: 2009-03-13 15:01 (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2008-07-16 01:16:01

It is not very easy to install GPT cleanly in /usr and abiding to the standard
filesystem hierarchy standard. I have created a set of patches that achieves
this, but I am not sure if you as the upstream maintainer are interested in
these - you might consider them out of scope. Anyway, I wanted to let you know
and you decide what you want to do with them, if anything.

1. http://www.grid.tsl.uu.se/repos/globus/fedora/9/info/gpt-perlpath.patch

This patch installs the perl modules in the standard location suitable for a
system installation.

2. http://www.grid.tsl.uu.se/repos/globus/fedora/9/info/gpt-share.patch

Static data file that are not changed after installation should be in share not
etc. This patch move the static files to share.

3. http://www.grid.tsl.uu.se/repos/globus/fedora/9/info/gpt-usr.patch

An installation in /usr should not depend on environment variables. This patch
introduces a default /usr location instead of bailing out with an error if

4. http://www.grid.tsl.uu.se/repos/globus/fedora/9/info/gpt-man.patch

The man page creation and installation is slightly broken. It e.g. creates
empty man pages for scripts that does not contain the required markup, and uses
non-standard installation locations. This patch fixes this.

5. http://www.grid.tsl.uu.se/repos/globus/fedora/9/info/gpt-bin.patch

User binaries should be in bin not sbin. This patch corrects the install
location for these. Historically, when e.g. an /opt/gpt installation was used
/opt/gpt/sbin was added to the PATH for all users (not only root). For an
installation in /usr this can of course no be done.

6. http://www.grid.tsl.uu.se/repos/globus/fedora/9/info/gpt-filelists.patch

This patch extends the GPT filelist generation to understand additional install
locations such as e.g. lib64 for 64 bit libraries.

Once again, I am not sure you consider these patches to be relevant for you,
but I wanted to let you know about them.

Best regards to you,

------- Comment #1 From 2008-07-16 01:50:00 -------
*** Bug 6228 has been marked as a duplicate of this bug. ***
------- Comment #2 From 2008-10-13 09:08:45 -------
Hi Charles!

I have now created a new set of patches for gpt taking your comments into
account. The patches used for the new RPM are available here:


> I believe the idea is that mostly administrators use GPT, not end-users.
> I would be perfectly happy if you moved the manpages over to section 8.

I have dropped the bin patch in the new set of patches at your request. The new
patches also move the man pages to section 8.

> I need the tools to work with just $GPT_LOCATION set for our non- 
> system installations.  I think you may be right that this is one to  
> leave to the Fedora patchset.  As an aside, given enough time I can  
> try to incorporate the Fedora-specific rules back to upstream, but  it  
> will take a while before I can get around to doing so.  So if you can  
> choose a method for Fedora that will also work for me if I can make  
> some small changes later, I would appreciate that.  Also of interest,  
> we would like to see if we could make this available as a Debian- 
> packaged .deb also.  I will go back and take a look at their rules,  
> which seem similar to Fedora's, and see if there's any way we can make  
> the Fedora patches a more generic "acceptable to linux distros" set  
> of patches.

The new set of patches by default adds symlinks to the old locations so that
you can build the GT 4.2.1 release with the patched gpt without bootstrapping.
I have added a --disable-compat option that disables the creation of the
symlinks which gives you a standard complying file hierarchy. If you use this
option (as I do in the build for the RPM) you need to rebootstrap all the
globus packages, but this option is not activated by default.

I am happy that you mentioned debian. Debian is even more strict in its FHS
compliance than redhat in that it does not allow installations in libexec. My
patches allows to use --libexecdir='${datadir}/gpt' when building GPT (and
--libexecdir='${datadir}/globus' for the globus packages to get a true FHS
compliant installations. I use this also for my Fedora packages even though
Fedora still tolerates installations in libexec. Being able to do this is
necessary for debian anyway. [The vast majority of files installed by globus in
libexec are really scripts, so the ${datadir}/globus location is really the
most appropriate (the alternative would be ${libdir}/globus - but that is not
really suitable for scripts). For the few files installed in libexec that are
really binaries my patches move them to sbin.]

The new patches are really backwards compatible if used with the default
configuration options. I made a few tests where I

1) patch gpt and build globus core and common without changes.

2) patch gpt, build gpt, patch globus core, rebootstrap and build globus core,
build globus common without changes.

3) patch gpt, build gpt, patch globus core, rebootstrap and build globus core,
patch globus common, rebootstrap and build globus common.

The scripts for these tests are available in

This means that if the default options are used it is possible to fix one
package at a time and leave the others alone. But you need to fix globus core
first since changes in globus core influence the bootstrapping of the other
packages. Once core is fixed the order for fixing the other package is mainly

Gpt, globus core and globus common are the packages that need the most patches.
The rest of globus almost (with a few exceptions) only needs rebootstrapping to
take advantage of the changes to gpt, core and common.

I have submitted my patches to core and common to the globus bugzilla.

> Yes, filesystem layout is one of our real problems.  I will note that  
> the existing GPT logic has a search path for packaging metadata.  It  
> will look in either $GLOBUS_LOCATION/etc/globus_packages or  
> $GLOBUS_LOCATION/etc/gpt/packages.  Might I suggest that you add share/ 
> gpt/packages to the list?

The new set of patches supports all three locations by default. If configured
with --disable-compat only the share/gpt/packages location is supported, since
this is the only one that is standard compliant.

Regarding the sed replacements, you said:

> I'll have to look at these, it has been a long time since I've had to  
> look inside out bootstraps.  Could you perhaps say in language what  
> the sed scripts are accomplishing?

The two I mentioned that would be of relevance for upstream are

for f in `find . -name Makefile.am` ; do
  sed -e 's!^flavorinclude_HEADERS!include_HEADERS!' \
      -e 's!^lib[a-zA-Z_]*_la_LDFLAGS\s*=\s*!&-version-info
  $f > $f.new
  mv $f.new $f

The first sed replacement is for the way globus installs headers. Globus
installes all headers in flavorheaderinclude, though it is really only the
globus_config.h header in globus core that is different between flavors, so in
all other packages the headers can be installed in the standard include
directory. (So don't do this replacement for globus core.) In my packages I
change the header installation paths at configure time to more reasonable
standard locations:

  --includedir='${prefix}/include/globus' \

Due to my sed replacement only the globus_config.h file ends up in the flavored
include directory. This is the standard way for other packages like glib,
glibmm and gtk to install flavored and non-flavored headers.

I have made sure that tools like globus-makefile-header work and gives the
right result if relocation of the include directories are changed with
configure. And the fixed gpt package handles non-flavored headers correctly,
which the old version did not do.

The second sed replacement is for the versions of the libraries. At present the
version numbers of the packages are not reflected in the version numbers of the
libraries. The gpt packages have a standard major, minor, age version triplet
and converting this to a -version-info flag in the LD_FLAGS is a piece of cake.
It does however require the gpt bug #6225 and the globus core bug #6455 are
fixed to work. It really looks silly to have all these libX.so.0.0.0 libraries,
especially when the correct numbers are available.

Thank you for your feedback, I think it has made the packages even better.
------- Comment #3 From 2008-10-24 13:36:14 -------
Just finished testing a full installer with gpt + globus_core (using the alt
patch) and it works and passes tests.  There's one hangup for me right now, in
that there is a package that installs four files in a binary installer into
etc/gpt/packages.  It's not GPT metadata, so it can be moved elsewhere, but
that pollution means I can't just symlink etc/gpt to share/gpt until it is
fixed.  Once that is cleaned up (which should be a simple change to the four
RFT packages and the deploy-gar script) I can commit the GPT+globus_core
changes into HEAD.
------- Comment #4 From 2008-12-09 03:00:52 -------
I have found a minor glitch in one of the patches, so I have updated it on the
web site:


The change between this and the previous version is that it changes the line

    $(POD2MAN) $$p > $(DESTDIR)$(mandir)/man8/$$script.8; \


    $(POD2MAN) --section 8 $$p > $(DESTDIR)$(mandir)/man8/$$script.8; \

in packaging_tools/Makefile.am and packaging_tools/Makefile.in
------- Comment #5 From 2009-03-13 15:01:55 -------
Reassigning to gt-dev@globus.org pending triage of these bugs following my