On 22/08/22 03:42PM, Mike Gilbert wrote:
> On Mon, Aug 22, 2022 at 2:10 PM Kenton Groombridge <conc...@gentoo.org> wrote:
> > What do you think?
> I am concerned that people will start mass filing bugs with
> suggestions without fully understanding them or without testing them
> thoroughly. Please don't do that.

I had thought of this potentially being a problem as well. I think with this in
mind perhaps it would be better to start with creating some documentation on
these systemd service options on the wiki, with notes geared for both users and
developers and when these options would/would not be a good idea to enable from
both perspectives. That way we can at least have some solid reference material
when addressing such bugs and providing guidance to developers to improve
systemd units in their packages.

> Also, ideally we would not need to provide systemd units at a distro
> level, and they would instead be provided by upstream. I certainly
> don't want to start installing distro-customized units where upstream
> already provides unit files.

I agree! Unfortunately I know of a very small amount of packages where hardened
systemd unit files are available but are not supported by upstream. One such
upstream includes a hardened systemd unit in their contrib/, but nevertheless it
is not installed by default for fear of breaking users' configurations.

I think the best way to address this is to have packages ship unit override
files instead of unit files themselves which enable these options. For example,
instead of Gentoo shipping a modified miniflux.service unit file, we can instead
install a file to /etc/system/miniflux.service.d/00gentoo.conf using the
existing systemd_install_serviced helper in systemd.eclass which enables these
options. Then, over time we can merge the modifications we make upstream if
upstream wants them. If not, we can continue to ship this override file without
changing how the original unit file gets installed.

Attachment: signature.asc
Description: PGP signature

Reply via email to