Packages enabling their systemd services at their own

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Packages enabling their systemd services at their own

Thorsten Kukuk

Hi,

the official mechanismus to enable systemd services by default during
installation is, to use the systemd preset functionallty.

Unfortunately, some packages still enable their services at their own
by calling systemctl enable in the %post install section. This will
break in the future for fresh installations!

Why? We have a problem with dependencies for systemd, dependency loops
and packages, where we are not able to enable them with the preset
mechanism during initial installation. The reason is, that systemd with
it's many dependencies can only be installed late, but some packages
have to be installed earlier. The same is true for build dependencies.

If we require a PreReq systemd for all packages having systemd units,
we will end in a dependency loop nightmare. Instead, we decided, that
we will call a systemctl preset-all in the %posttrans of
systemd-presets-branding-* packages for fresh installations.

Since we do this only for fresh installations, old init scripts and
all the other stuff does not matter. But all packages, which do not
follow our policy using the preset-branding package, but enabling
themself in the post install section, will of course now fail.
Which also leads to a better package quality, since all the hacks
have now to be fixed!

  Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Dominique Leuenberger / DimStar
On Mon, 2017-12-11 at 16:14 +0100, Thorsten Kukuk wrote:
> Hi,
>
> the official mechanismus to enable systemd services by default during
> installation is, to use the systemd preset functionallty.
>
> Unfortunately, some packages still enable their services at their own
> by calling systemctl enable in the %post install section. This will
> break in the future for fresh installations!

Without looking into the spec files for 'reasons', here the list of
affected packages:

> find -maxdepth 2 -name '*.spec' -exec grep -l "systemctl.*enable" {}
\;
./NetworkManager/NetworkManager.spec
./bluez/bluez.spec
./openSUSE-release-tools/openSUSE-release-tools.spec
./cups/cups.spec
./ipmiutil/ipmiutil.spec
./ooRexx/ooRexx.spec
./syslog-ng/syslog-ng.spec
./openvpn/openvpn.spec
./postgresql/postgresql.spec
./pullin-bcm43xx-firmware/pullin-bcm43xx-firmware.spec
./sendmail/sendmail.spec
./yast2-installation/yast2-installation.spec
./systemd/systemd-mini.spec
./systemd/systemd.spec
./rsyslog/rsyslog.spec
./wicked/wicked.spec
./spice-vdagent/spice-vdagent.spec
./storage-fixup/storage-fixup.spec
./syslogd/syslogd.spec
./sysvinit/powerd.spec
./connman/connman.spec

Please everybody find your package and adjust accordingly.

Cheers,
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Thorsten Kukuk
On Mon, Dec 11, Dominique Leuenberger / DimStar wrote:

> On Mon, 2017-12-11 at 16:14 +0100, Thorsten Kukuk wrote:
> > Hi,
> >
> > the official mechanismus to enable systemd services by default during
> > installation is, to use the systemd preset functionallty.
> >
> > Unfortunately, some packages still enable their services at their own
> > by calling systemctl enable in the %post install section. This will
> > break in the future for fresh installations!
>
> Without looking into the spec files for 'reasons', here the list of
> affected packages:

Beside that the expression matches too much, luckily a lot of the
calls handle broken migration, which is not affected by the above
change.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Josef Reidinger-3
In reply to this post by Dominique Leuenberger / DimStar
V Mon, 11 Dec 2017 16:27:12 +0100
Dominique Leuenberger / DimStar <[hidden email]> napsáno:

> On Mon, 2017-12-11 at 16:14 +0100, Thorsten Kukuk wrote:
> > Hi,
> >
> > the official mechanismus to enable systemd services by default
> > during installation is, to use the systemd preset functionallty.
> >
> > Unfortunately, some packages still enable their services at their
> > own by calling systemctl enable in the %post install section. This
> > will break in the future for fresh installations!  
>
> Without looking into the spec files for 'reasons', here the list of
> affected packages:
>
> > find -maxdepth 2 -name '*.spec' -exec grep -l
> > "systemctl.*enable" {}  
> \;
> ./NetworkManager/NetworkManager.spec
> ./bluez/bluez.spec
> ./openSUSE-release-tools/openSUSE-release-tools.spec
> ./cups/cups.spec
> ./ipmiutil/ipmiutil.spec
> ./ooRexx/ooRexx.spec
> ./syslog-ng/syslog-ng.spec
> ./openvpn/openvpn.spec
> ./postgresql/postgresql.spec
> ./pullin-bcm43xx-firmware/pullin-bcm43xx-firmware.spec
> ./sendmail/sendmail.spec
> ./yast2-installation/yast2-installation.spec

