According to https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29 one does something like:
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.
After discussion on IRC, there were two ideas floated.
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.
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...
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.
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?
As a packager, I really don't like having lots of changes just for EPEL.
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. ;)
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.
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.
+1 to put in EPEL-release
This is in epel-release now. ;)
to comment on this ticket.