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=531252 Mattias Ellert <mattias.ellert@xxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #17 from Mattias Ellert <mattias.ellert@xxxxxxxxxxxx> 2010-04-03 12:42:25 EDT --- (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@xxxxxxxxxxx > 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 -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review