On Wednesday, July 06, 2011 13:27:16 Patrick Shanahan wrote:

* Andreas Jaeger [07-06-11 03:03]:

...

I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers,

Andreas

---------- Forwarded Message ----------

Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering To: systemd Mailing List

...

...

Anyway, this of course requires some buy-in from the distributions, so I'd like to ask the distro maintainers for comments on this. Do you think this would be useful to you? Any other suggestions, ideas?

Note that even if we implement this in systemd (which is very likely) it is of course up to the distros to make use of this. If they still want to enable (or disable) all services unconditionally then they can still do so in RPM scrips, but we'd of course greatly welcome if distros would support this new scheme instead of cooking their own.

sounds like a plan

since it will be default-enabled, a provision should exist to include a preset default-disabled so it is not necessary to singularly disable every unwanted service that is installed.

disable all enable 1, 2, 3

Yeah, that works (with a different syntax ;). I expect that openSUSE to ship a default that reflects what we do today: - by default disable everything - enable a few services The proposal supports this. The nice thing is that it also allows different profiles, e.g. a server or a desktop profile - or a paranoia one ;) - that can be implemented via separate packages without touching the service packages itself, 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

On Wed, 6 Jul 2011 20:09, Christian Boltz wrote:

Hello,

on Mittwoch, 6. Juli 2011, Yamaban wrote:

...

On Wed, 6 Jul 2011 09:00, Andreas Jaeger wrote:

...

- systemd would not ship any preset file by default (and probably not even the directory), this is left to distributions.

...

To NOT include the preset dir (/lib/systemd/system.preset/) in the systemd-package is not a good decision in terms of foresight.

If you include the dir in systemd, you make it clear where it belongs to, and make sure it has the needed ownership and rights.

ACK, but...

...

In rpm-terms: mark it as config-dir.

NACK on marking it as config dir. /lib/systemd/system.preset is only filled by rpms, nothing should be manually changed there.

For manual changes/overrides, there will be /etc/systemd/system.preset/ (this directory should also be created by the systemd package).

Regards,

Christian Boltz

Thanks for the insight. What I (really) meant was to include BOTH dirs in the systemd package, the /lib/... as 'normal' dir and the /etc/... as 'config' dir. That way a service / daemon can include 'just' the /lib/systemd/system.preset/<name> file without the no-owner-for-directory hassle in the package management (see thread on this group this month). The thought behind is: How can we make the systemd package as usefull and easy to handle, use, and maintain as possible. Let's spare us all the hassle / security issues we've already had with the System5-init as much as possible. The clearer we define systemd now, the easier will be the next 20 years of maintenance of systemd itself and the files a service / daemon needs. Thanks, Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Wednesday, July 06, 2011 21:28:21 Robert Schweikert wrote:

<snip>

...

More specifically this is how it should work: We'd have a directory /lib/systemd/system.preset/. By default it would be empty (or not even exist), which for simplicity reasons would mean "enable everything installed" (i.e. the Debian policy). Then, if distros or spins want to change what is enabled by default, they'd drop in a file (or multiple, which might be useful for a desktop spin and a graphical design spin where the latter is a superset of the former) in that directory. The file would be a trivial text file with lines like this:

<snip> disable avahi-daemon.service enable cups.service disable * </snip>

Then, we'd add a new command to "systemctl" called "systemctl preset". It would be equivalent to a "systemctl enable" if the unit file passed is listed in any of the preset files on lines prefixed with "enable", or be like a "systemctl disable" if it is listed with a prefix of "disable". Simple globbing would be supported. If no entry is found "systemctl preset" would be synonymous with "systemctl enable".

Generally I think this is a good idea, although the approach appears a bit simplistic and stuffing everything into one directory is probably not so great either.

In another response there was mention of /etc/systemd to separate configurations, that's a step in the right direction. Still there would need to be some precedence rules if there are multiple files. For example if I have 3 files, a.preset, b.preset, and c.preset as follows:

The order is alphabetically if there are several files, like udev does it today. So, I guess we add a 99.openSUSE rule that does "disable *" as the last one.

a.preset enable cups.service

b.preset disable cups.service

c.preset enable cups.service

Is the service now enabled or disabled, probably depends on the processing order. But alpha sorting would not be a good choice as that is obviously locale specific and then has the potential of changing the behavior of the system as far as running services is concerned just based on the locale, that's just not correct.

The locale systemd runs under is the C locale - and if you use numbers, everything is fine.

It appears that maybe having files named for services would be more intuitive to users, therefore one would have a cups.preset file as follows:

cups.preset enable

to enable or

cups.preset disable

to disable the service. Yes, from an implementation point of view this is more cumbersome and potentially requires the reading of many more files. Also this would make implementation of a default rule such as "disable all" more difficult.

