Re: [Guidelines Change] Change to the Packaging Guidelines
On 2012-08-07 10:35, Lennart Poettering wrote: On Tue, 07.08.12 13:31, Gary Gatling (gsgat...@ncsu.edu) wrote: Question about new systemd policy, If your package is under review, and it enables its service by default, do you add it to the bugzilla of the systemd package or would that be one of the things that needs to happen if it gets approved? To enable a service by default after package installation you need permission from FESCO. See the last line of: https://fedoraproject.org/wiki/Starting_services_by_default If you have permission from FESCO then I will add it to the default preset file in systemd and upload it to Fedora. What service are you specifically wondering about? I maintain a package (cloud-init) with several services that meet the runs once then goes away grant. Shall I file a bug against the systemd package or something else? Going forward, when a package adds or removes a systemd service that starts by default, what is the best way to coordinate the change with the preset policy maintainers? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On 2012-08-07, Lennart Poettering mzerq...@0pointer.de wrote:
For services which should not be restarted on upgrade (D-Bus, ...) we
should recommend this:
%postun
%{systemd_postun}
Current wiki text is:
%post
%{systemd_postun}
Is this s/postun/post/ intentional?
-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On 08/08/2012 06:10 AM, Petr Pisar wrote:
On 2012-08-07, Lennart Poettering mzerq...@0pointer.de wrote:
For services which should not be restarted on upgrade (D-Bus, ...) we
should recommend this:
%postun
%{systemd_postun}
Current wiki text is:
%post
%{systemd_postun}
Is this s/postun/post/ intentional?
Nope, thats a typo. Fixed, thanks.
~tom
==
Fedora Project
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Wed, 08.08.12 00:17, Garrett Holmstrom (gho...@fedoraproject.org) wrote: On 2012-08-07 10:35, Lennart Poettering wrote: On Tue, 07.08.12 13:31, Gary Gatling (gsgat...@ncsu.edu) wrote: Question about new systemd policy, If your package is under review, and it enables its service by default, do you add it to the bugzilla of the systemd package or would that be one of the things that needs to happen if it gets approved? To enable a service by default after package installation you need permission from FESCO. See the last line of: https://fedoraproject.org/wiki/Starting_services_by_default If you have permission from FESCO then I will add it to the default preset file in systemd and upload it to Fedora. What service are you specifically wondering about? I maintain a package (cloud-init) with several services that meet the runs once then goes away grant. Shall I file a bug against the systemd package or something else? Going forward, when a package adds or removes a systemd service that starts by default, what is the best way to coordinate the change with the preset policy maintainers? Cloud sounds like something that is network facing, so I guess you need the OK from FESCO if you want to run it by default. Note that I am not really the guy in charge here, that's FESCO. I will simply check the wiki page mentioned above, and copy things from there into the policy file. Note that there are actually three kinds of services in my eyes: 1) Services that are not enabled after package installation 2) Services that are enabled after package installation 3) Services that static, i.e. enabled unconditionally via symlinks in /usr/ rather than in /etc/, and are not supposed to be disabled, and can only be disabled via systemctl mask, but systemctl enable and systemctl disable does not really apply to them. Examples for #1 are things like Apache and MySQL I guess. Examples for #2 are things like Syslog, cron, SSH, ... Examples for #3 are things like PolicyKit, D-Bus, LVM, udisks, upower, ... And my suspicion is that the first sentence in https://fedoraproject.org/wiki/Starting_services_by_default which says If a service does not require configuration to be functional and is not network enabled, it may be enabled by default (but is not required to do so) should probably just mean that a service like this should be considered of type #3. Or with other words: I think quite strongly that a service that a service covered by this sentence is probably either one of type #1 or type #3, but not for #2. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Wed, Aug 8, 2012 at 5:57 PM, Lennart Poettering mzerq...@0pointer.de wrote: Note that there are actually three kinds of services in my eyes: 1) Services that are not enabled after package installation 2) Services that are enabled after package installation 3) Services that static, i.e. enabled unconditionally via symlinks in /usr/ rather than in /etc/, and are not supposed to be disabled, and can only be disabled via systemctl mask, but systemctl enable and systemctl disable does not really apply to them. Examples for #1 are things like Apache and MySQL I guess. Examples for #2 are things like Syslog, cron, SSH, ... Examples for #3 are things like PolicyKit, D-Bus, LVM, udisks, upower, ... And my suspicion is that the first sentence in https://fedoraproject.org/wiki/Starting_services_by_default which says If a service does not require configuration to be functional and is not network enabled, it may be enabled by default (but is not required to do so) should probably just mean that a service like this should be considered of type #3. I can see no reason for such a suspicion. The wording enabled by default automatically implies the ability to disable, doesn't it? Or with other words: I think quite strongly that a service that a service covered by this sentence is probably either one of type #1 or type #3, but not for #2. Why? If we want to move in the direction of a static system image separate from configuration (which was one of the reported motivations of /usr move), it should be possible to disable installed services in the configuration, not by package removal from the system image - or at least to disable anything that is not contained in the minimal platform installation. So, in particular, udisks2 and upower needs to be user-controlled. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Wed, Aug 8, 2012 at 8:57 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 08.08.12 00:17, Garrett Holmstrom (gho...@fedoraproject.org) wrote: I maintain a package (cloud-init) with several services that meet the runs once then goes away grant. Shall I file a bug against the systemd package or something else? Cloud sounds like something that is network facing, so I guess you need the OK from FESCO if you want to run it by default. Perhaps, but the second permission grant on that page carries no such restriction on network-enabled services: In addition, any service which does not remain persistent on the system (aka, it runs once then goes away) and does not require configuration to be functional may be enabled by default (but is not required to do so). Examples of runs once then goes away services include iptables and udev. As a set of oneshot services that run once at boot time and then terminate, cloud-init falls entirely within the bounds of that grant. But if the fact that it contacts the network makes you uneasy then I can ask FESCo to clarify their statement. Would that help? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Wed, 08.08.12 12:16, Garrett Holmstrom (gho...@fedoraproject.org) wrote: On Wed, Aug 8, 2012 at 8:57 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 08.08.12 00:17, Garrett Holmstrom (gho...@fedoraproject.org) wrote: I maintain a package (cloud-init) with several services that meet the runs once then goes away grant. Shall I file a bug against the systemd package or something else? Cloud sounds like something that is network facing, so I guess you need the OK from FESCO if you want to run it by default. Perhaps, but the second permission grant on that page carries no such restriction on network-enabled services: In addition, any service which does not remain persistent on the system (aka, it runs once then goes away) and does not require configuration to be functional may be enabled by default (but is not required to do so). Examples of runs once then goes away services include iptables and udev. As a set of oneshot services that run once at boot time and then terminate, cloud-init falls entirely within the bounds of that grant. But if the fact that it contacts the network makes you uneasy then I can ask FESCo to clarify their statement. Would that help? Yes, it is probably better to ask FESCO for a clarification for this. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On 07/08/12 17:41, Tom Callaway wrote: The systemd scriptlet guidelines have been updated for Fedora 18. In Fedora 18, the systemd package now provides helper macros to simplify %post, %preun, and %postun invocations in packages with systemd unit files. Additionally, these macros enable support for systemd profiles, a Fedora 18 Feature. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd The postun macros look wrong - as written the guidelines will result in a service that is not enabled by default not being restarted on upgrade which is a change from the current behaviour. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Tue, 07.08.12 17:55, Tom Hughes (t...@compton.nu) wrote: On 07/08/12 17:41, Tom Callaway wrote: The systemd scriptlet guidelines have been updated for Fedora 18. In Fedora 18, the systemd package now provides helper macros to simplify %post, %preun, and %postun invocations in packages with systemd unit files. Additionally, these macros enable support for systemd profiles, a Fedora 18 Feature. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd The postun macros look wrong - as written the guidelines will result in a service that is not enabled by default not being restarted on upgrade which is a change from the current behaviour. This looks mostly like a copy/paste mistake in the guidelines. The bit about If your service should be enabled by default, ... should actually read If your service should be restarted on upgrades, The big change here is that the policy whether to enable/disable a package by default after installation is no longer encoded in the package itself, but in the preset policy. Thus, mechanism and policy are cleanly separated, so that spins or even local administrators can employ their own schemes here. The Fedora default preset policy is now shipped in systemd.rpm (though I am happy to move it elsewhere, if people prefer). That basically means: if you are converting a service that shall be enabled by default to these new macros (i.e. a service listed on https://fedoraproject.org/wiki/Starting_services_by_default ) then please file a bug against systemd so that your service is added to the default preset policy, so that your service continues to be enabled by default after package installation. Spot, may I suggest adding a short paragraph about this to the guidelines? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On 08/07/2012 12:55 PM, Tom Hughes wrote: On 07/08/12 17:41, Tom Callaway wrote: The systemd scriptlet guidelines have been updated for Fedora 18. In Fedora 18, the systemd package now provides helper macros to simplify %post, %preun, and %postun invocations in packages with systemd unit files. Additionally, these macros enable support for systemd profiles, a Fedora 18 Feature. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd The postun macros look wrong - as written the guidelines will result in a service that is not enabled by default not being restarted on upgrade which is a change from the current behaviour. You're right. I've corrected this. Thanks! ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On 08/07/2012 01:07 PM, Lennart Poettering wrote: Spot, may I suggest adding a short paragraph about this to the guidelines? Of course, although even more valuable would be a diff from the existing guidelines. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On 07/08/12 18:11, Tom Callaway wrote: On 08/07/2012 12:55 PM, Tom Hughes wrote: The postun macros look wrong - as written the guidelines will result in a service that is not enabled by default not being restarted on upgrade which is a change from the current behaviour. You're right. I've corrected this. Thanks! Great. Is that new section on enabled by default right for F18 though? or is that supposed be handled via presets now? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Tue, 07.08.12 13:12, Tom Callaway (tcall...@redhat.com) wrote: On 08/07/2012 01:07 PM, Lennart Poettering wrote: Spot, may I suggest adding a short paragraph about this to the guidelines? Of course, although even more valuable would be a diff from the existing guidelines. Ok, what about this: If your package includes one or more systemd units that shall be enabled by default on package installation, they need to be listed in the default Fedora preset policy. [[http://pkgs.fedoraproject.org/cgit/systemd.git/plain/99-default.preset| The default fedora preset policy is shipped as part of systemd.rpm]]. If your unit files are missing from this list, please file a bug against the systemd package. Only services included in the [[https://fedoraproject.org/wiki/Starting_services_by_default|list of services that may be enabled by default on package installation]] are eligible for this. Or something like this? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Tue, Aug 7, 2012 at 1:18 PM, Lennart Poettering mzerq...@0pointer.dewrote: Ok, what about this: If your package includes one or more systemd units that shall be enabled by default on package installation, they need to be listed in the default Fedora preset policy. [[ http://pkgs.fedoraproject.org/cgit/systemd.git/plain/99-default.preset| The default fedora preset policy is shipped as part of systemd.rpm]]. If your unit files are missing from this list, please file a bug against the systemd package. Only services included in the [[https://fedoraproject.org/wiki/Starting_services_by_default|list of services that may be enabled by default on package installation]] are eligible for this. Or something like this? Question about new systemd policy, If your package is under review, and it enables its service by default, do you add it to the bugzilla of the systemd package or would that be one of the things that needs to happen if it gets approved? Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On 08/07/2012 01:29 PM, Lennart Poettering wrote:
For services which should not be restarted on upgrade (D-Bus, ...) we
should recommend this:
%postun
%{systemd_postun}
and for services which should be restarted on upgrade, we should
recommend this:
%postun
%{systemd_postun_with_restart} apache-httpd.service
And nobody should use systemctl enable in the spec snippets
anymore. That should be encoded in the preset policy (see other mail I
just sent).
Why would we ever not want to do a try-restart on an upgrade? This is
the current Fedora default.
~tom
==
Fedora Project
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Tue, 07.08.12 13:36, Tom Callaway (tcall...@redhat.com) wrote:
On 08/07/2012 01:29 PM, Lennart Poettering wrote:
For services which should not be restarted on upgrade (D-Bus, ...) we
should recommend this:
%postun
%{systemd_postun}
and for services which should be restarted on upgrade, we should
recommend this:
%postun
%{systemd_postun_with_restart} apache-httpd.service
And nobody should use systemctl enable in the spec snippets
anymore. That should be encoded in the preset policy (see other mail I
just sent).
Why would we ever not want to do a try-restart on an upgrade? This is
the current Fedora default.
Many services don't support being restarted. For example D-Bus and various
storage daemons.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Tue, 07.08.12 17:35, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 08/07/2012 05:18 PM, Lennart Poettering wrote: Ok, what about this: If your package includes one or more systemd units that shall be enabled by default on package installation, they need to be listed in the default Fedora preset policy. [[http://pkgs.fedoraproject.org/cgit/systemd.git/plain/99-default.preset| The default fedora preset policy is shipped as part of systemd.rpm]]. If your unit files are missing from this list, please file a bug against the systemd package. Only services included in the [[https://fedoraproject.org/wiki/Starting_services_by_default|list of services that may be enabled by default on package installation]] are eligible for this. Or something like this? It's only logical since Fesco is responsible for what is and why it's enabled by default they should be the once that have to add the relevant unit(s) to that default preset file and commit those changes ( with proper change log entries on why they granted that exception in the first place ) once the exception has been approved. Well, the default preset file is currently in systemd.rpm. I am of course happy if FESCO just goes ahead and commits any changes to the policy right-away, but other than that, I am happy to do this for FESCO. The only thing an packager should have to do is request for his unit(s) to be enabled by default then add the relevant macro to his spec file if fesco grants that. The macros should be used anyway. The FESCO permission and addition to the policy is something on top of this. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
Lennart Poettering (mzerq...@0pointer.de) said:
On Tue, 07.08.12 13:36, Tom Callaway (tcall...@redhat.com) wrote:
On 08/07/2012 01:29 PM, Lennart Poettering wrote:
For services which should not be restarted on upgrade (D-Bus, ...) we
should recommend this:
%postun
%{systemd_postun}
and for services which should be restarted on upgrade, we should
recommend this:
%postun
%{systemd_postun_with_restart} apache-httpd.service
And nobody should use systemctl enable in the spec snippets
anymore. That should be encoded in the preset policy (see other mail I
just sent).
Why would we ever not want to do a try-restart on an upgrade? This is
the current Fedora default.
Many services don't support being restarted. For example D-Bus and various
storage daemons.
It's even in the SysV guidelines that automatic condrestart may not be
appropriate for all services.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Tue, Aug 7, 2012 at 1:35 PM, Lennart Poettering mzerq...@0pointer.dewrote: To enable a service by default after package installation you need permission from FESCO. See the last line of: https://fedoraproject.org/wiki/Starting_services_by_default If you have permission from FESCO then I will add it to the default preset file in systemd and upload it to Fedora. What service are you specifically wondering about? Hi, I have a package review in bugzilla 827167, where I am doing it wrong. The service is called bublebeed. It controls a discrete GPU if its a Intel + Nvidia hybrid graphics system. You should only install this package if you have the correct hardware. Otherwise its kind of useless. So I'm going to try to fix my package and do it the correct way. So I guess I need to research getting permission from FESCO, after I fix the package. Thanks, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Tue, Aug 7, 2012 at 7:48 PM, Gary Gatling gsgat...@ncsu.edu wrote: On Tue, Aug 7, 2012 at 1:35 PM, Lennart Poettering mzerq...@0pointer.de wrote: To enable a service by default after package installation you need permission from FESCO. See the last line of: https://fedoraproject.org/wiki/Starting_services_by_default If you have permission from FESCO then I will add it to the default preset file in systemd and upload it to Fedora. What service are you specifically wondering about? Hi, I have a package review in bugzilla 827167, where I am doing it wrong. The service is called bublebeed. It controls a discrete GPU if its a Intel + Nvidia hybrid graphics system. You should only install this package if you have the correct hardware. Otherwise its kind of useless. So I'm going to try to fix my package and do it the correct way. So I guess I need to research getting permission from FESCO, after I fix the package. Note that a package doesn't necessarily have to be explicitly listed on the wiki page to be enabled by default, the page starts with two general rules, the first being the most general one: If a service does not require configuration to be functional and is not network enabled, it may be enabled by default (but is not required to do so). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Tue, Aug 7, 2012 at 2:20 PM, Miloslav Trmač m...@volny.cz wrote: Note that a package doesn't necessarily have to be explicitly listed on the wiki page to be enabled by default, the page starts with two general rules, the first being the most general one: If a service does not require configuration to be functional and is not network enabled, it may be enabled by default (but is not required to do so). Oh, I see. Yeah. bumblebeed doesn't require configuration and its not a network service. Should have seen that. Thanks for the clarification. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
