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@xxxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review