3 Led
2019
3 Led
'19
16:01
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
On 1/3/19 11:29 AM, Jaromir Talir wrote:
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(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users