[Bug 1510565] New: Review Request: ntpstat - Utility to print NTP synchronization status
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
Bug ID: 1510565 Summary: Review Request: ntpstat - Utility to print NTP synchronization status Product: Fedora Version: rawhide Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: mlichvar@redhat.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org
Spec URL: https://mlichvar.fedorapeople.org/tmp/ntpstat.spec SRPM URL: https://mlichvar.fedorapeople.org/tmp/ntpstat-0.4-1.fc28.src.rpm Description: ntpstat is a script which prints a brief summary of the system clock's synchronisation status when the ntpd or chronyd daemon is running. Fedora Account System Username: mlichvar
This is a split from the ntp package. The ntpstat utility was included in the ntp package for a very long time, but it never was in the upstream ntp code. It was recently rewritten as a shell script, which supports both ntp and chrony, so it now makes even less sense to keep it in the ntp package.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
Iwicki Artur fedora@svgames.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora@svgames.pl
--- Comment #1 from Iwicki Artur fedora@svgames.pl ---
Group: Applications/System
The "Group:" tag shouldn't be used. https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
%files %doc COPYING NEWS README
COPYING should probably be marked as %license instead of %doc.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
--- Comment #2 from Miroslav Lichvar mlichvar@redhat.com --- Thanks, I'll fix that in the next release. Would you like to do a full review?
In order to not lose ntpstat after an upgrade, I was planning to add Recommends or Requires to the ntp package, but I'm wondering if there is not a better way. If ntpstat obsoleted the old ntp package and required "(ntp or chrony)", I suspect an upgrade could result in an installed ntp being replaced by chrony as the new requirement would be satisfied without ntp.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
Pavel Zhukov pzhukov@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |pzhukov@redhat.com Assignee|nobody@fedoraproject.org |pzhukov@redhat.com Flags| |fedora-review?
--- Comment #3 from Pavel Zhukov pzhukov@redhat.com --- I'll review it.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
--- Comment #4 from Pavel Zhukov pzhukov@redhat.com --- (In reply to Miroslav Lichvar from comment #2)
Thanks, I'll fix that in the next release. Would you like to do a full review?
In order to not lose ntpstat after an upgrade, I was planning to add Recommends or Requires to the ntp package, but I'm wondering if there is not a better way. If ntpstat obsoleted the old ntp package and required "(ntp or chrony)", I suspect an upgrade could result in an installed ntp being replaced by chrony as the new requirement would be satisfied without ntp.
What about: https://fedoraproject.org/wiki/Packaging:WeakDependencies#Real_life_example ?
Both chrony and ntp should provide some "service" and ntpstat should depend on this "service" and suggest chrony as preferred provider.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
--- Comment #5 from Miroslav Lichvar mlichvar@redhat.com --- (In reply to Pavel Zhukov from comment #4)
What about: https://fedoraproject.org/wiki/Packaging:WeakDependencies#Real_life_example ?
Both chrony and ntp should provide some "service" and ntpstat should depend on this "service" and suggest chrony as preferred provider.
What if a third package was added to fedora, which provided this service? ntpstat can get the data from ntpd (using ntpq) and chronyd (using chronyc), but that's all.
If old ntp is installed, I think an upgrade should result in both new ntp and ntpstat installed. If chrony is not installed, the upgrade should not install chrony. If neither chrony or ntp is installed, it would be nice if installing ntpstat installed chrony as it is currently preferred over ntp, but it probably does not really matter.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
--- Comment #6 from Pavel Zhukov pzhukov@redhat.com --- (In reply to Miroslav Lichvar from comment #5)
(In reply to Pavel Zhukov from comment #4)
What about: https://fedoraproject.org/wiki/Packaging:WeakDependencies#Real_life_example ?
Both chrony and ntp should provide some "service" and ntpstat should depend on this "service" and suggest chrony as preferred provider.
What if a third package was added to fedora, which provided this service? ntpstat can get the data from ntpd (using ntpq) and chronyd (using chronyc), but that's all.
Well it's theoretical question which applies for mysql example as well. There're few options: 1) Add support of the service to ntpstat 2) Add "Conflicts:" to either the service or ntpstat spec. In any case As far as ntpstat suggests chrony It's safe. In other words user has to explicitly install ntpstat and "the service".
Well It may happen that ntp/chrony will change the API :) and will not be longer compatible with ntpstat etc.
If old ntp is installed, I think an upgrade should result in both new ntp and ntpstat installed.
Something like Enhances: ntpstat in ntp.spec?
If chrony is not installed, the upgrade should not install chrony.
Should be ok.
If neither chrony or ntp is installed, it would be nice if installing ntpstat installed chrony as it is currently preferred over ntp, but it probably does not really matter.
Suggests: solves this
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
--- Comment #7 from Miroslav Lichvar mlichvar@redhat.com --- (In reply to Pavel Zhukov from comment #6)
(In reply to Miroslav Lichvar from comment #5)
What if a third package was added to fedora, which provided this service? ntpstat can get the data from ntpd (using ntpq) and chronyd (using chronyc), but that's all.
Well it's theoretical question which applies for mysql example as well. There're few options:
- Add support of the service to ntpstat
- Add "Conflicts:" to either the service or ntpstat spec.
In any case As far as ntpstat suggests chrony It's safe. In other words user has to explicitly install ntpstat and "the service".
Wouldn't it better to just explicitly list the supported services in the ntpstat spec using a rich dependency, e.g. "Requires: (ntp or chrony)" ?
If old ntp is installed, I think an upgrade should result in both new ntp and ntpstat installed.
Something like Enhances: ntpstat in ntp.spec?
That does not seem to work. I created a testing repo with ntp which "enhances" ntpstat and also contains the new ntpstat package, but dnf seems to ignore it:
# dnf update --disablerepo=* --enablerepo=local ... Upgrading: ntp x86_64 4.2.8p10-4.nontpstat.fc28 local 670 k ntpdate x86_64 4.2.8p10-4.nontpstat.fc28 local 85 k
I tried adding "Obsoletes: ntp < 4.2.8p10-4" to ntpstat.spec, expecting ntp would be dropped without replacement as chrony is installed, but the result was the same as before.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
--- Comment #8 from Pavel Zhukov pzhukov@redhat.com --- (In reply to Miroslav Lichvar from comment #7)
(In reply to Pavel Zhukov from comment #6)
(In reply to Miroslav Lichvar from comment #5)
What if a third package was added to fedora, which provided this service? ntpstat can get the data from ntpd (using ntpq) and chronyd (using chronyc), but that's all.
Well it's theoretical question which applies for mysql example as well. There're few options:
- Add support of the service to ntpstat
- Add "Conflicts:" to either the service or ntpstat spec.
In any case As far as ntpstat suggests chrony It's safe. In other words user has to explicitly install ntpstat and "the service".
Wouldn't it better to just explicitly list the supported services in the ntpstat spec using a rich dependency, e.g. "Requires: (ntp or chrony)" ?
looks good for me. It's maintainer decision at the end :) Are you going to update spec or it'll be done after formal review?
If old ntp is installed, I think an upgrade should result in both new ntp and ntpstat installed.
Something like Enhances: ntpstat in ntp.spec?
That does not seem to work. I created a testing repo with ntp which "enhances" ntpstat and also contains the new ntpstat package, but dnf seems to ignore it:
# dnf update --disablerepo=* --enablerepo=local ... Upgrading: ntp x86_64 4.2.8p10-4.nontpstat.fc28 local 670 k ntpdate x86_64 4.2.8p10-4.nontpstat.fc28 local 85 k
I tried adding "Obsoletes: ntp < 4.2.8p10-4" to ntpstat.spec, expecting ntp would be dropped without replacement as chrony is installed, but the result was the same as before.
weird. maybe bug in libsolv? Anyway I'll post formal review soon...
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
--- Comment #9 from Miroslav Lichvar mlichvar@redhat.com --- (In reply to Pavel Zhukov from comment #8)
(In reply to Miroslav Lichvar from comment #7)
Wouldn't it better to just explicitly list the supported services in the ntpstat spec using a rich dependency, e.g. "Requires: (ntp or chrony)" ?
looks good for me. It's maintainer decision at the end :) Are you going to update spec or it'll be done after formal review?
I've updated the spec and srpm: https://mlichvar.fedorapeople.org/tmp/ntpstat.spec https://mlichvar.fedorapeople.org/tmp/ntpstat-0.4-2.fc28.src.rpm
I tried adding "Obsoletes: ntp < 4.2.8p10-4" to ntpstat.spec, expecting ntp would be dropped without replacement as chrony is installed, but the result was the same as before.
weird. maybe bug in libsolv?
I'm not sure. Maybe the obsoletes should be considered only if ntpstat is already installed? I guess the other option is to simply add "Requires: ntpstat" to ntp.
Anyway I'll post formal review soon...
Thanks.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
Pavel Zhukov pzhukov@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mlichvar@redhat.com Flags| |needinfo?(mlichvar@redhat.c | |om)
--- Comment #10 from Pavel Zhukov pzhukov@redhat.com --- Revuew is below. Few remarks: 1) You are using %makeinstall macros while Makefile is pretty simple and either make install prefix=%{DESTDIR}/%{prefix} can be used or Makefile patched to accept DESTDIR (upstream first). https://fedoraproject.org/wiki/Packaging:Guidelines#Why_the_.25makeinstall_m... 2) Description should start with capitalized letter as normal English sentense
Package Review ==============
Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed
===== MUST items =====
Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "MIT/X11 (BSD like)", "Unknown or generated". 4 files have unknown license. Detailed output of licensecheck in /home/pavel/work/bugs/bz1510565/ntpstat/licensecheck.txt [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [!]: Package use %makeinstall only when make install DESTDIR=... doesn't work. Note: %makeinstall used in %install section [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [x]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [!]: Spec file is legible and written in American English. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local
===== SHOULD items =====
Generic: [x]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [ ]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified.
===== EXTRA items =====
Generic: [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment).
Rpmlint ------- Checking: ntpstat-0.4-2.fc26.noarch.rpm ntpstat-0.4-2.fc26.src.rpm ntpstat.noarch: W: spelling-error %description -l en_US synchronisation -> synchronization, synchronicity ntpstat.noarch: W: spelling-error %description -l en_US ntpd -> DuPont ntpstat.noarch: W: spelling-error %description -l en_US chronyd -> chronic ntpstat.src: W: spelling-error %description -l en_US synchronisation -> synchronization, synchronicity ntpstat.src: W: spelling-error %description -l en_US ntpd -> DuPont ntpstat.src: W: spelling-error %description -l en_US chronyd -> chronic 2 packages and 0 specfiles checked; 0 errors, 6 warnings.
Rpmlint (installed packages) ---------------------------- ntpstat.noarch: W: spelling-error %description -l en_US synchronisation -> synchronization, synchronicity ntpstat.noarch: W: spelling-error %description -l en_US ntpd -> DuPont ntpstat.noarch: W: spelling-error %description -l en_US chronyd -> chronic ntpstat.noarch: W: invalid-url URL: https://github.com/mlichvar/ntpstat <urlopen error [Errno -2] Name or service not known> 1 packages and 0 specfiles checked; 0 errors, 4 warnings.
Requires -------- ntpstat (rpmlib, GLIBC filtered): (ntp or chrony) /bin/bash
Provides -------- ntpstat: ntpstat
Source checksums ---------------- https://github.com/mlichvar/ntpstat/archive/0.4/ntpstat-0.4.tar.gz : CHECKSUM(SHA256) this package : 1ededcbf55599c4388ff181c18a2b60ca214793059d77f9aadd26d6bc33284f8 CHECKSUM(SHA256) upstream package : 1ededcbf55599c4388ff181c18a2b60ca214793059d77f9aadd26d6bc33284f8
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
Miroslav Lichvar mlichvar@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mlichvar@redhat.c | |om) |
--- Comment #11 from Miroslav Lichvar mlichvar@redhat.com --- Thanks for the review.
The Makefile doesn't support DESTDIR and the upstream is not interested in adapting autoconf+automake only to install a single shell script :). If %install used "make install prefix=...", the bindir and mandir variables wouldn't be set to %{_bindir} and %{_mandir}. I think that's why the %makeinstall macro exists.
Does that make sense?
To avoid starting with a lowercase character I'll change the description to:
This package contains a script which prints a brief summary of the system clock's synchronisation status when the ntpd or chronyd daemon is running.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
Pavel Zhukov pzhukov@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-review? |fedora-review+
--- Comment #12 from Pavel Zhukov pzhukov@redhat.com --- (In reply to Miroslav Lichvar from comment #11)
Thanks for the review.
The Makefile doesn't support DESTDIR and the upstream is not interested in adapting autoconf+automake only to install a single shell script :). If %install used "make install prefix=...", the bindir and mandir variables wouldn't be set to %{_bindir} and %{_mandir}. I think that's why the %makeinstall macro exists.
Does that make sense?
I'm fine with it. But packaging guidelines asks for clarification. Looks good.
To avoid starting with a lowercase character I'll change the description to:
This package contains a script which prints a brief summary of the system
clock's synchronisation status when the ntpd or chronyd daemon is running.
Ok. Please change the description in initial commit then.
Approved.
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
--- Comment #13 from Miroslav Lichvar mlichvar@redhat.com --- Thanks for the review!
To avoid the annoying warning when using %makeinstall I think it could be replaced with expanded "make install mandir=... bindir.... ".
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
--- Comment #14 from Gwyn Ciesla limburgher@gmail.com --- (fedrepo-req-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/ntpstat
https://bugzilla.redhat.com/show_bug.cgi?id=1510565
Miroslav Lichvar mlichvar@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution|--- |RAWHIDE Last Closed| |2017-12-04 12:13:58
package-review@lists.fedoraproject.org
-
bugzilla＠redhat.com