Mailinglist Archive: opensuse-packaging (116 mails)

< Previous Next >
Re: [opensuse-packaging] Packages enabling their systemd services at their own


On 12/12/17 08:36, Stefan Seyfried wrote:
Am 11.12.2017 um 22:21 schrieb Dominique Leuenberger / DimStar:
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)

Yes. It needs to be enabled always, or it will not work.
If is is not enabled, then it cannot be started on-demand by whatever
bluetooth applet is installed.

Kubic is this KDE live cd? I think they want to have bluetooth working.

Ah, i see. Kubic is a container.

I would not expect bluez being installed at all in such a
hipster-playground ;-)

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.

Yes. But bluez will not work as intended if it is not enabled. (You and
Frederic found this out in boo#796671 and opted against
presets-branding-openSUSE, because it is not good enough).
So the user selects another branding package and -- boom, bluez does not
work anymore.

Every other service shipped in openSUSE / SLE is following these
guidelines, why should bluez get an exception? You just need to make
sure the relevant distro's have the correct services in there branding
packages.

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'

But it does not make any sense to ever have this disabled if the bluez
package is installed. Unless the admin does not want to have it (but
then "rpm -e" is probably what she wants to do).

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?

No, because it does not apply to this package. There is no choice if we
want this enabled or not.

Unless we deliberately choose to "we don't want it to work".

Anyway, I removed the Requires(post): systemd and substituted it with
coreutils.


Any package enabling systemd services in %post should be rejected by the
openSUSE review team, it seems we have missed some packages including
bluez in the past.

--

Simon Lees (Simotek) http://simotek.net

Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

< Previous Next >
Follow Ups