Mailinglist Archive: opensuse-packaging (116 mails)

< Previous Next >
Re: [opensuse-packaging] Packages enabling their systemd services at their own
On Mon, 2017-12-11 at 22:02 +0100, Stefan Seyfried wrote:


Still no - the only valid mmethod is to modify systemd-preset-
branding-
openSUSE

What about systemd-presets-branding-CAASP?

It depends: would you expect bluez to be enabled inside Kubic?
(probably not)

this is the ONLY package that should bring default states for
services
for openSUSE.

So who will fix this package?

You can create a submit request for your bits / pieces

And i need to require it from bluez? To make sure that users cannot
install What about systemd-presets-branding-CAASP?

Nope - it is, like any other 'branding' package, the DISTROs
responsibility to pull in its own branding package. This allows us to
use the same RPM (e.g. bluez.rpm) across distros and have various
flavors that can decide on their own about what servcies they want/need
to enable out of the box.

No service / package is allowed to set its 'default enabled value'
by
bypassing the distro while being part of the distro.

Ok, then it's mkdir -p / ln -s. I meand "systemctl enable
foo.service"
is not exactly rocket science after all.

Sure - and this split was never done for 'simplicity' reason, bot for
'central point of definition what service a default distro installation
gets enabled'

as said above: it should not be the RPM's scripts choice if a service
is enabled by default or not, this is a 'overall distro choice' (of
course in openSUSE the contributors are the ones to define the list in
the end...)

Does that clarify things?

Cheers
Dominique
< Previous Next >
Follow Ups