#1483 Systemd: reword, clarify, clean up unit / dropin install locations
Merged by james. Opened by decathorpe.
Unknown source master

Download 1483.patch

I have tried to incorporate the suggestions from #1467 and made some small additional changes:

  • Just say that systemd unit files must be shipped in either %{_unitdir} or %{_userunitdir}, with them being the appropriate place for system services and user session services, respectively.
  • Drop what the macros expand to - information like that tends to get outdated (though admittedly, that is unlikely in this case).
  • Also drop "needed early in the boot process". This is just weird and out of context in this section, and doesn't explain anything unless you know about what dracut does internally (or I assume that this is the reason for it - I would say that I'm an experienced packager, but even I don't really know about this).

The resulting paragraph(s) are, I think, more straightforward to understand. And it's shorter! :)

Thanks, I think this is a good change. But I think we should still mention %config. Suggestion:

Unit files and drop-ins must be publicly readable and must not be marked with %config.

(Justification: this avoids two common mistakes in packaging. It's good to clarify this and have a place to point to during reviews and such. Systemd makes the contents of units files available over D-Bus so obviously making them non-publicly-readable is pointless, but people have strange ideas.)

Oh, and apparently the commit is missing the description. Did you put it only on the pull request page? Also add 'Resolves #1467' or such.

Thanks, I think this is a good change. But I think we should still mention %config. Suggestion:

Unit files and drop-ins must be publicly readable and must not be marked with %config.

By "publicly readable" I assume you mean the files should have mode 0644?

(Justification: this avoids two common mistakes in packaging. It's good to clarify this and have a place to point to during reviews and such. Systemd makes the contents of units files available over D-Bus so obviously making them non-publicly-readable is pointless, but people have strange ideas.)

:thumbsup:

Oh, and apparently the commit is missing the description. Did you put it only on the pull request page? Also add 'Resolves #1467' or such.

I usually try to avoid mixing-and-matching concepts like "this is a git commit history independent of where the git repo lives" and "this is a reference to a ticket on a website, where it's unclear if that reference will still be valid after pagure.io is gone".

No, sorry, but that makes no sense. It is almost always better to err on the side of too much information and too many links in a git commit. Links to pagure.io are useful now. Even if the website goes away, we might have a redirect. But even if there is no redirect, an informed reader can always figure out the ticket number and such from the link.

By "publicly readable" I assume you mean the files should have mode 0644?

By "publicly readable" I assume you mean the files should have mode 0644?

Yes. Yeah, it might be better to say that explicitly. People have put +x on unit files in the past.

rebased onto e2061d538bf377f4d642f061adf6abf105083f81

All feedback should be addressed now, PTAL.

I'd prefer to have the text from the first post in the PR request included in commit message. Otherwise LGTM.

rebased onto e2061d538bf377f4d642f061adf6abf105083f81

That's really overkill IMO ... but if it makes you happy? :shrug:

Thank you for the PR. There is already a %files section right below. With the changes, the part about %config got duplicated.

rebased onto e2061d538bf377f4d642f061adf6abf105083f81

Good catch. I dropped the separate section, it didn't appear to get referenced anywhere by the specified #fragment so I don't think anything else needs to be done.

LGTM ... a minor detail is that MUST (and MUST NOT) isn't in upper case, but that used to be true too and is also true in other parts of the file, so ¯\(ツ)

Yeah, this isn't even consistent in this one file I touched here (it uses both "must", "MUST", and "must"), so I just kept the emphasis and version that was in the paragraph I changed.

rebased onto a612abd62278c5a86aa112fa6ffa09fa94d27d7b

Is there still something I should fix here? From my point of view, I've addressed all comments (except the inconsistent emphasis on MUST / SHOULD, which would require touching the whole page instead of just two paragraphs).

rebased onto 85d017531225ea2fa3c0cc20aea493a3381be85d

Pull-Request has been merged by james

Metadata