Bug 478931

New version
- Added s390x as 64 bit arch
- Added comment documenting source
- Adapt to changes in the globus-core package

http://www.grid.tsl.uu.se/repos/globus/fedora/10/src/SRPMS/globus-rls-server-4.7-0.5.fc10.src.rpm
http://www.grid.tsl.uu.se/repos/globus/info/globus-rls-server.spec

Package updated due to new packaging guidelines
- Change defines to globals
- Remove explicit requires on library packages

http://www.grid.tsl.uu.se/repos/globus/info/new/globus-rls-server-4.7-1.fc10.src.rpm
http://www.grid.tsl.uu.se/repos/globus/info/new/globus-rls-server.spec

Draft packaging guidelines for Globus packages are now available:
http://fedoraproject.org/wiki/PackagingDrafts/Globus

This one was quite different from the other globus packages. Here is my review:

- package builds in koji rawhide
   http://koji.fedoraproject.org/koji/taskinfo?taskID=1394353

? I don't know if this
   BuildRequires:  globus-gssapi-gsi-devel >= 4
is really required, since
   $ grep -rl gssapi *
   pkgdata/pkg_data_src.gpt.in
Is it an upstream error or am I missing something?

* Afaik %setup is supposed to be used only once in a specfile. So
   %setup -q -n %{_name}-%{version}
   %setup -D -T -q -n %{_name}-%{version} -a 1
should be replaced by
   %setup -q -n %{_name}-%{version} -a 1

? Actually, why are you not making globus_rls_server_setup a package on its own?

! It would be good to briefly explain what Source{1,2,3} are for where you declare them.

* rpmlint complains
   globus-rls-server.x86_64: E: wrong-script-interpreter /usr/share/globus/setup/SXXrls.in "@SHELL@"
   globus-rls-server.x86_64: E: non-executable-script /usr/share/globus/setup/SXXrls.in 0644
   globus-rls-server.x86_64: E: non-readable /etc/globus-rls-server.conf 0600
   globus-rls-server.x86_64: W: no-reload-entry /etc/rc.d/init.d/globus-rls-server
Any words for these?

! Please preserve the timestamp of %{SOURCE3} in %install

! There is some html documentation under ./Doc that can be packaged. Also there is an INSTALL.html

! I don't know how serious they are but 
   Doc/man/man8/globus-rls-server.8
   Doc/html/globus-rls-server.html
   server.c
contain references to /usr/local. You might want to fix them.

? /usr/share/globus/setup/setup-globus-common.pl defines perl location as 
   /usr/lib/perl/
Will this be a problem?

? Are the tests under ./test worth running in %check ? 

! The package owns the directory
   /usr/share/globus/packages/setup/
I wasn't sure if this is intentional (or if its contents should actually go to /usr/share/globus/packages/globus_rls_server_setup/) and just wanted to bring it into your attention.

* The scriplets are different than the ones in the guidelines:
   http://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscripts_in_spec_file_scriptlets
(See the Requires(*) stuff)

* %{_initrddir}/%{name} does not contain all the required actions
   http://fedoraproject.org/wiki/Packaging/SysVInitScript#Required_Actions

? The "status" action in %{_initrddir}/%{name} has the port number hard-coded. Shouldn't the port number be taken from %{_sysconfdir}/%{name}.conf ?

