Mailinglist Archive: opensuse-packaging (134 mails)

[Andreas Jaeger <aj@xxxxxxxx>]

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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx