EPEL [Extra Packages for Enterprise Linux] #2: How to handle systemd service activation defaults in 7
#2: How to handle systemd service activation defaults in EPEL7 ----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Keywords: | ----------------------------+---------------------------- See https://bugzilla.redhat.com/show_bug.cgi?id=1141609
According to https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptl... one does something like:
%post %systemd_post apache-httpd.service
%preun %systemd_preun apache-httpd.service
and some other package (systemd in Fedora, rhel-release in RHEL) contains a list of presets as to what services get enabled by default. Where do we want that? I don't think we want to update epel-release that often.
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by stahnma):
After discussion on IRC, there were two ideas floated.
1. We add a package and have EPEL-releaese depend on that. 2. We don't allow presets in EPEL - therefore packagers in EPEL would have to modify specs slightly.
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by stahnma):
I'm against a new package that epel-release depends upon.
Most people don't install epel-release with yum - at least in my experience. They wget it or rpm -Uvh http://blahblah. This means that dependency resolution may not be in play at this time. I think this would break workflows for testing, and validation. (I know it would break what we do at Puppet Labs).
As for the second option, I'd like to see the exact differences in a spec file to see how intrusive it is.
From an ecosystem perspective, I think having no presets for EPEL packages feels the most right, but my perspective could be pre-systemd and therefore out of date.
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by kevin):
So, looking at rhel7...
they ship a disable * preset after their specific package presets. This means if we simply do nothing, packages will all be disabled by default.
The changes in the spec file will be for every single package that wants to be enabled by default. It will have to replace the systemd_post macro above with a call to systemctl that enables the service.
Thinking about it, I wonder how often we would need to update a preset file. There can't be that many services in epel that we want to enable by default...
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by smooge):
At the 2014-10-03 meeting it was originally decided to make a epel- release-presets dependency package but it was shown this would break many workflows that expect epel-release to be a standalone package.
The EpSCO decided to rethink its vote, and table this issue to the 2014-10-10 meeting to get more input on this from channel.
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by orion):
It might not be that big of a deal to have it in epel-release. Even if users get the original file from elsewhere, a yum update will bring in the changes.
Any reason epel wouldn't just ship the presets file from Fedora? /usr/lib/systemd/system-preset/90-default.preset
As a packager, I *really* don't like having lots of changes just for EPEL.
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by kevin):
Yeah, I guess I am ok with just copying the fedora presets into epel- release and hoping we don't have to do much tweaking. ;)
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by bstinson):
I'm leaning toward +1 on adding it into epel-release, if it is widely announced and added to our docs. I wonder if there are those out there who simply deploy /etc/yum.repos.d/epel.repo rather than installing the epel- release package. We would need to let people know that we are adding functionality to epel-release.
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by jperrin):
I think having an epel-release-latest (or whatever name) metapackage removes most of the reasons for not having this in epel-release, but I would prefer to ship a reasonably sane list of defaults to keep from frequent random updates.
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by smooge):
+1 to put in EPEL-release
#2: How to handle systemd service activation defaults in EPEL7 -----------------------------+---------------------------- Reporter: orion | Owner: epel-wranglers Type: task | Status: closed Priority: major | Milestone: EPEL-7 Component: Policy problem | Version: Resolution: fixed | Keywords: -----------------------------+---------------------------- Changes (by kevin):
* resolution: => fixed * status: new => closed
Comment:
This is in epel-release now. ;)
epel-devel@lists.fedoraproject.org
-
EPEL