On Monday, July 11, 2011 17:43:41 Robert Schweikert wrote:
On 07/11/2011 11:00 AM, Andreas Jaeger wrote:
On Monday, July 11, 2011 16:50:57 Robert Schweikert wrote:
Understood, but I think at least some of the things that were proposed in this thread (although I am not sure we reached agreement on the preferred way) are not possible with the upstream proposal/implementation. Therefore, we should get a consensus on what we would prefer for openSUSE, if that preferred method is not possible in the current systemd implementation someone (possibly AJ) should take our concerns back upstream and get feedback.
Robert, in this case I missed something. I haven't seen anything that could not be done with the proposal from upstream - what I noticed were some open questions on how things get done and some alternative proposals where I did not see any advantages to the proposal.
My understanding is that the current upstream proposal/implementation handles the following case:
Multiple files in /etc/systemd/system.preset and /lib/systemd/system.preset each file would be parsed and the expected content is:
<snip> disable avahi-daemon.service enable cups.service disable * </snip>
From original post: http://lists.opensuse.org/opensuse-packaging/2011-07/msg00030.html
Then I made two proposal, although I more or less talked myself out of one of them in: http://lists.opensuse.org/opensuse-packaging/2011-07/msg00041.html
Proposal 1: Have one file per service with the content of enable/disable as appropriate, this makes a "disable all by default" policy tedious to implement.
You could do this with the proposal, no problem at all.
Proposal 2: Allow only 2 files, enable.preset and disable.preset each file would list the service that is being enabled or disabled.
That's how we could do it for openSUSE.
In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00043.html Patrick proposed that there would only be one file that lists all services and enables/disables them.
Proposal 3: Only one file (decide on name) is supported to enable/disable services
In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00053.html Christian proposed to have subdirectories named enable and disable and have empty files for each service in the enable or disable subdirectories.
I've forwarded this upstream and here's the reply: http://lists.freedesktop.org/archives/systemd-devel/2011-July/002907.html
Proposal 4: Create subdirectories enable/disable and have empty files as indicators whether a service should be enabled or disabled.
In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00055.html, Rob proposed a modified version of proposal 4.
In http://lists.opensuse.org/opensuse-packaging/2011-07/msg00063.html you AJ mention that systemd already has an enable directory, something that was not part of the original message posted. Based on the original message posted it appears to me that upstream modifications would be necessary for proposals 2, 3, 4, and 4a. However, the upstream implementation my be more flexible than is obvious from the original post.
IMHO we should find consensus for the preferred approach for openSUSE, (1, 2, 3, 4, or 4a) and then double check with the capabilities of the upstream proposal/implementation.
The upstream proposal is capable of doing everything we have discussed here, it's our choice how we use the framework they give us (proposals 1-3). Just 4 will not work - and those are proposals of a different implementation. It's a matter of taste which to prefer but the most important part why the upstream proposal is better is the following: If we have a file 02_enable_ssh, then an admin could just place a link to /dev/zero into the /etc/ preset directory and thus disable the 02_enable_ssh. Or override it with another content. This won't work with proposals 3 and 4. Robert, thanks for summarizing. My confusion might come from the fact that your proposals 1-3 are ways how to implement the upstream proposal and all work and 4 is an alternative proposal. I haven't seen a single use case - and that's what I had in mind - where the upstream proposal did not work at all, Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org