regarding yast2-installation, it is in fact intentional as we have to
deal with upgrade scenario
https://github.com/yast/yast-installation/blob/master/package/yast2-installation.spec#L195
and we expect that systemd-presets. So from my POV it looks like we are
on safe side with installation.

Josef

> ./systemd/systemd-mini.spec
> ./systemd/systemd.spec
> ./rsyslog/rsyslog.spec
> ./wicked/wicked.spec
> ./spice-vdagent/spice-vdagent.spec
> ./storage-fixup/storage-fixup.spec
> ./syslogd/syslogd.spec
> ./sysvinit/powerd.spec
> ./connman/connman.spec
>
> Please everybody find your package and adjust accordingly.
>
> Cheers,
> Dominique

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Stefan Seyfried
In reply to this post by Thorsten Kukuk
Am 11.12.2017 um 16:14 schrieb Thorsten Kukuk:

>
> Hi,
>
> the official mechanismus to enable systemd services by default during
> installation is, to use the systemd preset functionallty.
>
> Unfortunately, some packages still enable their services at their own
> by calling systemctl enable in the %post install section. This will
> break in the future for fresh installations!
>
> Why? We have a problem with dependencies for systemd, dependency loops
> and packages, where we are not able to enable them with the preset
> mechanism during initial installation. The reason is, that systemd with
> it's many dependencies can only be installed late, but some packages
> have to be installed earlier. The same is true for build dependencies.
>
> If we require a PreReq systemd for all packages having systemd units,
> we will end in a dependency loop nightmare. Instead, we decided, that
> we will call a systemctl preset-all in the %posttrans of
> systemd-presets-branding-* packages for fresh installations.

So now I add "systemd-presets-branding-bluez" subpackage to bluez?
Any boilerplate code to use for this?
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Peter Czanik-2
On 12/11/2017 07:52 PM, Stefan Seyfried wrote:

> Am 11.12.2017 um 16:14 schrieb Thorsten Kukuk:
>> Hi,
>>
>> the official mechanismus to enable systemd services by default during
>> installation is, to use the systemd preset functionallty.
>>
>> Unfortunately, some packages still enable their services at their own
>> by calling systemctl enable in the %post install section. This will
>> break in the future for fresh installations!
>>
>> Why? We have a problem with dependencies for systemd, dependency loops
>> and packages, where we are not able to enable them with the preset
>> mechanism during initial installation. The reason is, that systemd with
>> it's many dependencies can only be installed late, but some packages
>> have to be installed earlier. The same is true for build dependencies.
>>
>> If we require a PreReq systemd for all packages having systemd units,
>> we will end in a dependency loop nightmare. Instead, we decided, that
>> we will call a systemctl preset-all in the %posttrans of
>> systemd-presets-branding-* packages for fresh installations.
> So now I add "systemd-presets-branding-bluez" subpackage to bluez?
> Any boilerplate code to use for this?

Yeah, same with syslog-ng. I can version update syslog-ng but can change
systemd support only if there is an example I can follow.

Thanks,

Peter

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Dominique Leuenberger / DimStar
In reply to this post by Stefan Seyfried
On Mon, 2017-12-11 at 19:52 +0100, Stefan Seyfried wrote:

> Am 11.12.2017 um 16:14 schrieb Thorsten Kukuk:
> >
> > Hi,
> >
> > the official mechanismus to enable systemd services by default
> > during
> > installation is, to use the systemd preset functionallty.
> >
> > Unfortunately, some packages still enable their services at their
> > own
> > by calling systemctl enable in the %post install section. This will
> > break in the future for fresh installations!
> >
> > Why? We have a problem with dependencies for systemd, dependency
> > loops
> > and packages, where we are not able to enable them with the preset
> > mechanism during initial installation. The reason is, that systemd
> > with
> > it's many dependencies can only be installed late, but some
> > packages
> > have to be installed earlier. The same is true for build
> > dependencies.
> >
> > If we require a PreReq systemd for all packages having systemd
> > units,
> > we will end in a dependency loop nightmare. Instead, we decided,
> > that
> > we will call a systemctl preset-all in the %posttrans of
> > systemd-presets-branding-* packages for fresh installations.
>
> So now I add "systemd-presets-branding-bluez" subpackage to bluez?
> Any boilerplate code to use for this?
No - if the service is meant to be enabled by default, it ought to be
listed in systemd-preset-branding-openSUSE (if enabled for openSUSE) or
the other, respective systemd-preset-branding-FOO packages (but no new
ones introduced per package)

