[opensuse-packaging] Packages enabling their systemd services at their own
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
V Mon, 11 Dec 2017 16:27:12 +0100
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
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-installa... 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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (8)
-
Andrei Borzenkov -
Dominique Leuenberger / DimStar -
Frederic Crozat -
Josef Reidinger -
Peter Czanik -
Simon Lees -
Stefan Seyfried -
Thorsten Kukuk