The package suffers from various packaging mistakes and would benefit from a re-review: [...] # rpm -q pcp-libs-devel pcp-libs-devel-3.10.3-1.fc21.x86_64 # rpmls pcp-libs-devel|grep ^d drwxr-xr-x /usr/share/pcp/demos/mmv drwxr-xr-x /usr/share/pcp/demos/pmclient drwxr-xr-x /usr/share/pcp/demos/procmemstat drwxr-xr-x /usr/share/pcp/demos/trace drwxr-xr-x /usr/share/pcp/examples drwxr-xr-x /usr/share/pcp/examples/pmie drwxr-xr-x /var/lib/pcp/pmdas/sample drwxr-xr-x /var/lib/pcp/pmdas/simple drwxr-xr-x /var/lib/pcp/pmdas/trivial drwxr-xr-x /var/lib/pcp/pmdas/txmon # rpm -qf /usr/share/pcp /var/lib/pcp /var/lib/pcp/pmdas file /usr/share/pcp is not owned by any package file /var/lib/pcp is not owned by any package file /var/lib/pcp/pmdas is not owned by any package https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership https://fedoraproject.org/wiki/Packaging:UnownedDirectories A dependency on the base "pcp" package is missing, because that one is the provider of those directories. [...] # rpmls pcp-libs-devel|grep \.so lrwxrwxrwx /usr/lib64/libpcp.so lrwxrwxrwx /usr/lib64/libpcp.so.2 lrwxrwxrwx /usr/lib64/libpcp_gui.so lrwxrwxrwx /usr/lib64/libpcp_gui.so.1 lrwxrwxrwx /usr/lib64/libpcp_import.so lrwxrwxrwx /usr/lib64/libpcp_mmv.so lrwxrwxrwx /usr/lib64/libpcp_pmda.so lrwxrwxrwx /usr/lib64/libpcp_pmda.so.2 lrwxrwxrwx /usr/lib64/libpcp_trace.so The versioned libs very likely are runtime libs, compatibility links. In the spec file, I couldn't find any comment on them and why there are stored in the buildtime -devel package instead of the pcp-libs runtime package. [...] > Version: 3.10.3 > Release: 0.804.g2e0fe59%{?dist} The guidelines for snapshot packages have always been different: https://fedoraproject.org/wiki/Packaging:Guidelines#Version_and_Release https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages > Source0: %{name}-%{version}-0.804.g2e0fe59.tar.gz https://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control > %define https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define > %package conf > Group: Development/Libraries ?? That is the group tag for buildtime packages. > %package libs > Group: Development/Libraries The group tag for runtime base library packages has been "System Environment/Libraries" for many years, dating back to very old Red Hat Linux releases even. Nowadays, the group tag is optional: https://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag > %package libs-devel > Requires: pcp-libs = %{version}-%{release} https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package Same for the other subpackages. > %{_mandir}/man1/pmmgr.1.gz Typically, one includes manual pages with a trailing wildcard, so the package would still build with modified/disabled compression of manual pages: %{_mandir}/man1/pmmgr.1* > %defattr(-,root,root,-) Obsolete for several years. https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
Ah, thanks Michael! I'll work through those for the next update. Lukas, could you look into the rawhide snapshot naming issues Michael mentioned? - presumably the same changes will be needed in systemtap, from whence that came.
It turns out that the snapshot-naming issues are false positives: we're exactly following the "pre-release packages" convention for these.
Are you kidding? The package has been at 3.10.3-2 before. Both in %changelog as well as in koji. Now it returned to 3.10.3-0.something, which is _lower_ than the earlier release: 2 is higher than 0. That's another mistake. And it is a snapshot, but if it has been at 3.10.3 before, the later snapshots are a post-release. > Release: 0.804.g2e0fe59%{?dist} Look at the "kismet pre-release svn checkout" example: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Examples You're missing the %{checkout} value as explained here: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
Lots of upgrade path issues because of those versioning problems: http://koji.fedoraproject.org/koji/packageinfo?packageID=10542 Example: $ rpmdev-vercmp 3.10.3-1.fc22 3.10.3-0.804.g2e0fe59.fc23 3.10.3-1.fc22 > 3.10.3-0.804.g2e0fe59.fc23
> presumably the same changes will be needed in systemtap, from whence that came. Confirmed.
> The package has been at 3.10.3-2 before. Both in %changelog as well as in > koji. Now it returned to 3.10.3-0.something That's a separate matter - it should be named 3.10.4-something now. The other question is whether it's better to model it as a ¶1.5.2.1.2 pre-release vs. ¶1.5.2.1.1 snapshot.
> The other question is whether it's better to model it as a ¶1.5.2.1.2 > pre-release vs. ¶1.5.2.1.1 snapshot. There is no difference as long as you check out the source code from an SCM system. Let me quote from the guidelines: | If the snapshot package is considered a "pre-release package", follow the | guidelines listed in Pre-Release Packages for snapshot packages, using the | %{checkout} that you decide on above. (For instance, | in kismet-0-0.3.20040204svn, 20040204svn is the %{checkout}) That is, currently it does _not_ follow the pre-release versioning guidelines for snapshots. | If the snapshot is a "post-release package", follow the guidelines in the | Post-Release Packages section. Where the %{posttag} in that section is the | %{checkout} string you decided on above. Same here.
(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #7) > > The other question is whether it's better to model it as a ¶1.5.2.1.2 > > pre-release vs. ¶1.5.2.1.1 snapshot. > > There is no difference as long as you check out the source code from an SCM > system. > > Let me quote from the guidelines: > > | If the snapshot package is considered a "pre-release package", follow the > | guidelines listed in Pre-Release Packages for snapshot packages, using the > | %{checkout} that you decide on above. (For instance, > | in kismet-0-0.3.20040204svn, 20040204svn is the %{checkout}) > > That is, currently it does _not_ follow the pre-release versioning > guidelines for snapshots. > > | If the snapshot is a "post-release package", follow the guidelines in the > | Post-Release Packages section. Where the %{posttag} in that section is the > | %{checkout} string you decided on above. > > Same here. As of the current rawhide spin, this particular naming issue has been fixed. Please see: http://koji.fedoraproject.org/koji/buildinfo?buildID=622679 I will tweak the systemtap spins as well next week to observe proper YYYYMMDDgit{describe} naming.
pcp-3.10.4-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/pcp-3.10.4-1.fc22
pcp-3.10.4-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/pcp-3.10.4-1.fc21
pcp-3.10.4-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/pcp-3.10.4-1.fc20
pcp-3.10.4-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/pcp-3.10.4-1.el5
Package pcp-3.10.4-1.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing pcp-3.10.4-1.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5870/pcp-3.10.4-1.el5 then log in and leave karma (feedback).
pcp-3.10.4-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.10.4-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.10.4-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.10.4-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.