Cheers
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Stefan Seyfried
Am 11.12.2017 um 20:14 schrieb Dominique Leuenberger / DimStar:

> On Mon, 2017-12-11 at 19:52 +0100, Stefan Seyfried wrote:
>> Am 11.12.2017 um 16:14 schrieb Thorsten Kukuk:
>>>
>>> Hi,
>>>
>>> the official mechanismus to enable systemd services by default
>>> during
>>> installation is, to use the systemd preset functionallty.
>>>
>>> Unfortunately, some packages still enable their services at their
>>> own
>>> by calling systemctl enable in the %post install section. This will
>>> break in the future for fresh installations!
>>>
>>> Why? We have a problem with dependencies for systemd, dependency
>>> loops
>>> and packages, where we are not able to enable them with the preset
>>> mechanism during initial installation. The reason is, that systemd
>>> with
>>> it's many dependencies can only be installed late, but some
>>> packages
>>> have to be installed earlier. The same is true for build
>>> dependencies.
>>>
>>> If we require a PreReq systemd for all packages having systemd
>>> units,
>>> we will end in a dependency loop nightmare. Instead, we decided,
>>> that
>>> we will call a systemctl preset-all in the %posttrans of
>>> systemd-presets-branding-* packages for fresh installations.
>>
>> So now I add "systemd-presets-branding-bluez" subpackage to bluez?
>> Any boilerplate code to use for this?
>
> No - if the service is meant to be enabled by default, it ought to be
> listed in systemd-preset-branding-openSUSE (if enabled for openSUSE) or
> the other, respective systemd-preset-branding-FOO packages (but no new
> ones introduced per package)

Ok, so I'll just add the preset to the main bluez package. A separate
branding package makes no sense since the service needs to be enabled
always anyway.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Dominique Leuenberger / DimStar
On Mon, 2017-12-11 at 21:40 +0100, Stefan Seyfried wrote:

> Am 11.12.2017 um 20:14 schrieb Dominique Leuenberger / DimStar:
> > On Mon, 2017-12-11 at 19:52 +0100, Stefan Seyfried wrote:
> > > Am 11.12.2017 um 16:14 schrieb Thorsten Kukuk:
> > > >
> > > > Hi,
> > > >
> > > > the official mechanismus to enable systemd services by default
> > > > during
> > > > installation is, to use the systemd preset functionallty.
> > > >
> > > > Unfortunately, some packages still enable their services at
> > > > their
> > > > own
> > > > by calling systemctl enable in the %post install section. This
> > > > will
> > > > break in the future for fresh installations!
> > > >
> > > > Why? We have a problem with dependencies for systemd,
> > > > dependency
> > > > loops
> > > > and packages, where we are not able to enable them with the
> > > > preset
> > > > mechanism during initial installation. The reason is, that
> > > > systemd
> > > > with
> > > > it's many dependencies can only be installed late, but some
> > > > packages
> > > > have to be installed earlier. The same is true for build
> > > > dependencies.
> > > >
> > > > If we require a PreReq systemd for all packages having systemd
> > > > units,
> > > > we will end in a dependency loop nightmare. Instead, we
> > > > decided,
> > > > that
> > > > we will call a systemctl preset-all in the %posttrans of
> > > > systemd-presets-branding-* packages for fresh installations.
> > >
> > > So now I add "systemd-presets-branding-bluez" subpackage to
> > > bluez?
> > > Any boilerplate code to use for this?
> >
> > No - if the service is meant to be enabled by default, it ought to
> > be
> > listed in systemd-preset-branding-openSUSE (if enabled for
> > openSUSE) or
> > the other, respective systemd-preset-branding-FOO packages (but no
> > new
> > ones introduced per package)
>
> Ok, so I'll just add the preset to the main bluez package. A separate
> branding package makes no sense since the service needs to be enabled
> always anyway.
Still no - the only valid mmethod is to modify systemd-preset-branding-
openSUSE

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

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

Cheers
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Thorsten Kukuk
In reply to this post by Stefan Seyfried
On Mon, Dec 11, Stefan Seyfried wrote:

> So now I add "systemd-presets-branding-bluez" subpackage to bluez?

No, see here:
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Stefan Seyfried
In reply to this post by Dominique Leuenberger / DimStar
Am 11.12.2017 um 21:43 schrieb Dominique Leuenberger / DimStar:

> On Mon, 2017-12-11 at 21:40 +0100, Stefan Seyfried wrote:
>> Am 11.12.2017 um 20:14 schrieb Dominique Leuenberger / DimStar:
>>> On Mon, 2017-12-11 at 19:52 +0100, Stefan Seyfried wrote:
>>>> Am 11.12.2017 um 16:14 schrieb Thorsten Kukuk:
>>>>>
>>>>> Hi,
>>>>>
>>>>> the official mechanismus to enable systemd services by default
>>>>> during
>>>>> installation is, to use the systemd preset functionallty.
>>>>>
>>>>> Unfortunately, some packages still enable their services at
>>>>> their
>>>>> own
>>>>> by calling systemctl enable in the %post install section. This
>>>>> will
>>>>> break in the future for fresh installations!
>>>>>
>>>>> Why? We have a problem with dependencies for systemd,
>>>>> dependency
>>>>> loops
>>>>> and packages, where we are not able to enable them with the
>>>>> preset
>>>>> mechanism during initial installation. The reason is, that
>>>>> systemd
>>>>> with
>>>>> it's many dependencies can only be installed late, but some
>>>>> packages
>>>>> have to be installed earlier. The same is true for build
>>>>> dependencies.
>>>>>
>>>>> If we require a PreReq systemd for all packages having systemd
>>>>> units,
>>>>> we will end in a dependency loop nightmare. Instead, we
>>>>> decided,
>>>>> that
>>>>> we will call a systemctl preset-all in the %posttrans of
>>>>> systemd-presets-branding-* packages for fresh installations.
>>>>
>>>> So now I add "systemd-presets-branding-bluez" subpackage to
>>>> bluez?
>>>> Any boilerplate code to use for this?
>>>
>>> No - if the service is meant to be enabled by default, it ought to
>>> be
>>> listed in systemd-preset-branding-openSUSE (if enabled for
>>> openSUSE) or
>>> the other, respective systemd-preset-branding-FOO packages (but no
>>> new
>>> ones introduced per package)
>>
>> Ok, so I'll just add the preset to the main bluez package. A separate
>> branding package makes no sense since the service needs to be enabled
>> always anyway.
>
> Still no - the only valid mmethod is to modify systemd-preset-branding-
> openSUSE

What about systemd-presets-branding-CAASP?

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

So who will fix this package?

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

> 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.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

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)

> > 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

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Stefan Seyfried
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.

>>> 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.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Andrei Borzenkov
12.12.2017 01:06, Stefan Seyfried пишет:

> 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.

Then it should not use [Install] section in the first place but install
static files under /usr/lib/systemd.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Simon Lees-3
In reply to this post by Stefan Seyfried


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


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Thorsten Kukuk
In reply to this post by Stefan Seyfried
On Mon, Dec 11, Stefan Seyfried wrote:

> What about systemd-presets-branding-CAASP?

If you would have looked at that package: it's uses
systemd-presets-branding-openSUSE as base and only contains
the changes needed for Kubic.

> > this is the ONLY package that should bring default states for services
> > for openSUSE.
>
> So who will fix this package?

There is nothing to fix, if you want that your package enables by
default, add the corresponding line and submit it.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Stefan Seyfried
In reply to this post by Andrei Borzenkov
On 12.12.2017 04:33, Andrei Borzenkov wrote:
>> Yes. It needs to be enabled always, or it will not work.
>
> Then it should not use [Install] section in the first place but install
> static files under /usr/lib/systemd.

Please argue with upstream.
I am not going to ship patches that upstream clearly disagrees with.

And there is always the admin who might want to have bluez installed but disable it for whatever reason.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packages enabling their systemd services at their own

Frederic Crozat-4
In reply to this post by Simon Lees-3
Le mardi 12 décembre 2017 à 14:48 +1030, Simon Lees a écrit :

>
> 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.

The reasoning for bluez, when I fixed it, was it is hardware related
and the systemd service will be started by a udev rules, automatically.
Unfortunately, to have this working, bluez systemd service needs to be
enabled first. But there is nothing really wrong in having it enabled
through preset.

--
Frederic Crozat
Enterprise Desktop Release Manager
SUSE

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]