I don't understand what you're getting at.

Another option would be to consider only two files, enable.preset and disable.preset. Enabled services are listed in enable.preset, disabled services are listed in disable.preset. The default rule can then be that enable wins, i.e. if a service is listed in both files it is enabled. Using the approach with only 2 files would allow easy implementation of default rules such as "disable all" an precedence is easy to explain. One could also consider making the precedence configurable, but then we'll get back into one distributions precedence is this and another's is that, which is not desirable.

This is exactly distribution specific files. This will allow a vendor to ship different preset rpm packges (that might conflict with each other), e.g. a server one, a desktop one, a paranoia one... The precedence is defined, 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

Hello, on Freitag, 8. Juli 2011, Robert Schweikert wrote:

OK, did not know that and was not part of the original message. Well, using numbers works, still leaves one parsing all files for a specific service and then figuring out which one is processed last and wins. Allowing only one file or enable/disable pair of files makes that task a lot easier.

There is another way that can even avoid reading file contents ;-) I propose to use two subdirectories "enabled" and "disabled", and then just put empty files there, with filename = service name. In other words: "touch disabled/cupsd.service" would mean cupsd is disabled by default, and "touch enabled/sshd.service" would enable sshd by default. The default behaviour (if there is no service-specific default set) could also stored with this method - just "touch enabled/DEFAULT". Advantages of this method: - you know exactly which files you have to check for a service - just check for disabled/$service_name and enabled/$service_name. - getting a full list for all services should be fast because you only have to read the content of two directories, not any file content. - easy to handle in packaging - you'll never have any problems with invalid syntax inside the config files ;-)) - you'll never get headache with file ordering The only thing my proposal doesn't solve is if enabled or disabled should win if both exist - but this issue exists in all proposals I've seen until now. It's probably something that should be (or already is) hardcoded in systemd. Regards, Christian Boltz -- What are you doing?!? The message is over, GO AWAY! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 8 July 2011 20:16, Rob OpenSuSE wrote:

On 8 July 2011 18:31, Christian Boltz wrote:

...

on Freitag, 8. Juli 2011, Robert Schweikert wrote:

...

Advantages of this method: - you know exactly which files you have to check for a service - just  check for disabled/$service_name and enabled/$service_name.

That seems much neater!  I prefer that suggestion to all the others so far. If it's a flag, then let's treat it like one, no parsing, no syntax errors etc

...

The only thing my proposal doesn't solve is if enabled or disabled should win if both exist

Outlaw it!  Simply mv {en,dis}abled/foo.service and mv {dis,en}abled/foo.service, and rm a redundant option that agrees with the system default.

Actually even simpler would be to say "everyone has a package manager", so we don't need to worry about configurable distro policy. The default is simply service disabled. The package management, is responsible to enable service with flag on a distro with that policy on install. As a courtesly to sysadmin, package management documents an installed but disabled service. If there's flags for both enabled & disabled, then disabled wins, rm the enabled flag by Lennarts laziness principal "if that's broken then evenutally someone will notice and come along to fix it for us". That allows global enabledment by the unwise, with mv "disabled/*.service enabled". The wise can, temporarily disable by "mv enabled off-maintenance", then re-enable later by "mv off-maintenace enabled" again. It's easy to undo the actions of the unwise, by "mv enabled/*.service disabled" and then re-enable the wanted services/ "echo *abled/*.service" documents what's on & off. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 8 July 2011 21:04, Robert Schweikert wrote:

...

Outlaw it! Simply mv {en,dis}abled/foo.service and mv {dis,en}abled/foo.service, and rm a redundant option that agrees with the system default.

Not sure how you would set a default of disable all or enable all, create a file "all" or "*" in the enable or disable directory?

Packages can simply look for a "install-defaults-on" flag which is at the directory level NOT at file *.service level. services/ enabled/ foo.service bar.service disabled/ boring.service tricky-to-configure.service install-defaults-on If you know disable is default, then removing (creating) that flag, allows local change to distro policy. With unlink & rename having filesystem guarantees, the only inconsistency is the configuration error of : enabled/foo.service disabled/foo.service Which one resolves by unlinking the enabled/foo.service on basis disabling is more principalled. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 11 July 2011 11:56, Andreas Jaeger wrote:

On Friday, July 08, 2011 19:31:07 Christian Boltz wrote:

You could do exactly the same with the other proposal.

Just have a single file for each service 01_ssh.service with enable/disable ssh in it - and the 99_default file.

...

The only thing my proposal doesn't solve is if enabled or disabled should win if both exist - but this issue exists in all proposals I've seen until now. It's probably something that should be (or already is) hardcoded in systemd.

