Re: [opensuse-packaging] Fwd: [systemd-devel] [RFC] Preset Files

On Monday, July 11, 2011 19:39:40 Rob OpenSuSE wrote:

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..

I expect that the default openSUSE installation will have just two or three files: 01_enable_openSUSE that contains something like enable nscd.service enable unscd.service enable avahi.service ... 02_enable_ssh (if configured at startup) enable ssh.service 99_default_openSUSE disable * So, that's really not that complicated in actual usage.

Either single file to check, or simple flags in 2 directories are both workable solutions.

I brought it upstream and here's their answer: http://lists.freedesktop.org/archives/systemd-devel/2011-July/002907.html

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.

Read the response above, they have thought of this. If you feel strongly about this, then please continue discussing it on the systemd-devel mailing list.

What would be horrible is many files, with flags in them like "enable", "disable".

We won't have that.

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.

We don't want flags in packages - we want a single "openSUSE-default-services" package or perhaps one package for desktop usage, one for server usage. The beauty of this is that it's not in the package itself but in a meta package!

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.

See above, it's easy enough in practice IMO, 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