(In reply to comment #3)
> This one was quite different from the other globus packages. Here is my review:
> 
> - package builds in koji rawhide
>    http://koji.fedoraproject.org/koji/taskinfo?taskID=1394353
> 
> ? I don't know if this
>    BuildRequires:  globus-gssapi-gsi-devel >= 4
> is really required, since
>    $ grep -rl gssapi *
>    pkgdata/pkg_data_src.gpt.in
> Is it an upstream error or am I missing something?

Yes, this is a bogus requirement stated in the upstream package description file - fixed (patch updated too)

> * Afaik %setup is supposed to be used only once in a specfile. So
>    %setup -q -n %{_name}-%{version}
>    %setup -D -T -q -n %{_name}-%{version} -a 1
> should be replaced by
>    %setup -q -n %{_name}-%{version} -a 1

You can have as many %setup lines you want as long as all except the first one has a -D flag in order not the trigger the deletion of already unpacked sources

Quoting http://www.rpm.org/max-rpm/s1-rpm-specref-macros.html

"The -D option is used to direct %setup to not delete the build directory prior to unpacking the sources. This option is used when more than one source archive is to be unpacked into the build directory, normally with the -b or -a options."

> ? Actually, why are you not making globus_rls_server_setup a package on its
> own?

See:

https://fedoraproject.org/wiki/PackagingDrafts/Globus#Setup_packages

and

https://fedoraproject.org/wiki/PackagingDrafts/Globus#Globus_package_that_provides_both_a_library_and_programs_and_that_has_a_corresponding_setup_package

The example above is from globus-common which already does the same (packaging globus-common and globus-common-setup in the same SRPM).

> ! It would be good to briefly explain what Source{1,2,3} are for where you
> declare them.

Comments added.

> * rpmlint complains
>    globus-rls-server.x86_64: E: wrong-script-interpreter
> /usr/share/globus/setup/SXXrls.in "@SHELL@"
>    globus-rls-server.x86_64: E: non-executable-script
> /usr/share/globus/setup/SXXrls.in 0644
>    globus-rls-server.x86_64: E: non-readable /etc/globus-rls-server.conf 0600
>    globus-rls-server.x86_64: W: no-reload-entry
> /etc/rc.d/init.d/globus-rls-server
> Any words for these?

I removed the SXXrls.in file from the package - it is not useful for the RPM package anyway since the RPM uses a %{SOURCE2} as the init.d script instead.

The configuration file is intentionally non-readable by non-root users since it contains information about database username and password.

reload entry added to init.d script. It is empty since reloading is not supported - as mandated by the guidelines.

> ! Please preserve the timestamp of %{SOURCE3} in %install

OK - Done for %{SOURCE2} as well.

> ! There is some html documentation under ./Doc that can be packaged. Also there
> is an INSTALL.html

The INSTALL.html file would be confusing to users since it contains information about GPT and how to build from source which is not relevant when installing from the RPM. The relevant part of the post-installation instructions are available in %{SOURCE3} which is installed.

> ! I don't know how serious they are but 
>    Doc/man/man8/globus-rls-server.8
>    Doc/html/globus-rls-server.html
>    server.c
> contain references to /usr/local. You might want to fix them.

This is fixed by these lines already present in the spec file:

# Fix hardcoded default locations
sed 's!/usr/local/etc!/etc!g' -i server.c
sed 's!/usr/local/etc!/etc!g' -i Doc/man/man8/globus-rls-server.8

> ? /usr/share/globus/setup/setup-globus-common.pl defines perl location as 
>    /usr/lib/perl/
> Will this be a problem?

When using GPT as installed from the Fedora RPM the GPT perl module is already in the default module path - so it will be found. The additions to the perl include path of the $GPT_LOCATION/lib/perl directory (where they would be by default in a configure, make, make install type installation) does not break anything when using the RPM version.

> ? Are the tests under ./test worth running in %check ? 

The test requires a postgres server where you are allowed to create and modify tables - not something you want to do during an RPM build.

> ! The package owns the directory
>    /usr/share/globus/packages/setup/
> I wasn't sure if this is intentional (or if its contents should actually go to
> /usr/share/globus/packages/globus_rls_server_setup/) and just wanted to bring
> it into your attention.

This is intentional.

> * The scriplets are different than the ones in the guidelines:
>   
> http://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscripts_in_spec_file_scriptlets
> (See the Requires(*) stuff)

The scriptlet requires are added.

> * %{_initrddir}/%{name} does not contain all the required actions
>    http://fedoraproject.org/wiki/Packaging/SysVInitScript#Required_Actions

The missing actions added (see also the rpmlint section above).

> ? The "status" action in %{_initrddir}/%{name} has the port number hard-coded.
> Shouldn't the port number be taken from %{_sysconfdir}/%{name}.conf ?  

Fixed.

New version:

http://www.grid.tsl.uu.se/repos/globus/info/new/globus-rls-server-4.7-2.fc10.src.rpm
http://www.grid.tsl.uu.se/repos/globus/info/new/globus-rls-server.spec

Thanks for the fixes!

----------------------------------------------------
This package (globus-rls-server) is APPROVED by oget
----------------------------------------------------

So this was the last one. Are there going to be more? You can add me to the CC if you submit more globus review requests.

Thank you for all the reviews. There were a few bumps along the way, but we got there in the end. I think writing the Globus specific packaging guidelines helped pave the way.

There are more Globus packages, but just right now I have not immediate plans for more - though I am open for requests from Globus users - the Globus gridftp server might be on the horizon eventually.

My next set of packages will be some other pieces of Grid computing software which is not part of the Globus toolkit, but that are built against its libraries.

New Package CVS Request
=======================
Package Name: globus-rls-server
Short Description: Globus Toolkit - Replica Location Service Server
Owners: ellert
Branches: F-9 F-10 F-11 EL-4 EL-5
InitialCC:

CVS done.

globus-rls-server-4.7-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/globus-rls-server-4.7-2.fc9

globus-rls-server-4.7-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/globus-rls-server-4.7-2.fc10

globus-rls-server-4.7-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/globus-rls-server-4.7-2.fc11

globus-rls-server-4.7-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

globus-rls-server-4.7-2.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

globus-rls-server-4.7-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.