Fedora 18 changes the way how to work with services in spec files. It introduces new macros - %systemd_post, %systemd_preun and %systemd_postun; which replace scriptlets from Fedora 17 and older (see https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd). This change relates to new feature systemd/Presets (see http://fedoraproject.org/wiki/Features/PackagePresets) which removes the service policy from the packaging scripts and places it to "preset" files which can be different for the various spins and even for individual systems.
https://fedoraproject.org/wiki/Starting_services_by_default : autofs avahi coda-client dbus firewalld ifplugd iscsi-initiator-utils isdn4k-utils nfs-utils NetworkManager ocfs2-tools openssh-server rpcbind rp-pppoe rsyslog sysklogd xinetd /usr/lib/systemd/system-preset/99-default.preset : enable avahi-daemon.* enable gdm.service disable *
I want dispute the > Fedora 18 changes the way how to work with services in spec files. According my records, guidelines have been changed on August, 7th and F18 has been branched a day after. In my opinion, this change should apply to F19. I think changing script-lets in distribution frozen for stabilization is contradiction.
Is there any chance to get these macros into F17 too? I don't want to add more conditional builds and want one spec file for all releases, if possible. Otherwise can you reopen this bug in time when these macros will be available in all supported releases of Fedora?
> Is there any chance to get these macros into F17 too? I don't want to add > more conditional builds and want one spec file for all releases, if possible. I'm confirming that this *requirement* brings little or no value while putting additional burden to the packagers until all living Fedora branches provide these macros.
Whether that macros will be back-ported to F17- or not, the following piece of code should work well in all branches: %preun %if 0%{?systemd_preun:1} %systemd_preun rarpd.service %else if [ $1 = 0 ]; then /bin/systemctl --no-reload disable rarpd.service >/dev/null 2>&1 || : /bin/systemctl stop rarpd.service >/dev/null 2>&1 || : fi %endif ... and similar for %post and %postun. So packagers can have the same spec file in all branches.
I was asked to note that the %systemd_requires macro should not be used. The FPC approved the new systemd macros with the specific exception of that one. Working on having it removed from the package as well as it seems to have caused some confusion.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.