Cannot find any valid SRPM URL for this ticket. Common causes are:

- You didn't specify `SRPM URL: ...` in the ticket description
  or any of your comments
- The URL schema isn't HTTP or HTTPS
- The SRPM package linked in your URL doesn't match the package name specified
  in the ticket summary


---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

(In reply to Fedora Review Service from comment #1)
> Cannot find any valid SRPM URL for this ticket. Common causes are:
> 
> - You didn't specify `SRPM URL: ...` in the ticket description
>   or any of your comments
> - The URL schema isn't HTTP or HTTPS
> - The SRPM package linked in your URL doesn't match the package name
> specified
>   in the ticket summary
> 
> 
> ---
> This comment was created by the fedora-review-service
> https://github.com/FrostyX/fedora-review-service
> 
> If you want to trigger a new Copr build, add a comment containing new
> Spec and SRPM URLs or [fedora-review-service-build] string.

Redone the URLs; Plz retry

Copr build:
https://copr.fedorainfracloud.org/coprs/build/8730247
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2350109-systemd-cron/fedora-rawhide-x86_64/08730247-systemd-cron/fedora-review/review.txt

Please take a look if any issues were found.


---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

Remaining items from the brief look at the spec file as part of the %license stuff:


> Release:        1

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_version_and_release
 --> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_release_tag


> Group:          System Environment/Base
> BuildRoot:      %{_tmppath}/%{name}-%{version}-build

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_tags_and_sections

Yes, there are still packages that haven't removed the "Group" tag, but typically if the guidelines say "SHOULD NOT" that is a strong recommendation not to override it without a compelling reason. If you need a custom buildroot, define it for your local build environment.


> make

There's few source files to compile, but as it's a review ticket, notice the section about "make":
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_parallel_make

$ rpm -E %make_build
/usr/bin/make -O -j3 V=1 VERBOSE=1


> /usr/libexec/systemd-cron/mail_for_job
> /usr/libexec/systemd-cron/boot_delay
> /usr/libexec/systemd-cron/remove_stale_stamps
> /usr/libexec/systemd-cron/crontab_setgid

/usr/libexec/systemd-cron  directory is "unowned" currently:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/

(In reply to Michael Schwendt from comment #4)

> > Release:        1
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/
> #_version_and_release
>  -->
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
> #_release_tag

I have added `Release: %{autorelease}` as per the 2nd link.

 
> > Group:          System Environment/Base
> > BuildRoot:      %{_tmppath}/%{name}-%{version}-build
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_tags_and_sections
> 
> Yes, there are still packages that haven't removed the "Group" tag, but
> typically if the guidelines say "SHOULD NOT" that is a strong recommendation
> not to override it without a compelling reason. If you need a custom
> buildroot, define it for your local build environment.

Done. Removed the 2 lines

> > make
> 
> There's few source files to compile, but as it's a review ticket, notice the
> section about "make":
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_parallel_make
> 
> $ rpm -E %make_build
> /usr/bin/make -O -j3 V=1 VERBOSE=1

I have just replaced `make` with `%make_build` without any further modifications.
 
> > /usr/libexec/systemd-cron/mail_for_job
> > /usr/libexec/systemd-cron/boot_delay
> > /usr/libexec/systemd-cron/remove_stale_stamps
> > /usr/libexec/systemd-cron/crontab_setgid
> 
> /usr/libexec/systemd-cron  directory is "unowned" currently:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/

Added in `%files` `%dir /usr/libexec/systemd-cron`.

Additionally, I re-enabled support for `/etc/cron.boot` anyways, despite fedora apparently not supporting it with prior cron implementations.

I have also updated the reference copy in the original post here on bugzilla.

Thanks for the guidance.

(In reply to Fedora Review Service from comment #3)
> Copr build:
> https://copr.fedorainfracloud.org/coprs/build/8730247
> (succeeded)
> 
> Review template:
> https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-
> review-2350109-systemd-cron/fedora-rawhide-x86_64/08730247-systemd-cron/
> fedora-review/review.txt
> 
> Please take a look if any issues were found.
> 
> 
> ---
> This comment was created by the fedora-review-service
> https://github.com/FrostyX/fedora-review-service
> 
> If you want to trigger a new Copr build, add a comment containing new
> Spec and SRPM URLs or [fedora-review-service-build] string.

There have been sufficient fixes to various flaws. Kindly re-build with updated spec.

Hi,

I'm one of the two upstream of this project and want to help get it into Fedora.

I can also help with long term maintenance

---

The setgid/setuid is not packaged correctly.

[tchet@fedora ~]$ echo '@hourly date >> cron.log' | crontab 
crontab: -: Permission denied
[tchet@fedora ~]$ ls -l /usr/libexec/systemd-cron/crontab_setgid
-rwxr-xr-x. 1 root root 11752 Mar  8 12:35 /usr/libexec/systemd-cron/crontab_setgid

(In reply to Alexandre Detiste from comment #7)
> Hi,
> 
> I'm one of the two upstream of this project and want to help get it into
> Fedora.
> 
> I can also help with long term maintenance
> 
> ---
> 
> The setgid/setuid is not packaged correctly.
> 
> [tchet@fedora ~]$ echo '@hourly date >> cron.log' | crontab 
> crontab: -: Permission denied
> [tchet@fedora ~]$ ls -l /usr/libexec/systemd-cron/crontab_setgid
> -rwxr-xr-x. 1 root root 11752 Mar  8 12:35
> /usr/libexec/systemd-cron/crontab_setgid

You mean to say it doesn't have actual setgid permissions?
I am fixing it soon...

The "crontabs" package in Fedora already cites two different cron impletations;
so it should be fine to have a third one.

> The cron daemon such as cronie or fcron ...

https://src.fedoraproject.org/rpms/crontabs/blob/rawhide/f/crontabs.spec


All of these cron implemenation follow the same API (i.e. 'crontab' command) and are swapable.

(In reply to Alexandre Detiste from comment #9)
> The "crontabs" package in Fedora already cites two different cron
> impletations;
> so it should be fine to have a third one.
> 
> > The cron daemon such as cronie or fcron ...
> 
> https://src.fedoraproject.org/rpms/crontabs/blob/rawhide/f/crontabs.spec
> 
> 
> All of these cron implemenation follow the same API (i.e. 'crontab' command)
> and are swapable.

`chmod g+s` on `%{_bindir}/crontab` or `/usr/libexec/systemd-cron/crontab_setgid` ? Assuming only latter...

The security model is not the same on Debian & Fedora.

On Debian, /var/spool/cron/crontabs/ is owned by group
'crontab', this job is actualy done by 'cron-daemon-common'.

On Fedora /var/spool/cron is own by the cron implementation.
Which might make the job easier or harder.

Please try to switch back and forth between cronie
and systemd-cron and see wether non-root user crontabs all still work.



[root@fedora ~]# rpm -qf /var/spool/cron
systemd-cron-2.5.1-1.fc43.x86_64
[root@fedora ~]# ls /var/spool/cron/ -dl
drwx-wx--T. 2 root root 18 10 mar 15:55 /var/spool/cron/



$ ls /var/spool/cron/crontabs/ -ld
drwx-wx--T 2 root crontab 4096 20 sep  2023 /var/spool/cron/crontabs/
$ lsb_release -a
Distributor ID: Debian

These might help setting up similar setting if desired

https://salsa.debian.org/debian/cron/-/blob/master/debian/cron-daemon-common.tmpfile?ref_type=heads (new systemd-tmpfiles config)
https://salsa.debian.org/debian/cron/-/blob/master/debian/cron-daemon-common.sysusers?ref_type=heads (new systemd-sysuser config)
https://salsa.debian.org/debian/cron/-/blob/master/debian/cron-daemon-common.postinst?ref_type=heads (beware, lots of legacy)


Have a look there too:

https://src.fedoraproject.org/rpms/cronie/blob/rawhide/f/cronie.spec


/usr/bin/crontab should work for all users even if you don't use it yourself and you will have to learn how it works

I'm maintaining this for 10 years because I first wanted to remove cron; I'm used to this paradox.


All in all that's the reason I never applied for packaging this myself, I only spin up my almost empty Fedora VM once a year or so
and this needs more field testing

> `chmod g+s` on `%{_bindir}/crontab` or `/usr/libexec/systemd-cron/crontab_setgid` ? Assuming only latter...

Of course, the only purpose of the tiny helper is to reduce the attack surface and have 
as little code as possible setuid/setgid.

A failure here would mean a possible privilège escalation;
that's what we want to avoid.

The editor, where `crontab -e` is call, is never run as root,
that would be the most scary part.

(In reply to Alexandre Detiste from comment #12)
> > `chmod g+s` on `%{_bindir}/crontab` or `/usr/libexec/systemd-cron/crontab_setgid` ? Assuming only latter...
> 
> Of course, the only purpose of the tiny helper is to reduce the attack
> surface and have 
> as little code as possible setuid/setgid.
> 
> A failure here would mean a possible privilège escalation;
> that's what we want to avoid.
> 
> The editor, where `crontab -e` is call, is never run as root,
> that would be the most scary part.

I need to in `%files` add `%attr(644, root, crontab) %dir /var/spool/cron`.

Do I need to also add `%config(noreplace)`?

(In reply to Pramod V U from comment #13)
> 
> I need to in `%files` add `%attr(644, root, crontab) %dir /var/spool/cron`.
> 
> Do I need to also add `%config(noreplace)`?

Edit: crontab group doesn't exist, only _crontab_failure; what should I do?

For now I just settled on the setgid.

Some guidance please?

I am including the `crontab` group within `sysusers.d/systemd-cron.conf`
AND attributing `/usr/libexec/systemd-cron/crontab_setgid` `chmod g+s`

AND `/var/spool/cron` `%attr(1730, root, crontab)`

I will include the `tmpfiles.d` only if you want, myself I think it's unnecessary as RPM handles the permissions fine during install.

Should I include `systemctl reload-or-restart systemd-sysusers.service` post-install? [OR will RPM handle it? Mostly not, but IDK; Am including it anyways...]

RPM *needs* the `crontab` group beforehand, to (un)pack it that way.

I just included the tmpfiles file and excluded the directory from the package...

and added `systemd-tmpfiles-setup.service` to the reload-or-restart.

So the `crontab` group has been added to the `sysusers.d` file of systemd-cron.

And the `/var/spool/cron` directory has been excluded from the package, and exclusively handled by a `tmpfiles.d` drop-in.

This solves the problem of the directory and permissioning.

Spec URL: https://download.copr.fedorainfracloud.org/results/pramodvu1502/systemd-cron/srpm-builds/08741493/systemd-cron.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/pramodvu1502/systemd-cron/srpm-builds/08741493/systemd-cron-2.5.1-1.src.rpm
[These URLs changed on 11/03/2025 14:12/IST... to incorporate a change in `crontab` group as well as `/var/spool/cron`]

Description: A systemd generator which generates service-timer unit pairs from cronjobs.

Fedora Account System Username: pramodvu1502

Copr with the package: https://copr.fedorainfracloud.org/coprs/pramodvu1502/systemd-cron/

Upstream repo: https://github.com./systemd-cron/systemd-cron

Package sponsor request: https://pagure.io/packager-sponsors/issue/708

Created attachment 2080249 [details]
The .spec file difference from Copr build 8730247 to 8768976

Copr build:
https://copr.fedorainfracloud.org/coprs/build/8768976
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2350109-systemd-cron/fedora-rawhide-x86_64/08768976-systemd-cron/fedora-review/review.txt

Found issues:

- No gcc, gcc-c++ or clang found in BuildRequires
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/
- License file COPYING is not marked as %license
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text
- Systemd service file(s) in systemd-cron
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scriptlets

Please know that there can be false-positives.

---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

Will this review actually take place? Sorry if I asked in the wrong place.

I reviewed the following, I think you fixed most of it. This looks like a nice package!

Spec URL: https://download.copr.fedorainfracloud.org/results/pramodvu1502/systemd-cron/fedora-rawhide-x86_64/08748905-systemd-cron/systemd-cron.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/pramodvu1502/systemd-cron/fedora-rawhide-x86_64/08748905-systemd-cron/systemd-cron-2.5.1-1.fc43.src.rpm

I noticed that systemd-cron provides some tests, would it be possible to run these in %check?

Yes, I've fixed most of it.

However, I need to ask if the cron-update.{path,service} is really required... It basically runs `systemctl daemon-reload` if any file cron-related is touched.

As for `%check` yes, it's on my TODO list, but low priority.
I'll add %check soon;

If you have "review"ed the package, can it now be put into the fedora repos?

As for `make install`, is there something like `%make_install`?
AND
Should I move the `./configure` part from `%build` to `%setup`?

This is the output from fedora-review:

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- If your application is a C or C++ application you must list a
  BuildRequires against gcc, gcc-c++ or clang.
  Note: No gcc, gcc-c++ or clang found in BuildRequires
  See: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/
- Dist tag is present.
- Permissions on files are set properly.
  Note: See rpmlint output
  See: https://docs.fedoraproject.org/en-US/packaging-
  guidelines/#_file_permissions
- 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.
  Note: License file COPYING is not marked as %license
  See: https://docs.fedoraproject.org/en-US/packaging-
  guidelines/LicensingGuidelines/#_license_text
- systemd_post is invoked in %post, systemd_preun in %preun, and
  systemd_postun in %postun for Systemd service files.
  Note: Systemd service file(s) in systemd-cron
  See: https://docs.fedoraproject.org/en-US/packaging-
  guidelines/Scriptlets/#_scriptlets


===== MUST items =====

C/C++:
[ ]: Package does not contain kernel modules.
[x]: Package does not contain any libtool archives (.la)
[x]: Package contains no static executables.
[x]: Rpath absent or only used for internal libs.

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: "Unknown or generated", "MIT License", "BSD 0-Clause License
     and/or MIT License", "*No copyright* MIT License", "*No copyright* BSD
     0-Clause License". 57 files have unknown license. Detailed output of
     licensecheck in /home/meeuw/2350109-systemd-cron/licensecheck.txt
[x]: Package does not own files or directories owned by other packages.
     Note: Dirs in package are owned also by: /etc/cron.d(cronie)
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[ ]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[ ]: Package consistently uses macros (instead of hard-coded directory
     names).
[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.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[x]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 26779 bytes in 3 files.
[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]: The License field must be a valid SPDX expression.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[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]: Package does not contain duplicates in %files.
[x]: Package must not depend on deprecated() packages.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[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).
[ ]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[ ]: %check is present and all tests pass.
[ ]: Packages should try to preserve timestamps of original installed
     files.
[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 debuginfo package(s).
     Note: There are rpmlint messages (see attachment).
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: systemd-cron-2.5.1-1.fc43.x86_64.rpm
          systemd-cron-2.5.1-1.fc43.src.rpm
============================ rpmlint session starts ============================
rpmlint: 2.7.0
configuration:
    /usr/lib/python3.13/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-spdx-licenses.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
rpmlintrc: [PosixPath('/tmp/tmpisf2qz4r')]
checks: 32, packages: 2

systemd-cron.spec:15: W: unversioned-explicit-provides cronie
systemd-cron.spec:16: W: unversioned-explicit-provides cronie-anacron
systemd-cron.x86_64: W: tmpfile-not-in-filelist /var/spool/cron
systemd-cron.src: W: summary-not-capitalized systemd generator to provide cron daemon & anacron functionality
systemd-cron.x86_64: W: summary-not-capitalized systemd generator to provide cron daemon & anacron functionality
systemd-cron.src: E: spelling-error ('anacron', 'Summary(en_US) anacron -> macron')
systemd-cron.src: E: spelling-error ('crontab', '%description -l en_US crontab -> contactable')
systemd-cron.src: E: spelling-error ('anacron', '%description -l en_US anacron -> macron')
systemd-cron.x86_64: E: spelling-error ('anacron', 'Summary(en_US) anacron -> macron')
systemd-cron.x86_64: E: spelling-error ('anacron', '%description -l en_US anacron -> macron')
systemd-cron.x86_64: E: setgid-binary /usr/libexec/systemd-cron/crontab_setgid root 2755
systemd-cron.x86_64: W: post-without-tmpfile-creation /usr/lib/tmpfiles.d/systemd-cron.conf
systemd-cron.x86_64: W: percent-in-%preun
systemd-cron.x86_64: W: percent-in-%postun
systemd-cron.x86_64: W: percent-in-%post
systemd-cron.x86_64: E: non-standard-executable-perm /usr/libexec/systemd-cron/crontab_setgid 2755
systemd-cron.src: E: no-changelogname-tag
systemd-cron.x86_64: E: no-changelogname-tag
systemd-cron.spec: W: no-%check-section
systemd-cron.x86_64: W: files-duplicate /usr/share/licenses/systemd-cron/LICENSE /usr/share/doc/systemd-cron/COPYING
systemd-cron.src: E: description-line-too-long Provides a systemd generator to run cron jobs in /etc/cron.hourly cron.daily cron.weekly and cron.monthly directories, crontab etc..
systemd-cron.x86_64: E: description-line-too-long Provides a systemd generator to run cron jobs in /etc/cron.hourly cron.daily cron.weekly and cron.monthly directories, crontab etc..
systemd-cron.spec:55: W: configure-without-libdir-spec
 2 packages and 0 specfiles checked; 11 errors, 12 warnings, 13 filtered, 11 badness; has taken 0.5 s 




Rpmlint (debuginfo)
-------------------
Checking: systemd-cron-debuginfo-2.5.1-1.fc43.x86_64.rpm
============================ rpmlint session starts ============================
rpmlint: 2.7.0
configuration:
    /usr/lib/python3.13/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-spdx-licenses.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
rpmlintrc: [PosixPath('/tmp/tmpd4folgmu')]
checks: 32, packages: 1

systemd-cron-debuginfo.x86_64: E: no-changelogname-tag
 1 packages and 0 specfiles checked; 1 errors, 0 warnings, 14 filtered, 1 badness; has taken 0.4 s 





Rpmlint (installed packages)
----------------------------
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory
============================ rpmlint session starts ============================
rpmlint: 2.7.0
configuration:
    /usr/lib/python3.13/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-spdx-licenses.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
checks: 32, packages: 2

systemd-cron.x86_64: W: tmpfile-not-in-filelist /var/spool/cron
systemd-cron.x86_64: W: summary-not-capitalized systemd generator to provide cron daemon & anacron functionality
systemd-cron.x86_64: E: spelling-error ('anacron', 'Summary(en_US) anacron -> macron')
systemd-cron.x86_64: E: spelling-error ('anacron', '%description -l en_US anacron -> macron')
systemd-cron.x86_64: E: setgid-binary /usr/libexec/systemd-cron/crontab_setgid root 2755
systemd-cron.x86_64: W: post-without-tmpfile-creation /usr/lib/tmpfiles.d/systemd-cron.conf
systemd-cron.x86_64: W: percent-in-%preun
systemd-cron.x86_64: W: percent-in-%postun
systemd-cron.x86_64: W: percent-in-%post
systemd-cron.x86_64: E: non-standard-executable-perm /usr/libexec/systemd-cron/crontab_setgid 2755
systemd-cron-debuginfo.x86_64: E: no-changelogname-tag
systemd-cron.x86_64: E: no-changelogname-tag
systemd-cron.x86_64: W: files-duplicate /usr/share/licenses/systemd-cron/LICENSE /usr/share/doc/systemd-cron/COPYING
systemd-cron.x86_64: E: description-line-too-long Provides a systemd generator to run cron jobs in /etc/cron.hourly cron.daily cron.weekly and cron.monthly directories, crontab etc..
 2 packages and 0 specfiles checked; 7 errors, 7 warnings, 20 filtered, 7 badness; has taken 1.5 s 



Source checksums
----------------
https://github.com/systemd-cron/systemd-cron/archive/v2.5.1.tar.gz :
  CHECKSUM(SHA256) this package     : 5453566e44b88cc9de6fc1933644b8fdfcd93d2814893548de09a12f865a8870
  CHECKSUM(SHA256) upstream package : 5453566e44b88cc9de6fc1933644b8fdfcd93d2814893548de09a12f865a8870


Requires
--------
systemd-cron (rpmlib, GLIBC filtered):
    /bin/sh
    /usr/bin/sh
    crontabs
    libc.so.6()(64bit)
    libm.so.6()(64bit)
    libmd.so.0()(64bit)
    libmd.so.0(LIBMD_0.0)(64bit)
    libstdc++.so.6()(64bit)
    libstdc++.so.6(CXXABI_1.3)(64bit)
    libstdc++.so.6(CXXABI_1.3.9)(64bit)
    rtld(GNU_HASH)
    systemd



Provides
--------
systemd-cron:
    cronie
    cronie-anacron
    group(_cron-failure)
    group(crontab)
    systemd-cron
    systemd-cron(x86-64)
    user(_cron-failure)



Generated by fedora-review 0.10.0 (e79b66b) last change: 2023-07-24
Command line :/usr/bin/fedora-review -b 2350109
Buildroot used: fedora-rawhide-x86_64
Active plugins: Shell-api, Generic, C/C++
Disabled plugins: Perl, R, PHP, Ocaml, Haskell, fonts, SugarActivity, Python, Java
Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH

====

This is my first review so bear with me.

1. configure is fine in %build, there's also %configure I'm not sure if you should use that.
2. consider using %buildroot instead of using $RPM_BUILD_ROOT
3. %changelog is missing
4. the description is too long

%configure IDK... I'll just leave it for now...

RPM_BUILD_ROOT is a shell (or environment?) variable for that purpose while `%{buildroot}` is substituted by RPM itself...
Any reason to change? I'll have to consider...

%changelog is not needed; Nothing has happened to software after completion, other than bugfixes and a rewrite in C++
Should I write it anyways, with these changes?

I will shorten the %description soon, alongwith the %configure, %make_install, %buildroot and %changelog after a bit of consideration and evaluation... kindly state your opinion on esp. %make_install

%changelog is required in the .spec file, just add to the bottom of the spec file:

%changelog
%autochangelog

And the changelog will be automatically generated from git.

If you can please use %make_install

As an inspiration you can look at qemu.spec https://src.fedoraproject.org/rpms/qemu/blob/rawhide/f/qemu.spec

I also noticed that %post automatically enables and starts the installed service, not sure if that's right. I think this causes the workarounds you need to do in %pre.

Please take a look at https://src.fedoraproject.org/rpms/cronie/blob/rawhide/f/cronie.spec#_124 and use %systemd_post crond.service

I added %make_install and %changelog

Apparently %conf is the section for configuring, and %configure is a RPM macro for autotools-based configure scripts...

I'll just use %build

Here's why I was using RPM_BUILD_ROOT over %buildroot... https://rpm-software-management.github.io/rpm/manual/spec.html#build-scriptlets
Should I still use %buildroot ?

Yes, I also tried %configure and it doesn't work, forget about it

I don't see anything why you should use RPM_BUILD_ROOT over %{buildroot} in the document you've linked (there is a reference about the BuildRoot preable but that's something different.

I have left %build as-it-is, with minor formatting fixes in the comments...

I have also added BuildRequires to the systemd RPM macros package...

I have also done a series of `sed -i 's/\/bin/\%\{\_bindir\}/g' systemd-cron.spec`,
for `/bin` as `%{_bindir}`, `/usr/libexec` as `%{_libexecdir}`, `/usr/lib/systemd/system` as `%{_unitdir}`, etc...

Also cleared out the unused commented-out parts of the %install scriptlet,
added appropriate quotes around all paths...

I also rewrote all the calls to `systemctl` with macros...
EXCEPT the `systemctl reload-or-restart systemd-tmpfiles.service systemd-sysusers.service`; I didn't quite understand which macro does that...
I'll remove it if it's not needed...

I didn't yet do the change to %buildroot,
If the SRPM is built into a binary on another system, and for whatever reason the buildroot is chosen/calculated differently, then won't the script have %buildroot hardcoded to the old value? While RPM_BUILD_ROOT has a newer value?

If I am wrong here, kindly inform me. I'll right away change it with `sed -i 's/\$\{RPM\_BUILD\_ROOT\}/\%\{buildroot\}/g' systemd-cron.spec`

I'll just use %buildroot
I am getting some errors in my copr which suggest that the variable is empty...

Everything must use the correct macros


See https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/

/run = %{_rundir}

/usr/lib/systemd/system-preset/ = %{_presetdir}

/usr/lib/sysusers.d = %{_sysusersdir}

/usr/lib/tmpfiles.d = %{_tmpfilesdir}

/usr/lib/systemd/system/ = %{_unitdir}

/usr/libexec = %{_libexecdir}

Add a note


%build
# Don't use the %%configure macro as this is not an autotool script
./configure \

Everything sorted, I have uploaded the new specfile to the copr, and am rebuilding...

I have included the %%configure note too...

You will need to add systemd-rpm-macros for the systemd macros

BuildRequires: systemd-rpm-macros

%{_unitdir}-generators = %{_systemdgeneratordir}

I am writing this by referring to the fedora-review output above:
Whatever is "fixed" (not "already fixed") here will come soon in the next spec-file though...

```
systemd-cron.x86_64: W: tmpfile-not-in-filelist /var/spool/cron
```

I omitted it from the filelist for a reason;
It needs to be created *after* systemd-sysusers creates the required group "crontab".

```
systemd-cron.x86_64: W: summary-not-capitalized systemd generator to provide cron daemon & anacron functionality
```

Fixed

```
systemd-cron.x86_64: E: spelling-error ('anacron', 'Summary(en_US) anacron -> macron')
systemd-cron.x86_64: E: spelling-error ('anacron', '%description -l en_US anacron -> macron')
```

Also fixed by writing "(ana)cron" (mostly)

```
systemd-cron.x86_64: E: setgid-binary /usr/libexec/systemd-cron/crontab_setgid root 2755
```

What's the issue here? That binary is *supposed* to be setgid...

```
systemd-cron.x86_64: W: post-without-tmpfile-creation /usr/lib/tmpfiles.d/systemd-cron.conf
```

I know that I am missing a macro here, but IDK what...

```
systemd-cron.x86_64: W: percent-in-%preun
systemd-cron.x86_64: W: percent-in-%postun
systemd-cron.x86_64: W: percent-in-%post
```

Well, %systemd_ macros for their intended purpose...

```
systemd-cron.x86_64: E: non-standard-executable-perm /usr/libexec/systemd-cron/crontab_setgid 2755
```

That binary is *supposed* to be setgid...

```
systemd-cron-debuginfo.x86_64: E: no-changelogname-tag
systemd-cron.x86_64: E: no-changelogname-tag
```

Already fixed in existing specfile

```
systemd-cron.x86_64: W: files-duplicate /usr/share/licenses/systemd-cron/LICENSE /usr/share/doc/systemd-cron/COPYING
```

Already fixed, by removing COPYING altogether.

```
systemd-cron.x86_64: E: description-line-too-long Provides a systemd generator to run cron jobs in /etc/cron.hourly cron.daily cron.weekly and cron.monthly directories, crontab etc..
```

Already fixed.

`BuildRequires: systemd-rpm-macros` is already there by now


Thanks for %{_systemdgeneratordir}, but is the "d" there or is it just %{_systemgeneratordir}?

Change Url: to URL:


URL:            https://github.com/systemd-cron/systemd-cron

shorten and use a proper name for the source

Source0:        %{url}/archive/v%{version}/%{name}-%{version}.tar.gz


I think this needs to be addressed

Provides:       cronie
Provides:       cronie-anacron
Conflicts:      cronie
Conflicts:      cronie-anacron

See https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/

(In reply to Pramod V U from comment #38)

You should ignore this spelling warning

> ```
> systemd-cron.x86_64: E: spelling-error ('anacron', 'Summary(en_US) anacron
> -> macron')
> systemd-cron.x86_64: E: spelling-error ('anacron', '%description -l en_US
> anacron -> macron')
> ```
> 
> Also fixed by writing "(ana)cron" (mostly)
> 
> I know that I am missing a macro here, but IDK what...
> 
> ```
> systemd-cron.x86_64: W: percent-in-%preun
> systemd-cron.x86_64: W: percent-in-%postun
> systemd-cron.x86_64: W: percent-in-%post
> ```
> 
> Well, %systemd_ macros for their intended purpose...

https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd

> 
> ```
> systemd-cron-debuginfo.x86_64: E: no-changelogname-tag
> systemd-cron.x86_64: E: no-changelogname-tag
> ```
> 

> 
> Thanks for %{_systemdgeneratordir}, but is the "d" there or is it just
> %{_systemgeneratordir}?

There is a 'd' in there

$ rpm -E %{_systemdgeneratordir}
/usr/lib/systemd/system-generators

The macros' usage is compliant with the documentation you linked.

What should I do about the `systemctl reload-or-restart systemd-tmpfiles.service systemd-sysusers.service` call in `%post`?
Let it be, should it be removed, is there a macro for it?

AND what should I do about the setgid error in fedora-review? I have used %attr for it, will try it now...

Unfortunately the character limit is reached before the specfile can be fit into the "custom" script...

The specfile really needs to be upstream... things would be easier...

The specfile for reference:
```
# https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
# https://github.com/systemd/systemd/blob/42911a567dc22c3115fb3ee3c56a7dcfb034f102/src/core/macros.systemd.in

# "If your package includes one or more systemd units that need
# to be enabled by default on package installation,
# they must be covered by the Fedora preset policy."

Name:           systemd-cron
Version:        2.5.1
Release:        %{autorelease}
License:        MIT
Summary:        A systemd generator to provide (ana)cron functionality
Url:            https://github.com/systemd-cron/systemd-cron
Source0:        https://github.com/systemd-cron/systemd-cron/archive/v%{version}.tar.gz
Provides:       cronie
Provides:       cronie-anacron
Conflicts:      cronie
Conflicts:      cronie-anacron
Requires:       crontabs
Requires:       systemd
Requires:       libmd
BuildRequires:  g++
BuildRequires:  libmd-devel
BuildRequires:  systemd-rpm-macros

%description
A systemd generator implementing (ana)cron.
It uses systemd.timer and systemd.service under the hood.

%pre
# Prevent execution of boot and reboot scripts on installation
touch %{_rundir}/crond.reboot
touch %{_rundir}/crond.bootdir

%preun
%systemd_preun cron.target

%post
%systemd_post cron.target

# To apply the /var/spool/cron and crontab group to the system on installation
systemctl reload-or-restart systemd-sysusers.service systemd-tmpfiles-setup.service

%postun
%systemd_postun_with_restart cron.target

%prep
%setup -q

%build
# Don't use the %%configure macro as this is not an autotool script
./configure \
  --version="%{version}" \
  --prefix="%{_prefix}" \
  --bindir="%{_bindir}" \
  --datadir="%{_datadir}" \
  --libdir="%{_libdir}" \
  --libexecdir="%{_libexecdir}" \
  --mandir="%{_mandir}" \
  --docdir="%{_docdir}" \
  --unitdir="%{_unitdir}" \
  --generatordir="%{_systemdgeneratordir}" \
  --sysusersdir="%{_sysusersdir}" \
  --enable-runparts=no \
  --enable-minutely=yes \
  --enable-quarterly=yes \
  --enable-semi_annually=yes \
  --enable-boot=yes

# Disabled run-parts i.e. static single units for each granuarity level.
# Instead opting to use only the systemd-crontab-generator
# run-parts override the generator when installed
#
# Also enabled all disabled-by-default granularity levels
#
# cron.boot isn't otherwise supported in fedora,
# But we enable it anyway for those who want it.

# Compile
%make_build

%install
%make_install

# Required directories
mkdir -p "%{buildroot}%{_sysconfdir}/cron.d/"

# Systemd preset policy
mkdir -p "%{buildroot}%{_presetdir}"
echo 'enable cron.target' > "%{buildroot}%{_presetdir}/50-systemd-cron.preset"

# Appropriate group(s);
echo 'g crontab - -' >> "%{buildroot}%{_sysusersdir}/systemd-cron.conf"
# Appending this to systemd-cron.conf already having _cron_failure

# Preparing /var/spool/cron using tmpfiles.d
mkdir -p "%{buildroot}%{_tmpfilesdir}"
echo 'd /var/spool/cron 1730 root crontab' >> "%{buildroot}%{_tmpfilesdir}/systemd-cron.conf"
# /var/spool/cron not included in package as tmpfiles handles it

# setgid helper
chmod g+s "%{buildroot}%{_libexecdir}/systemd-cron/crontab_setgid"

%files
%license LICENSE
%doc README.md CHANGELOG

%dir %{_sysconfdir}/cron.d/
%dir %{_libexecdir}/systemd-cron

%{_bindir}/crontab
%{_libexecdir}/systemd-cron/mail_for_job
%{_libexecdir}/systemd-cron/boot_delay
%{_libexecdir}/systemd-cron/remove_stale_stamps
%attr(2755, root, crontab) %{_libexecdir}/systemd-cron/crontab_setgid
%{_systemdgeneratordir}/systemd-crontab-generator

%{_presetdir}/50-systemd-cron.preset
%{_unitdir}/cron.target
%{_unitdir}/cron-update.path
%{_unitdir}/cron-update.service
%{_unitdir}/cron-mail@.service
%{_unitdir}/systemd-cron-cleaner.service
%{_unitdir}/systemd-cron-cleaner.timer

%{_sysusersdir}/systemd-cron.conf
%{_tmpfilesdir}/systemd-cron.conf

%{_mandir}/man1/crontab.*
%{_mandir}/man5/crontab.*
%{_mandir}/man5/anacrontab.*
%{_mandir}/man7/systemd.cron.*
%{_mandir}/man8/systemd-crontab-generator.*

%changelog
%autochangelog
```

Great, please have a look at the following

- "Provides: cronie" is wrong in my eyes
- I think the %pre script should be removed (as it isn't started anymore)
- You can omit creating empty directories (/etc/cron.d), it will be automatically managed by %dir in %files
- It would be really nice to have 50-systemd-cron.preset and/or systemd-cron.conf provided by upstream, have you tried to get these added using a PR?
- Use the _systemdgeneratordir macro
- Use the suggested Url: %{url}/archive/v%{version}/%{name}-%{version}.tar.gz

So,
- I will remove "Provides:"...
- %pre script is needed... Ideally cron.target is enabled by default and functional at installation... As per the "preset"... The 
- I will remove `mkdir /etc/cron,d`
- I am collecting a few things to PR together... Now I will within fork and PR a few days
- I *am* using the _systemdgeneratordir macro now...
- I will use %{url}/archive/v%{version}.tar.gz
- %{url}/archive/v%{version}/%{name}-%{version}.tar.gz is "Not found"; I'll just use %{url}/archive/v%{version}.tar.gz

BTW, here are some things I need to know from more experienced packagers,
- Is the cron-update.{path,service} needed? It basically runs `systemctl daemon-reload` whenever cron files are touched.
- I run `%{_bindir}/systemctl reload-or-restart systemd-sysusers.service systemd-tmpfiles-setup.service` in %post
- In order to get the required users and directory ready right after install. Atleast the tmpfiles.d thing is needed...
- Creating the directory in %install or %post is a tricky issue regarding the "crontab" group the directory needs to be set to.
- I will also change (in my PR) the user and group handling from `systemd-sysusers` to systemd's JSON user/group record format... Should I (in context of fedora I am asking)?

I have successfully forked: https://github.com/pramodvu1502/systemd-cron
I am slowly committing to it... the various changes...

I have to:
- Add the preset file
- Carefully modify ./configure and the Makefile(s) to install it too...
- ./configure will need a new --presetdir option to support %{_presetdir}

Then I will (after asking opinion of a few, you all too):
- Write the systemd JSON records for the system user, rather than using systemd-sysusers

Hi,

Upstream talking here.

> - Is the cron-update.{path,service} needed?

Yes, absolutely. Vixie-Cron or Cronie will either watch these location
with some os-provided facility (iselect()...) or poll these every minute.

Also, when systemd-cron's "crontab" modify files in /var/spool...;
it does not communicate with the generator and can not anyway.

The current `systemctl daemon-reload` is the only way to refreh correclty & only once.



> "Provides:"

On Debian we have this nice things called "cron-daemon" & "cron-daemon-common" 

'cron-daemon' is a so-called _virtual package_ provided by either vixie-cron/cron/systemd-cron.

Theses three mutual implementation will also Conflicts: on 'cron-daemon' to avoid that the system explode.

Random package needing some cron implementation will then depends on virtual package cron-daemon


'cron-daemon-common' is a runtime package shared by the 3 different crons and it contains
the tmpfiles, sysusers.d and /etc/crontab stuff.

Fedora has "crontabs" that fill a similar purpose.
https://packages.fedoraproject.org/pkgs/crontabs/crontabs/




> I think this needs to be addressed
>
> Provides:       cronie
> Provides:       cronie-anacron
> Conflicts:      cronie
> Conflicts:      cronie-anacron

I joted this together 10 years ago.

In practice if packages in Fedora Depends: on "cronie" and nothing else
that makes systemd-cron uninstable.

> The specfile really needs to be upstream... things would be easier...

That's not how it works. Upstream should not be bothered after each 50 attemps
to nudge a specfile in the right direction. I'm considering removing
this contrib/ file altogether as soon as this package is accepted.

Acceptiong tiny tmpfiles/sysusers sutff would be ok.

Greetings

There's no /etc/cron.boot in Fedora; please stay in line with what "cronie" & "crontabs" do.

https://src.fedoraproject.org/rpms/crontabs/blob/rawhide/f/crontabs.spec

But crontabs "Requires:" cronie

I've no idea how to untangle this knot.

Maybe in the same way as "/usr/sbin/sendmail", using "alternatives"?

This will require changes in cronie...

> Yes, absolutely. Vixie-Cron or Cronie will either watch these location with some os-provided facility (iselect()...) or poll these every minute.
>
> Also, when systemd-cron's "crontab" modify files in /var/spool...;
> it does not communicate with the generator and can not anyway.
>
> The current `systemctl daemon-reload` is the only way to refreh correclty & only once.

Agreed

> Fedora has "crontabs" that fill a similar purpose.
> https://packages.fedoraproject.org/pkgs/crontabs/crontabs/

But we have to supply the group and tmpfiles.d snippet for `/var/spool/cron`.
I think it would be better if those too would be in this shared package...
Anyways, adding the systemd-userdb JSON records in my fork...

> In practice if packages in Fedora Depends: on "cronie" and nothing else
that makes systemd-cron uninstable.

Do the other cron daemons like fcron do `Provides: cronie`?
If yes, then we too must do it...

> That's not how it works. Upstream should not be bothered after each 50 attemps
to nudge a specfile in the right direction. I'm considering removing
this contrib/ file altogether as soon as this package is accepted.

I agree,
but the copr needs the specfile to be with the sources... in the same repository...
OR a custom script (which I used until now, heredoc-ing the spec-file into it);
But now the character limit is reached.

I'll just use the custom script but with `git` pulling the specfile separately (from *my* github repo maybe).
OR does someone have a better solution?

> There's no /etc/cron.boot in Fedora; please stay in line with what "cronie" & "crontabs" do.

Fine; I am disabling support for the boot timer...

> I've no idea how to untangle this knot.

Maybe just use `Provides: cronie` for now...

> Maybe in the same way as "/usr/sbin/sendmail", using "alternatives"?

Great idea...
But what? `crontabs` binary...

> This will require changes in cronie...

Just temporarily resort to `Provides: cronie`...
Once everything else sorted out we'll see into this...

PR: https://github.com/systemd-cron/systemd-cron/pull/171

It improves a few things not directly related to the generator:
- Honours the "%{_presetdir}" macro (./configure itself and the Makefile too)
- Preset file is already included now in the repo
- spec-file is in the repo, retrievable without a "custom script" in the copr...
- Other things not directly related to that.

Yes, the spec-file mustn't be the problem of upstream, but the copr...

In the copr web interface,
I can in the "Builds" section skip all of this and directly link/upload the spec-file, but the "Packages" section...
For now I have "Packages" section to be the older version, am directly uploading the newer specfiles for "Build".
Is this fine? If yes then upstream needn't be worried about the specfile at all...

I'm not sure if alternatives can be used for systemd service unit files (like /lib/systemd/system/crond.service).

Would it be possible to install systemd-cron at the same time as cronie (and be able to switch using alternatives?)

(In reply to Dick Marinus from comment #52)
> I'm not sure if alternatives can be used for systemd service unit files
> (like /lib/systemd/system/crond.service).

There's no crond.service here, just cron.target (and a few other units, but for auxillary tasks only)

> Would it be possible to install systemd-cron at the same time as cronie (and
> be able to switch using alternatives?)

The *only* thing needed to be using "alternatives" is the crontab binary.

AND could the tmpfiles.d drop-in for `/var/spool/cron` as well as the sysusers.d drop-in for `crontab` group be put in the `crontabs` package?
For *all* cron implementations?

And please, I *have* to `Provides: cronie` in order to sanely satisfy all dependants of cron, `systemd-cron` is pretty much compatible anyways...

If I have to have an optional dependency on sendmail, I will `Reommends: %{_bindir}/sendmail`. Am I right?

Building using my fork... until PR is reviewed and accepted...
IDK, but the release might need to be re-released in order to make sure that the new commits are actually packaged...

> There's no crond.service here, just cron.target (and a few other units, but for auxillary tasks only)
In theory cronie could switch to a cron.target

> The *only* thing needed to be using "alternatives" is the crontab binary.
There should only be one cron-like daemon running, this can be solved using "alternatives"

For /usr/sbin/sendmail /usr/bin/alternatives --initscript is used to allow switching between different MTAs, I don't know if this could be implemented systemd .targets.

To be clear to you, I won't accept this review with the current hacks for cronie. I really dislike any hard-couplings with cronie (what if cronie gets renamed, that would require changes in this package). And I don't like that cronjobs might get forcefully killed (or run twice) from cronie when installing systemd-cron.

My preferred solution would be that cronie and systemd-cron can be installed at the same time possibly using /usr/bin/alternative to switch between both.

But feel free to suggest other solutions than the current hacks.

If you'd like I can also remove myself as reviewer so you can find somebody else, no hard feelings.

"Alternatives" mechanism would be too complicated, considering that crond.service and cron.target are 2 different units...

Yes, systemd does have a `Conflicts=` though, which could be used in cron.target here...
Should I add a `Conflicts=crond.service` to cron.target?

> To be clear to you, I won't accept this review with the current hacks for cronie. I really dislike any hard-couplings with cronie (what if cronie gets renamed, that would require changes in this package).

I agree, but the "solution(s)" is/are not that simple... will need a bit of time...

Is it possible to amend cronie.spec to `Provides: cron` and make all packages having `Requires: cronie` to instead depend on `cron`?
AND `Provides: cron` in this package too.

Yes, alternatives mechanism is ultimately needed, for the "crontabs" binary.
But if it *is* possible for the crond.service and cron.target units, and it's not too complicated, it might be fine.

So I propose the following solutions:
- Alternatives mechanism for %{_bindir}/crontab binary...
- systemd.unit Conflicts=crond.service
- Alternatives mechanism for crond.service <-> cron.target if possible...
- If really needed, every cron daemon `Provides: cron` and every dependant `Requires: cron`... If really needed.
- What else? A better solution?

> Is it possible to amend cronie.spec to `Provides: cron` and make all packages having `Requires: cronie` to instead depend on `cron`?
AND `Provides: cron` in this package too.

That's up to the maintainer of cronie, I'd suggest to create another bugzilla report with a feature request for cronie to support multiple cron daemons in Fedora. This report should be blocked by it.

We also have to take in account that a user can switch back to cronie from systemd-cron.

(In reply to Dick Marinus from comment #57)
> > Is it possible to amend cronie.spec to `Provides: cron` and make all packages having `Requires: cronie` to instead depend on `cron`?
> AND `Provides: cron` in this package too.
> 
> That's up to the maintainer of cronie, I'd suggest to create another
> bugzilla report with a feature request for cronie to support multiple cron
> daemons in Fedora. This report should be blocked by it.

I'll create it.

Additionally, I think the tmpfiles.d drop-in meant for `/var/spool/cron` should be handled by the `crontabs` package itself.
If I want to suggest that, can I write it in the same bugzilla report as of cronie, or should I do a separate report? I guess the latter...

> We also have to take in account that a user can switch back to cronie from
> systemd-cron.

Of course, that's something which can't be ignored...
Steps I am taking:
- Adding Conflicts=crond.service to cron.target
- Preparing alternatives mechanism for crontab binary and the units if possible.

I will soon file a bugzilla report for cronie, to support alternatives.

But before that, I have to ask: Is this spec-file right? anything to improve?
Hooks for alternative crontab binaries are added...
BUT unfortunately I can't use alternatives mechanism for cron.target and crond.service; It is meant to allow *one* file to be provided by multiple packages and allowing you to choose any one.

BTW, why is alternatives needed? `Conflicts: cronie` is already there, so there won't be another cron implementation anyway.

Can I `Provides: cron` and `Conflicts: cron` (and request all cron implementations to do the same), to fix this issue?

The spec-file:
```
# Copyright (C) 2023,2025 наб (nabijaczleweli)
# Copyright (C) 2023 Alexandre Detiste (alexandre)
# Copyright (C) 2025 Pramod (pramodvu1502) (only for this specfile though)
# SPDX-License-Identifier: MIT

Name:             systemd-cron
Version:          2.5.1
Release:          %{autorelease}
License:          MIT
Summary:          A systemd generator to provide (ana)cron functionality
URL:              https://github.com/systemd-cron/systemd-cron
Source0:          %{url}/archive/v%{version}.tar.gz
Conflicts:        cronie
Conflicts:        cronie-anacron
Requires:         crontabs
Requires:         systemd
Requires:         libmd
Requires(post):   %{_bindir}/update-alternatives
Requires(postun): %{_bindir}/update-alternatives
#Recommends:       %%{_bindir}/sendmail
BuildRequires:    g++
BuildRequires:    libmd-devel
BuildRequires:    systemd-rpm-macros

%description
A systemd generator implementing (ana)cron.
It uses systemd.timer and systemd.service under the hood.

%pre
# Prevent execution of cron.reboot scripts on installation
touch %{_rundir}/crond.reboot

%preun
%systemd_preun cron.target

%post
%systemd_post cron.target

update-alternatives --install %{_bindir}/crontab %{name} %{_bindir}/crontab.%{name}

# To apply the /var/spool/cron and crontab group to the system on installation
%{_bindir}/systemctl reload-or-restart systemd-sysusers.service systemd-tmpfiles-setup.service

%postun
%systemd_postun_with_restart cron.target

if [ $1 -eq 0 ] ; then
  update-alternatives --remove %{name} %{_bindir}/crontab.%{name}
fi

%prep
%setup -q

%build
# Don't use the %%configure macro as this is not an autotool script
./configure \
  --with-version="%{version}" \
  --prefix="%{_prefix}" \
  --bindir="%{_bindir}" \
  --datadir="%{_datadir}" \
  --libdir="%{_libdir}" \
  --libexecdir="%{_libexecdir}" \
  --mandir="%{_mandir}" \
  --docdir="%{_docdir}" \
  --unitdir="%{_unitdir}" \
  --generatordir="%{_systemdgeneratordir}" \
  --sysusersdir="%{_sysusersdir}" \
  --enable-runparts=no \
  --enable-minutely=yes \
  --enable-quarterly=yes \
  --enable-semi_annually=yes \
  --enable-boot=no

# Compile
%make_build

%install
%make_install

# Preparing /var/spool/cron using tmpfiles.d
mkdir -p "${RPM_BUILD_ROOT}%{_tmpfilesdir}"
printf "%s\n" "d %{_localstatedir}/spool/cron 1730 root crontab" >> "${RPM_BUILD_ROOT}%{_tmpfilesdir}/systemd-cron.conf"

# The "crontab" group for /var/spool/cron
printf "%s\n" "g crontab - -" >> "${RPM_BUILD_ROOT}%{_sysusersdir}/systemd-cron.conf"

# systemd preset as required by fedora
mkdir -p "${RPM_BUILD_ROOT}%{_presetdir}"
printf "%s\n" "enable cron.target" > "${RPM_BUILD_ROOT}%{_presetdir}/50-systemd-cron.preset"

# Conflict with other cron services to avoid 2 cron implementations from running
OtherCronServices="crond.service"
mkdir -p "${RPM_BUILD_ROOT}%{_unitdir}/cron.target.d"
printf "%s\n%s\n" "[Unit]" "Conflicts=${OtherCronServices}" > "${RPM_BUILD_ROOT}%{_unitdir}/cron.target.d/crond-conflict.conf"

# Alternative %%{_bindir}/crontab
mv "${RPM_BUILD_ROOT}%{_bindir}/crontab" "${RPM_BUILD_ROOT}%{_bindir}/crontab.%{name}"
touch "${RPM_BUILD_ROOT}%{_bindir}/crontab"

# A required directory
mkdir -p "${RPM_BUILD_ROOT}%{_sysconfdir}/cron.d"

%files
%license LICENSE
%doc README.md CHANGELOG

%dir %{_sysconfdir}/cron.d
%dir %{_libexecdir}/systemd-cron
%ghost %{_bindir}/crontab

%{_bindir}/crontab.%{name}
%{_libexecdir}/systemd-cron/mail_for_job
%{_libexecdir}/systemd-cron/boot_delay
%{_libexecdir}/systemd-cron/remove_stale_stamps
%attr(2755, root, crontab) %{_libexecdir}/systemd-cron/crontab_setgid
%{_systemdgeneratordir}/systemd-crontab-generator

%{_presetdir}/50-systemd-cron.preset
%{_unitdir}/cron.target
%{_unitdir}/cron-update.path
%{_unitdir}/cron-update.service
%{_unitdir}/cron-mail@.service
%{_unitdir}/systemd-cron-cleaner.service
%{_unitdir}/systemd-cron-cleaner.timer

%{_sysusersdir}/systemd-cron.conf
%{_tmpfilesdir}/systemd-cron.conf

%{_mandir}/man1/crontab.*
%{_mandir}/man5/crontab.*
%{_mandir}/man5/anacrontab.*
%{_mandir}/man7/systemd.cron.*
%{_mandir}/man8/systemd-crontab-generator.*

%changelog
%autochangelog
```