Hi Jaromir

I need to take a deeper look at this since I'm already hitting violation in Fedora package guidelines so the spec files are not up to "spec" as ironic as that sounds and I need those to be up to specs before RHEL/CentOS 8 get's releases if we decided here at ISNIC to migrate to FRED ;)

I made sure when I handled the legacy sys-v migration to type systemd units in the distribution that no new legacy sys-v initscripts would be added and all major linux distributions should have made the systemd service manager the default init system by now and have deprecate legacy sysv initscripts (  with the exception of Debian due to it's Hurd/kFreeBSD part of it's community ) so by shipping an legacy initscript you ( read as an upstream or downstream packager ) have added direct ( unnecessary ) dependency on legacy sysv ( assuming you have packaged it correctly thou many packagers in Fedora just wrongly assumed certain components existed there indefinitely, which made in longer, harder and more painful to make changes on the core/baseOS level )  .

As an upstream you should ship only type unit files ( service,timers etc ) upstream and have those downstream that still use legacy sys v initscript maintain their own ( or keep it in a separated downstream package with correct dependency and requirements on legacy sysv init and cron component for cron jobs ).

That said I'm going to see if I cant find the time to review this is and make some pull request to fix this unless there is some specific reason why you ( as an upstream ) are still shipping legacy sysv initscripts.  ( thou the documentation [1] clearly mentions type systemd units as in  fred-rifd.service which btw is not being shipped with those components in the corp repository ).

Unfortunately there are still some downstream distribution shenanigans related to the core/basesOS setup like different package names and file and directory names ( like apache vs httpd or /etc/sysconfig which is RH specific nonsense ) which creates administrative/end users confusion and unnecessary load on upstream communities ( support/documentation etc ).

I'll keep going through this and testing this and will file pull-request for any issues I find and need fixing.

Regards

              Jóhann B.

1. https://fred.nic.cz/documentation/html/AdminManual/Configuration.html

Hi Jóhann,

we have a delay in publication of new version FRED-2.38 that is now in
the QA process. This new version will include packages for Fedora 29.
Last release candidate packages are available at the build server:
https://copr.fedorainfracloud.org/coprs/jtalir/fred/monitor/

If you want to test this release candidate packages, you can attach
this repository via:
$ dnf copr enable jtalir/fred

After this you can install Fred the same way as described on the
website. I still need to verify installation procedure so I'll be happy
if you will give me feedback how it worked.

Regards,
Jaromir

On Thu, 2019-01-03 at 10:40 +0000, Jóhann B. Guðmundsson wrote:

Greetings

Fedora 29 got officially released on 30 October last year but no 
packages have been built for that release [1] as of today hence 
installation on the distro fails with....

Failed to synchronize cache for repo 'fred', ignoring this repo.
No match for argument: fred-*

Any particular reason the components have not been built for the 29 
release of Fedora?

Regards

              Jóhann B.

1. http://archive.nic.cz/yum/fred/fedora/

_______________________________________________
fred-users mailing list
fred-users@lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users