Hi

On Wed, Apr 30, 2014 at 1:53 PM, Richard Shaw wrote:

On Wed, Apr 30, 2014 at 11:02 AM, Andrew Lutomirski wrote:

...

spacenavd

Right or wrong, the decision for enabling spacenavd by default is that

you would only install the package if you have one of these devices. Nothing should be pulling it in so it needs to be explicitly installed by the user.

The control for enabling the service by default should be part of the

preset to allow for admin customization easily and it would need FESCo to approve it. Maintainers cannot decide that for themselves according to the current Fedora policy

Rahul

On Wed, Apr 30, 2014 at 11:06 AM, Richard Shaw hobbes1069@gmail.com wrote:

On Wed, Apr 30, 2014 at 12:58 PM, Rahul Sundaram metherid@gmail.com wrote:

...

Hi On Wed, Apr 30, 2014 at 1:53 PM, Richard Shaw wrote:

...

On Wed, Apr 30, 2014 at 11:02 AM, Andrew Lutomirski wrote:

...

spacenavd

Right or wrong, the decision for enabling spacenavd by default is that you would only install the package if you have one of these devices. Nothing should be pulling it in so it needs to be explicitly installed by the user.

The control for enabling the service by default should be part of the preset to allow for admin customization easily and it would need FESCo to approve it. Maintainers cannot decide that for themselves according to the current Fedora policy

The guidelines still allow it as no direct configuration is required except for legacy serial devices, USB devices work fine out of the box.

I think you're right as long as no network sockets are involved.

Does that exception include UNIX sockets?

--Andy

On 04/30/14 at 09:02am, Andrew Lutomirski wrote:

Due to some confusion around how alternatives worked, I screwed up the list of packages here. I've updated it below. I'll give it a few more days before filing the actual bugs.

On Wed, Apr 23, 2014 at 4:59 PM, Andrew Lutomirski luto@mit.edu wrote:

...

Hi everyone-

This is a notice in accordance with the mass bug filing procedure.

A number of packages install systemd units and enable them automatically. They should not. Please update these packages to use the macroized scriptlet (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd).

If your package has an exception from FESCo permitting it to enable itself, please make sure that the service in question is listed in the appropriate preset file.

There is a general exception described here:

https://fedoraproject.org/wiki/Starting_services_by_default

If your package falls under the general exception, then it is possible that no change is required. Nevertheless, if you are relying on the exception, please make sure that your rpm scripts are sensible. The exception is:

In addition, any service which does not remain persistent on the system (aka, it "runs once then goes away"), does not listen to incoming connections during initialization, and does not require configuration to be functional may be enabled by default (but is not required to do so). An example of "runs once then goes away" service is iptables.

Given that this issue can affect Fedora 20 users who install your package as a dependency, these bugs should be fixed in Fedora 20 and Rawhide.

The tracker bug is here:

https://bugzilla.redhat.com/show_bug.cgi?id=1090684

I created it early because three of the bugs are pre-existing. Next week, I'll file bugs against the packages below. If you fix your package in the mean time, please let me know.

After three weeks, provenpackagers may step in and fix these issues.

abrt acpid aeolus-audrey-agent aeolus-configserver audit avahi bluez bootchart cherokee cloud-init deltacloud-core dmapd dnssec-trigger glusterfs gnome-initial-setup gpsd ipmiutil iptables kexec-tools

Cc kexec-tools list.

libstoragemgmt libvirt lttng-tools monit NetworkManager nfs-utils nss-pam-ldapd olpc-kbdshim olpc-powerd openct pcsc-lite qemu qpid-cpp rootfs-resize rpcbind sendmail soundmodem spacenavd subscription-manager supervisor systemd targetcli util-linux vdsm xen

--Andy _______________________________________________ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

On Wed, Jun 4, 2014 at 11:23 AM, Adam Williamson awilliam@redhat.com wrote:

On Wed, 2014-04-23 at 16:59 -0700, Andrew Lutomirski wrote:

...

Hi everyone-

This is a notice in accordance with the mass bug filing procedure.

A number of packages install systemd units and enable them automatically. They should not. Please update these packages to use the macroized scriptlet (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd).

If your package has an exception from FESCo permitting it to enable itself, please make sure that the service in question is listed in the appropriate preset file.

There is a general exception described here:

https://fedoraproject.org/wiki/Starting_services_by_default

If your package falls under the general exception, then it is possible that no change is required. Nevertheless, if you are relying on the exception, please make sure that your rpm scripts are sensible. The exception is:

In addition, any service which does not remain persistent on the system (aka, it "runs once then goes away"), does not listen to incoming connections during initialization, and does not require configuration to be functional may be enabled by default (but is not required to do so). An example of "runs once then goes away" service is iptables.

The page is somewhat confusingly written, but I don't believe you are reading it correctly.

I believe the page lists *two* general exceptions, not just the one you list. Both of the first two paragraphs are exceptions.

"If a service does not require configuration to be functional and does not listen on a network socket, it may be enabled by default (but is not required to do so)." is Exception #1

"In addition, any service which does not remain persistent on the system (aka, it "runs once then goes away"), does not listen to incoming connections during initialization, and does not require configuration to be functional may be enabled by default (but is not required to do so)." is Exception #2

I don't quite understand why these are written entirely separately, as so far as I can see, #1 entirely subsumes #2: anything excepted by #2 is also excepted by #1.

The big difference here with what you wrote in your email is that a service does not have to be one-shot to be covered by the exception. The only requirements to be excepted are i) 'does not listen on a network socket' / 'does not listen to incoming connections' (these seem basically the same to me) and ii) 'does not require configuration to be functional'.

I'm not sure if any of the packages you filed against are covered by Exception #1 (one which I'm fairly sure is covered is 'at', but I don't see that you actually filed a bug against it), but if I'm right, you might want to check.

I haven't explicitly checked either one, actually. What I did was to search for packages that enabled systemd units on their own instead of using the preset mechanism. For the most part, packages should be using presets to enable units. There are a couple packages I filed bugs against that do, indeed, qualify for the exception and have now migrated to using presets and are now in the default preset list.

That being said, there are certainly false positives here, due to my somewhat buggy script and the fact that I'm using data that's a bit stale. Is there a better way to download all the spec files than to grab them one at a time by scraping pkgs.fedoraproject.org's web interface? That's how I got my current copy, and I don't relish redoing it.

--Andy