[Bug 513896] Review Request: pcp - performance monitoring and collection 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=513896





--- Comment #15 from Jarod Wilson <jwilson at redhat.com>  2009-08-20 09:42:56 EDT ---
(In reply to comment #14)
> Eric Sandeen wrote:
> > * MUST: The package must meet the Packaging Guidelines. 
> > NEEDSWORK? - 4 errors still above.  subsys-not-used should be easy to fix up, 
> 
> I looked at this and I'd rather not change it.
> 
> It turned out not to be that easy to fix. The three PCP services
> (pcp, pmie and pmproxy) all manage their own var/run/pcp/pid files.
> This pre-dates the standard functionality for managing pid files and
> is also multi-platform and also rock solid stable.

I think we can live with that.

> > * MUST: The License field in the package spec file must match the actual 
> > license.
> > 
> > NEEDSWORK?
> > From COPYING:
> > All the libraries in the Performance Co-Pilot (PCP) open source
> > release are licensed under Version 2.1 of the GNU Lesser General
> > Public License.
> > 
> > All other components in the PCP open source release are licensed
> > under Version 2 of the GNU General Public License.
> > 
> > but the specfile says:
> > License: GPL+ and LGPLv2+
> 
> The previous version tried to specify the license for the base package
> and the two subpackages, which is wrong because -libs has a different
> license. So I've now split this so each package specifies it's own license.
> Changed the spec so the base package and -devel specify "GPLv2+"
> (assuming "GPLv2+" is the best match for "GPLv2.1", as specified in COPYING
> since there is no explicit option for "GPLv2.1"), and -libs is "LGPLv2"
> (exactly matching what's in COPYING).

"GPLv2+" is only for "GPLv2.anything or later", if it doesn't say "or later",
then simply "GPLv2" is the tag you want.

> > * MUST: Devel packages must require the base package using a fully
> > versioned dependency: Requires: %{name} = %{version}-%{release}
> > 
> > NEEDSWORK: Requires: pcp-libs = %{version}
> > 
> > For whatever reason I guess we must require pcp, not pcp-libs.
> 
> Nathan and I discussed this and we concluded the only True Dependencies are:
> pcp-devel requires pcp-libs
> pcp requires pcp-libs
> 
> Neither pcp-devel nor pcp-libs actually requires pcp. There is a good
> reason we don't want pcp-devel to require pcp - basically it has to do with
> the pcp daemon on the build machine getting killed when pcp in the chroot
> gets uninstalled, i.e. we want to be able to build packages (such as pcp-gui)
> that BuildRequires pcp-devel *without* pcp installed (just pcp-devel and
> pcp-libs should be installed).

I think it might be cleanest/most obvious to users if the -devel package were
renamed to pcp-libs-devel, since its really the devel headers for the
libraries. Then we're even reasonably satisfying the guidelines, I'd argue.

> > * SHOULD: Subpackages other than devel should require the base package
> > using a fully versioned dependency.  NO, but it seems ok
> 
> Comment: if -libs and the base package require each other, then what's the
> point
> of splitting out -libs since they can never be installed separately?

Welcome to multiarch. :) Splitting the libs out allows you to have pcp.x86_64,
pcp-libs.x86_64 and pcp-libs.i686 all installed at the same time without any
file conflicts (in theory).

> So based on the above, I'm leaving the run-time and build-time dependencies
> as they strictly need to be. If the final Fedora reviewer and/or sponsor insist
> on additional dependencies, then I'll conform, reluctantly :)

I don't think its necessary on this one, there's a reasonable reason not to.


I presume this is the srpm I should be looking at now?

ftp://oss.sgi.com/projects/pcp/download/v3/pcp-3.0.0-3.fc10.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.