#85 systemd service file naming --backwards compat
Closed: Fixed None Opened 12 years ago by toshio.

I thought we discussed symlinks for backwards compat in http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Naming

It looks like that never made it into the final draft though. Additionally, Viking-Ice brought up that the draft doesn't make clear that we want to follow upstream when they have systemd unit files as well as lead upstream when they don't already. Here's a reworked draft for that section:

=== Naming ===

Unit files for services have a naming scheme of foobar.service. When considering what basename to use, keep in mind that we'd like to use the same service names for software across distributions. We'd also like to ship the service files in the upstream packages. These desires create a few guides for naming a unit file:

  • Follow upstream if they're already distributing a .service file and it's not likely to conflict with other packages.
  • Look at packages in other distros or talk with the maintainers of those packages and upstream to try to come up with a common name.
  • Unit files should be named after the software implementation that they support as opposed to the generic type of software. So, a good name would be apache-httpd.service and bad names would be httpd.service or apache.service as there are multiple httpd implementations and multiple projects produced by the apache foundation.

For backwards compatibility you may also want to create a symlink from an older, name to the new name. In the above example, for instance, Fedora has always used httpd for the service. When creating the new apache-httpd.service file, also create a symlink named httpd.service that points at apache-httpd.service. Then end users that are used to using service httpd will have it continue to work.


btw, I probably won't be around for next week's meeting so I'll vote +1 on this now.

This was approved (+1:6, 0:0, -1:0)

Guidelines updated. Announcement text:

The systemd guidelines on naming unit files has been amended to tell packagers how to make compatibility symlinks for alternate service names should their service have had a different name in the past.

Login to comment on this ticket.

Metadata