Much friendly to the sysadmin to work with list of files in directory, not look inside file. Means less code & more efficient GUI program to "echo */*.service | sort". Disabled is logical choice, it's far safer to have a "failed service" than one accidentally running, if something is broke it gets fixed; something running that should not be, or a service accidentally started can have disproportionately expensive consequences. Files have same issue as 2 directory flag solution, one can write enabled & disabled in the file, so it's same configuration error as having directory entries (zero byte files) in both enabled & disabled. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 07/11/2011 10:09 AM, Andreas Jaeger wrote:

On Monday, July 11, 2011 15:59:03 Rob OpenSuSE wrote:

...

On 11 July 2011 11:56, Andreas Jaeger wrote:

...

On Friday, July 08, 2011 19:31:07 Christian Boltz wrote:

You could do exactly the same with the other proposal.

Just have a single file for each service 01_ssh.service with enable/disable ssh in it - and the 99_default file.

...

The only thing my proposal doesn't solve is if enabled or disabled should win if both exist - but this issue exists in all proposals I've seen until now. It's probably something that should be (or already is) hardcoded in systemd.

Much friendly to the sysadmin to work with list of files in directory, not look inside file. Means less code& more efficient GUI program to "echo */*.service | sort".

We're not talking about the sysadmin in the proposal (at least not directly)!

The proposal is for distributors how they will configure the system - to define which services are run by default and which not.

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 -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 11 July 2011 16:00, 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.

So, this I missed a bit, could you point out, what I missed, please (a URL to the archive with a comment would be fine)?

Sure earlier on in this thread... On 6 July 2011 12:38, Andreas Jaeger wrote:

On Wednesday, July 06, 2011 13:27:16 Patrick Shanahan wrote:

...

* Andreas Jaeger [07-06-11 03:03]:

...

I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers,

Andreas

---------- Forwarded Message ----------

Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering To: systemd Mailing List

...

...

Anyway, this of course requires some buy-in from the distributions, so I'd like to ask the distro maintainers for comments on this. Do you think this would be useful to you? Any other suggestions, ideas?

Note that even if we implement this in systemd (which is very likely) it is of course up to the distros to make use of this. If they still want to enable (or disable) all services unconditionally then they can still do so in RPM scrips, but we'd of course greatly welcome if distros would support this new scheme instead of cooking their own.

sounds like a plan

since it will be default-enabled, a provision should exist to include a preset default-disabled so it is not necessary to singularly disable every unwanted service that is installed.

disable all enable 1, 2, 3

Yeah, that works (with a different syntax ;).

I expect that openSUSE to ship a default that reflects what we do today: - by default disable everything - enable a few services

The proposal supports this. The nice thing is that it also allows different profiles, e.g. a server or a desktop profile - or a paranoia one ;) - that can be implemented via separate packages without touching the service packages itself,

That's messages previous in thread. 1) Feedback is asked for 2) Suggestion about text file contents with lines like "enable, disable" which create ordering problems. Avoiding that file parsing is neater and simpler, and rules out the questions asked. The "preset directory" concept is a good one. Hope that answers the question, you just asked me. I saw a simple but powerful suggestion that was better than the others. May be they prefer global enable default, but so long as it's easy to ship with disable default, no problem. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 11 July 2011 16:21, Andreas Jaeger wrote:

On Monday, July 11, 2011 17:15:20 Rob OpenSuSE wrote:

...

2) Suggestion about text file contents with lines like "enable, disable" which create ordering problems.

I don't see an ordering problem! Where do you see it?

People were asking questions like, what supercedes what if in file it's both enabled & disabled etc etc. The discussion looked more and more compicated to me, with some intricate proposals with many levels, or involving file naming conventions; even character set was considered, hence the "numbering" rather reminscient (ironically) of S10*, S20* & K90*, K80* examples in current /etc/init.d script links.. Either single file to check, or simple flags in 2 directories are both workable solutions. I realise if it were formal proposal, that a better presented worked out alternative would have been better. It was simply that I saw "beauty" in minimalist simplicity of making flags flags and the useability of such is very obvious to me. What would be horrible is many files, with flags in them like "enable", "disable". The inherent disadvantage with flags in packages is they then own their defaults, where they differ from distro "global" policy for some good reason. It may not matter, but there's not some central point with overview of which package does what, unless it's collated. They can however respect the site global policy by checking for prescence of local "global" over-ride flag, which could for example in openSUSE, SLE & Fedora be set by default to enforce the "all off" on install policy quite neatly. I just hope the final solution, has simpler rules easy to understand that are simple to remember, to avoid confusion or mandate use of GUI for overview. Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

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. Proposal 2: Allow only 2 files, enable.preset and disable.preset each file would list the service that is being enabled or disabled. 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. 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. Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 11 July 2011 15:09, Andreas Jaeger wrote:

