[Bug 517763] Review Request: voms - Virtual Organization Membership Service

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





--- Comment #2 from Mattias Ellert <mattias.ellert at fysast.uu.se>  2009-08-27 05:23:45 EDT ---
(In reply to comment #1)
> Hi Mattias,

Hi!

> 1) First the simple rpmlint errors.
> 
> voms.src:387: W: libdir-macro-in-noarch-package vomsjapi %{_libdir}/gcj/%{name}
>   (Should be fixed)

This is a false warning from rpmlint. The reason for the false warning is that
rpmlint does not interpret specfile conditionals. All Java packages that follow
the guidelines for packaging ahead-of-time compiled Java triggers this false
warning.

> voms-devel.x86_64: W: no-dependency-on voms/voms-libs/libvoms
>    (I'm not sure what this is)

This warning is due to that the current rpmlint version does not support
%{_isa} tags. This has been fixed in the rpmlint sources, but there is no new
rpmlint release yet. This warning will go away when the next rpmlint version is
released.

> voms-devel.x86_64: W: no-documentation
>     (okay)

> voms-server.x86_64: E: subsys-not-used /etc/rc.d/init.d/voms
>      (should be easy enough to add or maybe it looks like a <vo> specific lock 
>       is created? Its tricky I don't know of anything else that launches 
>       multiple deamons per configuration)

The init.d script is using subsys, however the rpmlint check greps for the
string "/var/lock/subsys", and the script in the voms package has
"$VOMS_LOCATION_VAR/lock/subsys" where VOMS_LOCATION_VAR has been set to /var.

> voms-server.x86_64: W: incoherent-init-script-name voms ('voms-server',
> 'voms-serverd')
>      (okay)

> 2) Why is it?
> 
> %package -n vomsjapi
> and not just
> %package japi

Fedora Java Packaging guidelines says:

"If a package provides a single JAR file it must have the same name as the
package itself."

See: https://fedoraproject.org/wiki/Packaging:Java#Jar_file_naming

> 3) After installing voms-server
> # service voms start
> ls: cannot access /etc/voms: No such file or directory
> [root at globus x86_64]# echo $?
> 0
> 
> /etc/voms should be created and owned by the package.

Fixed.

> I guess (not checked) voms is the directory containing the 
> <vo>/voms.conf files? If so maybe /etc/voms.d/ might be better?

I'd rather not change this, since many scripts has this location hardcoded.

> 3.1) Is it worth adding an example configuration and perhaps a README.Fedora
>       to describe simply how to get up and running? Create database., ...

Fixed.

> 4) Given there is no need to run voms as root ( except host cert) is 
>    it a good idea to add a voms user and run as that? I realise it gets
>    to a point where the init script ends up being written from scratch.

Fixed. No need to rewrite the script, only add a /etc/sysconfig/voms file
defining the user - now included in the package.

> 5) For my own education I expect in 
> BuildRequires: globus-gssapi-gsi-devel%{?_isa}
> why/how is the %{?_isa} added?

On a multilib installation (e.g. i386/x86_64) the "BuildRequires:
globus-gssapi-gsi-devel" is satisfied by both the i386 and x86_64 RPM package.
By adding the %{?_isa} you explicitly request the right version (provided the
version of RPM used by the distribution is new enough to support it).

> 6) Concerning EPEL support this is probably only difficult because 
>    of the bouncycastle requirment which requires a slew of missing 
>     dependencies. Could it be built without the javaapi support? It
>    is a lot less important I would say.

EPEL packages can be built without the Java API.

> Steve.  

New version is here:

Spec URL: http://www.grid.tsl.uu.se/review/voms.spec
SRPM URL: http://www.grid.tsl.uu.se/review/voms-1.9.11-2.fc11.src.rpm

Mattias.

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