Bug 531252 - Review Request: lcgdm - LHC Computing Grid Data Management
Summary: Review Request: lcgdm - LHC Computing Grid Data Management
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Steve Traylen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 531254 531256 531258 (view as bug list)
Depends On:
Blocks: 531254 531256 531258
TreeView+ depends on / blocked
 
Reported: 2009-10-27 13:53 UTC by Mattias Ellert
Modified: 2010-04-26 23:27 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-04-22 22:47:20 UTC
steve.traylen: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)
Multiple sources in .src.rpms (7.74 KB, text/plain)
2009-12-09 23:16 UTC, Steve Traylen
no flags Details

Description Mattias Ellert 2009-10-27 13:53:27 UTC
Spec URL: http://www.grid.tsl.uu.se/review/lfc.spec
SRPM URL: http://www.grid.tsl.uu.se/review/lfc-1.7.3.1-1.fc11.src.rpm

Description:
The LCG File Catalog (LFC) keeps track of the locations of the physical
replicas of the logical files in a distributed storage system

Comment 1 Steve Traylen 2009-11-17 20:47:54 UTC
Hi,

Question: There is this lfc building mysql variant and Bug #531252
building a postgres variant.

Both look to be build from the same source file?

Is it possible not to merge these two packages?

Comment 2 Steve Traylen 2009-11-17 20:54:17 UTC
rpmlint errors.
lfc-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon

I've not looked at the file at the logrotate file at all.

Also it seems not to like "backend" as not being a en_US word. Hyphenate
I guess:

lfc-mysql.x86_64: W: spelling-error-in-summary en_US backend

Steve

Comment 3 Steve Traylen 2009-11-17 22:47:21 UTC
1) # rpm -Uvh lfc-1.7.3.1-1.fc13.x86_64.rpm 
error: Failed dependencies:
	liblcgdm.so.1()(64bit) is needed by lfc-1.7.3.1-1.fc13.x86_64

which is course provided by lcgdm-1.7.3.1-1.fc13.x86_64.rpm
it seems to be normal in these case to explicitly require lcgdb = %{version}-%{release} where the provides comes from one of the sub packages so as
not to end up with mixed versions of package.

 similar for lfc-mysql as well.

2) # /etc/init.d/lfc-mysql start
Starting lfcdaemon: FAILED : config file /etc/NSCONFIG empty

So this file should probably be there as an example or something?

I guess they come from these files which are apparently duplicated.

# cat /usr/lib64/lfc-mysql/NSCONFIG.templ 
<username>/<password>@<host>
[root@rawhide x86_64]# cat /usr/share/lfc/NSCONFIG.templ
<username>/<password>@<host>

3) The INSTALL-server-mysql is rather misleading to this RPM installation.

4) A quick read of the init.d script has 
   /etc/grid-security/$LFCUSER/lfccert.pem
   so that directory should probably exist.

5) The same LICENSE file looks to be duplicated in both lfc and lfc-mysql

6) I'm guessing a schema or at least a database has to be created?
   Maybe a README.Fedora?

Comment 4 Mattias Ellert 2009-12-09 10:23:39 UTC
Update:

Spec URL: http://www.grid.tsl.uu.se/review/lfc.spec
SRPM URL: http://www.grid.tsl.uu.se/review/lfc-1.7.3.1-4.fc12.src.rpm

(In reply to comment #1)
> Hi,
> 
> Question: There is this lfc building mysql variant and Bug #531252
> building a postgres variant.
> 
> Both look to be build from the same source file?
> 
> Is it possible not to merge these two packages?  

Actually there are 4 packages building from the same tarfile:

  - lfc (bug #531252 - this one)
  - lfc-postgres (bug #531254)
  - dpm (bug #531256)
  - dpm-postgres (bug #531258)

Unfortunately there is no sane way to build all this at the same time in the same source tree. The configure options for building LFC and DPM are mutually exclusive. The same is true for building the servers with mysql, postgres (or oracle) support. The oracle support we can't build for Fedora anyway since the oracle client libraries are not free - which is kind of fortunate since otherwise there would be 6 package.

If all the software were to be built in the same source RPM this source RPM would have to untar the source tarfile 4 times so that the build directory had 4 copies of the source tree, then apply the patches 4 times (once in each of the source trees), run configure 4 times with different options in each of the source trees, run make and make install 4 times. It would be a mess. Splitting it into 4 separate source RPMs seemed to be a much better way to do it to me. Each of these is more or less standard with setup, configure, make, make install.

(In reply to comment #2)
> rpmlint errors.
> lfc-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon
> 
> I've not looked at the file at the logrotate file at all.

The logrotate files are handled by alternatives so that there are not two copies of them installed in /etc/logrotate.d if you install both the mysql and postgres version of the services. The name of the symlink installed by the alternatives is the same for both packages and both packages own this symlink as a %ghost, as they should. However, since the name of this symlink must be the same for both packages it can not have the same name as the package, which is why rpmlint finds it "incoherent".

> Also it seems not to like "backend" as not being a en_US word. Hyphenate
> I guess:
> 
> lfc-mysql.x86_64: W: spelling-error-in-summary en_US backend

I don't get this complaint with my version of rpmlint.

(In reply to comment #3)
> 1) # rpm -Uvh lfc-1.7.3.1-1.fc13.x86_64.rpm 
> error: Failed dependencies:
>  liblcgdm.so.1()(64bit) is needed by lfc-1.7.3.1-1.fc13.x86_64
> 
> which is course provided by lcgdm-1.7.3.1-1.fc13.x86_64.rpm
> it seems to be normal in these case to explicitly require lcgdb =
> %{version}-%{release} where the provides comes from one of the sub packages so
> as not to end up with mixed versions of package.
> 
>  similar for lfc-mysql as well.

Since the choice of building liblcgdm together with the LFC or the DPM is arbitrary, the Requires should not depend on this choice, and since having %{version}-%{release} Requires across source RPMs is a bad idea ...

The same arbitrariness is true for building liblfc together with lfc-mysql or lfc-postgres.

> 2) # /etc/init.d/lfc-mysql start
> Starting lfcdaemon: FAILED : config file /etc/NSCONFIG empty
> 
> So this file should probably be there as an example or something?
> 
> I guess they come from these files which are apparently duplicated.
> 
> # cat /usr/lib64/lfc-mysql/NSCONFIG.templ 
> <username>/<password>@<host>
> [root@rawhide x86_64]# cat /usr/share/lfc/NSCONFIG.templ
> <username>/<password>@<host>

The duplication is due to the alternatives handling. The installed file is /usr/lib64/lfc-mysql/NSCONFIG.templ, and the symlink created by alternatives is /usr/share/lfc/NSCONFIG.templ.

The instructions for creating the /etc/NSCONFIG file is now in the README.Fedora file (see below).

> 3) The INSTALL-server-mysql is rather misleading to this RPM installation.

Removed - replaced with a README.Fedora (see below).

> 4) A quick read of the init.d script has 
>    /etc/grid-security/$LFCUSER/lfccert.pem
>    so that directory should probably exist.

Directory added.

> 5) The same LICENSE file looks to be duplicated in both lfc and lfc-mysql

Yes, this is again due to making the package content not depend on arbitrary choices about what parts to build in which source RPM. Since the mysql-postgres package should have the license file since it is built from a separate rpm it doesn't make sense for lfc-mysql not to have it since the choice about which flavour of the server to build in the main package is arbitrary.

> 6) I'm guessing a schema or at least a database has to be created?
>    Maybe a README.Fedora?  

README.Fedora added.

Comment 5 Steve Traylen 2009-12-09 21:25:16 UTC
Concerning the 1 or 4 my feeling is that your method you describe of
4 * (unpacks, patch, .... build, installs) is probably better
in the long run.

With the exception of the configure stage it is a series of loops(?).
More of a pain now but better for future when you are updating the 
package.

>Since the choice of building liblcgdm together with the LFC or the DPM is
>arbitrary, the Requires should not depend on this choice, and since having
>%{version}-%{release} Requires across source RPMs is a bad idea ...

It's a bad idea normally but in this case its the same .tgz and so all
the binary packages are essentially sub-packages to the binary end user. Certainly the two .src.rpms should/would be released together if they contain the same upstream update anyway. Obviously doing the loop avoids the
situation.

Also the lib you are building against is not the same instance as the
one that this is then ran against. Its a private lib in the build.

I was looking for precedents of two packages starting life with the same source.
There are 66 tar.gz, .tgz or .bz2s in more than one rawhide package so they
do exist but inspecting the list only these mostly probably for other
reasons, e.g including private libs for some reason, but there are some
that look similar to this one. e.g.
//Python-2.6.4.tar.bz2 in python-0:2.6.4-3.fc13.src
and
//Python-2.6.4.tar.bz2 in python-docs-0:2.6.4-2.fc13.src


There are certainly precedents for the multi build option, e.g one of 
mine ndoutils.

Writing this really convinces me one package is the way to go.

Lastly on a separate note rather than say
/etc/init.d/lfc-mysql 
should/could it be 
/etc/init.d/lfc 

and an ghost and alternative to lfc-mysql , -postgres instances. Would
be consistent with the other files managed under alternatives.
Is it possible to make the init.d script db independent and avoid the
situation completely?

Comment 6 Steve Traylen 2009-12-09 23:16:35 UTC
Created attachment 377341 [details]
Multiple sources in .src.rpms

For academic purposes the list of duplicate source files in .src.rpms.

Comment 7 Mattias Ellert 2009-12-10 08:26:53 UTC
(In reply to comment #5)
> Also the lib you are building against is not the same instance as the
> one that this is then ran against. Its a private lib in the build.

No, I do not build libraries multiple times. E.g. liblcgdm is only built by the lfc SRPM, the other three has the lcgdm-devel as a build dependency.

> Lastly on a separate note rather than say
> /etc/init.d/lfc-mysql 
> should/could it be 
> /etc/init.d/lfc 
> 
> and an ghost and alternative to lfc-mysql , -postgres instances. Would
> be consistent with the other files managed under alternatives.
> Is it possible to make the init.d script db independent and avoid the
> situation completely?  

No, the alternatives in Fedora has a --initscript option for this purpose. These initscripts should however not themselves be handled by alternatives, and must have different names for different altenatives. The alternatives system makes sure that only one of the alternative's initscript is active at the same time.

Comment 8 Mattias Ellert 2009-12-10 14:04:13 UTC
(In reply to comment #5)
> Concerning the 1 or 4 my feeling is that your method you describe of
> 4 * (unpacks, patch, .... build, installs) is probably better
> in the long run.
> 
> With the exception of the configure stage it is a series of loops(?).
> More of a pain now but better for future when you are updating the 
> package.

OK, here is an attempt to build everything in the same SRPM:

Spec URL: http://www.grid.tsl.uu.se/review/lcgdm.spec
SRPM URL: http://www.grid.tsl.uu.se/review/lcgdm-1.7.3.1-5.fc12.src.rpm

It is quite a long specfile, and it creates 28 binary packages. It is not as messy as I feared. One advantage of this approach would be that there is only need for one review and not four.

Comment 9 Steve Traylen 2009-12-18 03:52:40 UTC
Won't be able to look at this for nearly a month to un-assigning.
Steve

Comment 10 Mattias Ellert 2010-01-08 13:30:14 UTC
Updated to new upstream version:

Spec URL: http://www.grid.tsl.uu.se/review/lcgdm.spec
SRPM URL: http://www.grid.tsl.uu.se/review/lcgdm-1.7.4.1-1.fc12.src.rpm

Comment 11 Steve Traylen 2010-02-06 14:23:41 UTC
Looking at this now again.

Having some problems using the lfc commands: e.g.

$ lfc-ls prod-lfc-shared-central.cern.ch:/grid/dteam
send2nsd: NS002 - send error : client_establish_context: The server had a problem while authenticating our connection
prod-lfc-shared-central.cern.ch:/grid/dteam: Could not secure the connection

There are some env variables to add debugging output to this but 
I forget what they are.

I've a correct proxy and also the openssl 1.0 version of the CAs installed.

will continue to look at things anyway.

Comment 12 Steve Traylen 2010-02-06 14:39:15 UTC
Given

diff /etc/lfc-postgres/lfcdaemon.logrotate /etc/lfc-mysql/lfcdaemon.logrotate

shows they are the same having an alternative between them seems
a bit pointless but then of course I realise there is the problem
of where you put it. Perhaps a -common package or something.

Also it would remove the, all be it false positive, rpmlint ERROR.

lfc-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon

Steve

Comment 13 Steve Traylen 2010-02-06 14:50:08 UTC
In the README change:

 mysql> grant all on cns_db.* to <user>@localhost identified by <password>;

to
 mysql> grant all on cns_db.* to <user>@localhost identified by '<password>';

Comment 14 Steve Traylen 2010-02-06 14:54:15 UTC
Related to comment #12 I think the /etc/NSCONFIG should really be present
and owned especially given it is in /etc/

It could go in lfc-common package.

Comment 15 Steve Traylen 2010-02-07 11:24:35 UTC
Hi Mattias,

1) Can you submit a bug for 
# rpmlint dpm
dpm.x86_64: W: shared-lib-calls-exit /usr/lib64/libdpm.so.1.7.4 exit@GLIBC_2.2.5
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

2) Request only: Given there are two different versions of rf* commands out
   there any chance these ones could become of managed by alternatives key of
   rfio so as to exist with.

     > rpm -ql castor-rfio-client
/usr/bin/rfcat
/usr/bin/rfchmod
/usr/bin/rfcp
/usr/bin/rfdir
/usr/bin/rfmkdir
/usr/bin/rfrename
/usr/bin/rfrm
/usr/bin/rfstat

and man pages. Obviously castor-rfio does not exist in Fedora but it might
one day. It certainly does here of course.

3) I realise this is an upstream thing but both lfc and dpm-nameserver use a 
   database called cns_db by default. If possible/easy could one be changed.