We're not talking about the sysadmin in the proposal (at least not directly)!

The proposal is for distributors how they will configure the system - to define which services are run by default and which not.

The sysadmin will configure the system starting from the preconfiguration with systemctl. No need for the admin to learn about all this magic ;)

Fine but why complicate things, does someone really want to write a file parser? If you just have Disable as default policy, and then have flag set by distro to make "enable" a global default, that's it done. It DOES matter to the sysadmin, because if it's : service-default-install-policy enabled disabled Once at a large installation, will going to want to change the policy most likely; for example if the admin have 2 distro's they'll want the SAME defaults! So the simpler you make it the better alround. What can be more efficient than 0 byte files for a flag in 2 directories? A runninug system does indeed have systctl etc, but I thought the was Distro policy, package polocy with some over-ride. It may seem different, to the running system, but it'd be likely quite easy to write scripts to do the systemctl to match the site policy, when one desired, if you define it nicely. Filesystem state has advantages, because there's good tools to replicate it. Regards Rob -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Mon, 11 Jul 2011 17:10, Andreas Jaeger wrote:

On Monday, July 11, 2011 16:56:39 Rob OpenSuSE wrote:

...

On 11 July 2011 15:09, Andreas Jaeger wrote:

...

We're not talking about the sysadmin in the proposal (at least not directly)!

The proposal is for distributors how they will configure the system - to define which services are run by default and which not.

The sysadmin will configure the system starting from the preconfiguration with systemctl. No need for the admin to learn about all this magic ;)

Fine but why complicate things, does someone really want to write a file parser? If you just have Disable as default policy, and then have flag set by distro to make "enable" a global default, that's it done.

I assume that openSUSE will have "disable" as default. Debian might have "Enable" as default.

...

It DOES matter to the sysadmin, because if it's :

service-default-install-policy enabled disabled

Once at a large installation, will going to want to change the policy most likely; for example if the admin have 2 distro's they'll want the SAME defaults! So the simpler you make it the better alround.

...

From the original post: If an admin wants to manually change "enable-by-default" to "disable-by-default" (or vice versa) he could just drop his own file with "disable *" (or "enable *") into /etc/systemd/system.preset/ and override the vendor/spin settings.

So, this is possible - as easy as what you describe.

The difference is treating all options the same and allow pattern matching - vs. having an explicit file for defaults. It also means that all settings will be in one directory.

...

What can be more efficient than 0 byte files for a flag in 2 directories?

A runninug system does indeed have systctl etc, but I thought the was Distro policy, package polocy with some over-ride. It may seem different, to the running system, but it'd be likely quite easy to write scripts to do the systemctl to match the site policy, when one desired, if you define it nicely.

I don't understand what you're saying in the above paragraph, could you rephrase it, please?

...

Filesystem state has advantages, because there's good tools to replicate it.

The original proposal does it as well - doesn't it?

Not that easily. - A file with content has a syntax, charset, parsing. - A 'file' (zero-length) in a directory is just that. No syntax, parsing, charset (fixed to utf8 of the fs). Also do not underestimate trouble shooting of crashed systems. How does a Fedora user held his Debian friend without having a running reference system, or extened knowlege? In the case of zero-length-file-in-directory with added (en|dis)abled/DEFAULT - file the learning curve is nearly flat. Maybe the acceptance for systemd will get a rise with a "Oh, it's simple!" system of en- and disableing services, even without deeper knowledge of the 'new' init-system. For me at least a simple, easy to check config is a convincing argument for the change to systemd as 'my' init-system. Just as a two digit number plus a underscore before the name and you get even a simple and easy method of start order. Well, that's ust me, but I'm sure, for the user that seldom (only in cases of trouble) look under the hood/bonnet of his system a distro-independend, uniform, with just a glance understandable system of configuration is gold, and a argument for a system / distro. Ask yourself: would your grandmother/mother understood this system? Is it intuitive? How does it handle a filesystem-crash? Yes, AJ, you are under the hood daily. But most users not. This isn't meant personally, but it is a case of perspective. User versus Admin. A flat learning curve is a benefit for both, yes, but is esential for the user and thus the distro acceptance. A tip beyond: Would a simple README file in the level of the enable and disable directory to much to ask for, at least during the change-over from System-V to systemd. As content just a few lines about systemctl and it's most basic usage. To spare our self some support questions and give adopters a little extra help on the way. Cheers, Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Yamaban, if you as an admin like to enable or disable a service, just run systemctl enable some.service or systemct disable some.service And I expect we will teach chkconfig about systemd as well. The proposal is for the initial configuration - which services will be enabled or not. Currently this happesn inside packages and you have *zero* influence on it - and now we move it from packages to a meta-package. 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