4) Finally same comments for dpm and lfc about the use of a -common package
   for each with configuration files to avoid things like.

   # rpm -qf /etc/DPMCONFIG 
   file /etc/DPMCONFIG is not owned by any package

Other than these I've run out of things to look for at the moment.
Steve

Comment 16 Mattias Ellert 2010-02-13 21:22:36 UTC
(In reply to comment #11)
> Looking at this now again.
> 
> Having some problems using the lfc commands: e.g.
> 
> $ lfc-ls prod-lfc-shared-central.cern.ch:/grid/dteam
> send2nsd: NS002 - send error : client_establish_context: The server had a
> problem while authenticating our connection
> prod-lfc-shared-central.cern.ch:/grid/dteam: Could not secure the connection
> 
> There are some env variables to add debugging output to this but 
> I forget what they are.
> 
> I've a correct proxy and also the openssl 1.0 version of the CAs installed.
> 
> will continue to look at things anyway.    

The authentication problem is a known issue. It is due to the current globus-gssapi-gsi package not working correctly with openssl 1.0.0.

These issues have been fixed in today's build of globus-gssapi-gsi in koji (globus-gssapi-gsi-7.0-2). So please use this version if you are on a Fedora release that uses openssl 1.0.0.

[ellert@ellert ~]$ rpm -q lfc-client
lfc-client-1.7.3.1-4.fc12.x86_64

[ellert@ellert ~]$ rpm -q globus-gssapi-gsi
globus-gssapi-gsi-7.0-2.fc12.x86_64

[ellert@ellert ~]$ lfc-ls lfc1.ndgf.org:/grid
atlas
ops.ndgf.org

The globus-gssapi-gsi-7.0-2 is part of the big update to Globus Toolkit 5. This transition has been completed for the existing Globus packages in F13, with the exception of globus-gridftp-server-control where the new version depends on the new globus-xio-pipe-driver package submitted for review.

For F11, F12 and EPEL the GT5 update has been imported to CVS and most of the packages have been built, but some of the builds involves requesting and waiting for buildroot overrides. The builds are almost done - the buildroot override I am currently waiting for is the second to last one. But of course the new dependency on globus-xio-pipe-driver applies here too, if the update should be really complete.

Comment 17 Mattias Ellert 2010-04-03 16:42:25 UTC
(In reply to comment #12)
> Given
> 
> diff /etc/lfc-postgres/lfcdaemon.logrotate /etc/lfc-mysql/lfcdaemon.logrotate
> 
> shows they are the same having an alternative between them seems
> a bit pointless but then of course I realise there is the problem
> of where you put it. Perhaps a -common package or something.

There are in total 7 logrotate files. If each of these should be put in a separate subpackage this would mean 7 new subpackages each containing a single file. I don't find this to be a good idea.

(In reply to comment #13)
> In the README change:
> 
>  mysql> grant all on cns_db.* to <user>@localhost identified by <password>;
> 
> to
>  mysql> grant all on cns_db.* to <user>@localhost identified by '<password>';    

Accepted.

(In reply to comment #14)
> Related to comment #12 I think the /etc/NSCONFIG should really be present
> and owned especially given it is in /etc/
> 
> It could go in lfc-common package.    

The /etc/NSCONFIG file contains the username and password of the lfc database that the sysadmin creates when the service is deployed. This file should not exist before the database has been created. Its presence is an indication that the sysadmin has initialized the necessary database tables. It can therefore not be installed or created at the time of package installation.

(In reply to comment #15)
> 1) Can you submit a bug for 
> # rpmlint dpm
> dpm.x86_64: W: shared-lib-calls-exit /usr/lib64/libdpm.so.1.7.4
> exit@GLIBC_2.2.5
> 1 packages and 0 specfiles checked; 0 errors, 1 warnings.

I sent an e-mail to the upstream developers about this issue and it has been fixed in the latest version.

> 2) Request only: Given there are two different versions of rf* commands out
>    there any chance these ones could become of managed by alternatives key of
>    rfio so as to exist with.
> 
>      > rpm -ql castor-rfio-client
> /usr/bin/rfcat
> /usr/bin/rfchmod
> /usr/bin/rfcp
> /usr/bin/rfdir
> /usr/bin/rfmkdir
> /usr/bin/rfrename
> /usr/bin/rfrm
> /usr/bin/rfstat
> 
> and man pages. Obviously castor-rfio does not exist in Fedora but it might
> one day. It certainly does here of course.

I sent the following question to the upstream developers:

"The dpm-clients bundles the set of rfio-clients. These are also present in another software package you provide (castor-rfio). This package is not in Debian or Fedora yet, so it is not a packaging conflict in the distributions at this time, but it is a potential one. Do you have any plans w.r.t. this so that you only provide one set of the rfio client tools. Looking at the sources the two versions seems to be different versions of the same software a bit out of sync with each other, not two different implementations that both should be packaged, but please enlighten me."

And got the following reply:

"There was 3 years ago a project to have a common RFIO between CASTOR and DPM. But not much has been done and the 2 RFIO codes have even more diverged. However in the medium term CASTOR wants to drop RFIO. So I'm not sure we should spend time on this, but the RFIO code cleanup I've done for DPM 1.7.4-2 would certainly help."

I suggest keeping the current structure of the package until we know more about whether upstream will merge the two implementations, or drop one of them, or not.

> 3) I realise this is an upstream thing but both lfc and dpm-nameserver use a 
>    database called cns_db by default. If possible/easy could one be changed.

Upstream's reply:

"cns_db is the default but as you can specify the DB name in the NSCONFIG and DPMCONFIG files, I do not see really a problem. We have also a plan to be able to use the DPM Name Server as local LFC (DPM 1.7.6)."

Given this reply, I suggest upstream's defaults are kept. It is tricky to run both an lfc and a dpm-nameserver on the same host anyway since they both by default listen to the same port (5010).

> 4) Finally same comments for dpm and lfc about the use of a -common package
>    for each with configuration files to avoid things like.
> 
>    # rpm -qf /etc/DPMCONFIG 
>    file /etc/DPMCONFIG is not owned by any package

The /etc/DPMCONFIG file contains the username and password of the dpm database that the sysadmin creates when the service is deployed. This file should not exist before the database has been created. Its presence is an indication that the sysadmin has initialized the necessary database tables. It can therefore not be installed or created at the time of package installation.

New version:

Spec URL: http://www.grid.tsl.uu.se/review/lcgdm.spec
SRPM URL: http://www.grid.tsl.uu.se/review/lcgdm-1.7.4.4-1.fc12.src.rpm

Comment 18 Mattias Ellert 2010-04-03 16:43:48 UTC
*** Bug 531254 has been marked as a duplicate of this bug. ***

Comment 19 Mattias Ellert 2010-04-03 16:43:53 UTC
*** Bug 531256 has been marked as a duplicate of this bug. ***

Comment 20 Mattias Ellert 2010-04-03 16:43:58 UTC
*** Bug 531258 has been marked as a duplicate of this bug. ***

Comment 21 Steve Traylen 2010-04-06 22:47:49 UTC
Review:     lcgdm
Date:       6th April
Mock Build: F14 http://koji.fedoraproject.org/koji/taskinfo?taskID=2098329

* PASS: rpmlint output 
30 packages and 1 specfiles checked; 14 errors, 71 warnings.

I've sorted, grouped and removed duplicates here to make
it easier to read.

invalid-url Source0: lcgdm-1.7.4.4.tar.gz
 -> expected since built from cvs.

dpm.x86_64: W: spelling-error %description -l en_US runtime -> run time, run-time, runtier
dpm-mysql.x86_64: W: spelling-error Summary(en_US) backend -> back end, back-end, backed
  -> correct runtime and backend if you like but they are clearly in
     common usage in  this context. If you do it's obviously for all
     the descriptions but odmitted here.

dpm-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpm
dpm-mysql-copyd.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpmcopyd
dpm-mysql-srmv1.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpm-srmv1
dpm-mysql-srmv2.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpm-srmv2
dpm-mysql-srmv22.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpm-srmv2.2
dpm-postgres-nameserver.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/dpnsdaemon
lfc-mysql.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon
lfc-postgres.x86_64: E: incoherent-logrotate-file /etc/logrotate.d/lfcdaemon
  -> These are symlinks to real ones managed via "alternatives".

dpm-mysql.x86_64: W: non-standard-uid /var/log/dpm dpmmgr
dpm-mysql-copyd.x86_64: W: non-standard-uid /var/log/dpmcopy dpmmgr
dpm-mysql-nameserver.x86_64: W: non-standard-uid /var/log/dpns dpmmgr
dpm-mysql-srmv1.x86_64: W: non-standard-uid /var/log/dpm-srmv1 dpmmgr
dpm-mysql-srmv2.x86_64: W: non-standard-uid /var/log/dpm-srmv2 dpmmgr
dpm-mysql-srmv22.x86_64: W: non-standard-uid /var/log/dpm-srmv2.2 dpmmgr
lfc-dli.x86_64: W: non-standard-uid /var/log/lfc-dli lfcmgr
lfc-mysql.x86_64: W: non-standard-uid /var/lib/lfc lfcmgr
  -> All expected since these users write the log files writes the log files.


dpm-postgres-nameserver.x86_64: W: non-standard-uid /var/log/dpns dpmmgr
dpm-postgres-nameserver.x86_64: W: non-standard-gid /var/log/dpns dpmmgr


* PASS: Named according to the Package Naming Guidelines.
Same as SVN module.
* PASS: spec file name same as  base package %{name}.
Yes.
* PASS: Packaging Guidelines.
Its clearly a hugh package but yes.
There are 
* PASS: Approved license in .spec file.
ASL 2.0
* NOTE: License on Source code.
Clear LICENSE file, most code is with out its own license header but

lcgdm-1.7.4.4/test/python/lfc/*.py looks 
to be GPL but as far as I can see this is not used
nor end ups in the binary RPMS. i.e it is fine.

socket/goputils/gop_synfo.c contains some GPL declarations
but again it does not looked to be used in anyway.


* PASS: Include LICENSE file or similar if it exist.
Included
* PASS: Written in American English.
Only if you want to change runtime and backend.
* COMMENT: Spec file legible. 
Some of the seds especially could do with a few more comments.
* PASS: Included source must match upstream source.
After checking out and removing the .svn directories.
$ diff -r --brief lcgdm-1.7.4.4 ../SPECS/lcgdm-1.7.4.4
produces nothing.

* PASS: Build on one architecture.
koji build
* PASS: Not building on an architecture must highlighted.
koji build
* PASS: Build dependencies must be listed in BuildRequires.
koji build
* PASS: Handle locales properly. 
no locales
* PASS: ldconfig must be called on shared libs.
* PASS: No bundled copies of system libraries.
* PASS: Package must state why relocatable if relocatable.
Not relocatable.
* PASS: A package must own all directories that it creates
* PASS:  No duplicate files in %files listings. 
None
* PASS:  Permissions on files must be set properly. %defattr
%defattr is there.
* PASS:  %clean section contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
* PASS:  Each package must consistently use macros.
* PASS:  The package must contain code, or permissable content.
* PASS:  Large documentation files must go in a -doc subpackage.  
No large docs.
* PASS:  %doc  must not affect the runtime of the application. 
* PASS:  Header files must be in a -devel package.
Yes.
* PASS:  Static libraries must be in a -static package.
No statics.
* PASS:  Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'
No pkgconfig
* PASS:  devel packages must require the exact base package
They do
* PASS:  No .la libtool archives
None present
* PASS:  GUI apps should have %{name}.desktop file
No gui
* PASS:  No files or directories already owned by other packages. 
None
* PASS:  %install must run rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
It does
* PASS:  All filenames in rpm packages must be valid UTF-8.

Summary:

1. There are quite a few "install"s that could benefit from a "-p".
2. There are a few pretty complicated seds in there that have little or
   no comments with them. Might make it easier for someone else
   (me) to understand what is going on if more comment could be added.
3. You may want to take out the words backend and runtime which
   are apparently not words.

Comment 22 Steve Traylen 2010-04-06 23:18:35 UTC
Above can all be done post review.

A really good package. 

APPROVED.

Comment 23 Mattias Ellert 2010-04-07 07:17:28 UTC
Thank you for the review - it took some time, but I think the end result is very good.

New Package CVS Request
=======================
Package Name: lcgdm
Short Description: LHC Computing Grid Data Management
Owners: ellert
Branches: F-11 F-12 F-13 EL-4 EL-5
InitialCC:

Comment 24 Steve Traylen 2010-04-07 08:59:49 UTC
Hi had one more comment I meant to mention yesterday.

The postgres and mysql flavors are both priority 20.
Is that on purpose, I admit I don't know what alternatives chooses
in this case?

The mysql version is certainly better maintained.

Steve.

Comment 25 Mattias Ellert 2010-04-07 18:25:59 UTC
(In reply to comment #24)
> The postgres and mysql flavors are both priority 20.
> Is that on purpose, I admit I don't know what alternatives chooses
> in this case?

The postgres version was supposed to have lower priority (10) - it was correct for the LFC, but not for the DPM services. I bit too much cut and paste I guess. Thank you for pointing this out - I will fix it.

Comment 26 Kevin Fenzi 2010-04-08 02:22:36 UTC
CVS done (by process-cvs-requests.py).

Comment 27 Fedora Update System 2010-04-08 11:01:53 UTC
lcgdm-1.7.4.4-2.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.el5

Comment 28 Fedora Update System 2010-04-08 11:02:02 UTC
lcgdm-1.7.4.4-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc13

Comment 29 Fedora Update System 2010-04-08 11:02:07 UTC
lcgdm-1.7.4.4-2.el4 has been submitted as an update for Fedora EPEL 4.
http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.el4

Comment 30 Fedora Update System 2010-04-08 11:02:14 UTC
lcgdm-1.7.4.4-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc11

Comment 31 Fedora Update System 2010-04-08 11:02:19 UTC
lcgdm-1.7.4.4-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc12

Comment 32 Fedora Update System 2010-04-08 19:12:46 UTC
lcgdm-1.7.4.4-2.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update lcgdm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.el5

Comment 33 Fedora Update System 2010-04-08 19:13:37 UTC
lcgdm-1.7.4.4-2.el4 has been pushed to the Fedora EPEL 4 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update lcgdm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.el4

Comment 34 Fedora Update System 2010-04-09 04:12:03 UTC
lcgdm-1.7.4.4-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update lcgdm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc13

Comment 35 Fedora Update System 2010-04-10 10:20:07 UTC
lcgdm-1.7.4.4-2.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update lcgdm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc12

Comment 36 Fedora Update System 2010-04-10 10:33:40 UTC
lcgdm-1.7.4.4-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update lcgdm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lcgdm-1.7.4.4-2.fc11

Comment 37 Fedora Update System 2010-04-22 22:47:12 UTC
lcgdm-1.7.4.4-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 38 Fedora Update System 2010-04-22 22:53:06 UTC
lcgdm-1.7.4.4-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 39 Fedora Update System 2010-04-22 22:55:24 UTC
lcgdm-1.7.4.4-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 40 Fedora Update System 2010-04-26 23:23:12 UTC
lcgdm-1.7.4.4-2.el4 has been pushed to the Fedora EPEL 4 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 41 Fedora Update System 2010-04-26 23:26:56 UTC
lcgdm-1.7.4.4-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.


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