[systemd-devel] Unwants

[Dimitri John Ledkov]

On 27 January 2015 at 12:42, Lennart Poettering <lennart at poettering.net> wrote:
> On Thu, 22.01.15 15:16, Dimitri John Ledkov (dimitri.j.ledkov at intel.com) wrote:
>
>> On 22 January 2015 at 14:46, Michael Biebl <mbiebl at gmail.com> wrote:
>> > 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov <dimitri.j.ledkov at intel.com>:
>> >> At the moment, I'm looking at packaging symlinks in .wants directories
>> >> under /usr and then allow to uninstall such a package as a means to
>> >> override the default config. Since I would like to update how the
>> >> default config is setup, without doing in /etc where I'd have to
>> >> answer "is this my old config, or user modified it and I shouldn't
>> >> touch it"
>> >
>> > That's indeed a tough problem. The upstream recommendation is, to run
>> > "systemctl preset" during the initial installation.
>> > If there are changes to the default in the unit files, those changes
>> > are *not* applied on package upgrades.
>>
>> Presets are good, however they do not have a format to specify extra
>> .wants and .requires. And in my case unwants and unrequires.
>
> Extra .wants and .requires? What would those entail? I mean, the unit
> files can store extra deps in their [Install] section...
>
>> So at the moment I'm playing around with - unconditionally running
>> preset on my preset file, and directing users to write (override) own
>> preset file in /etc/systemd/system-preset if they want to modify the
>> default proposed integration.
>>
>> > I don't think that's a particularly compelling solution.
>> >
>> > In Debian, we introduced a helper called i-s-h [1], which keeps some
>> > additional state and tries to apply such changes on updates.
>> >
>>
>> Well, if "systemctl enable/disable/add-requires/add-wants" would write
>> things into /etc/systemd/system-preset instead of modifying things in
>> /etc, then it would be alright. As essentially the full set of presets
>> would be the state of system-defaults + user overrides.
>>
>> Also it seems like preset is a bit of templating hack at the moment,
>> as they are not loaded by systemd but rarther are simply used to
>> generate files/symlinks on disk under /etc.
>
> I don't follow. Presets are the recommended vendor configuration, and
> as such static and immutable. It is supposed to be applied once,
> during first installation of a pacakge. From that point on things are
> user configuration and presets will not be applied.
>

The end result of preset commands is the same as running a series of
enable/disable commands interactively.

Which means it is never possible to tell apart differences between:
admin changes, current vendor configuration, original vendor
configuration at install-time. Nor upgrade to new vendor defaults.

Thus preset files simply scrip a list of enable/disable commands to run.

It is not supposed to be applied only once, but rather it has no way
to distinguish user modifications vs "old vendor config" and thus
cannot be re-run again without loosing admin changes/choices.

E.g.
for my use-case it would be awesome if preset commands would generate
symlinks in e.g. /var/lib/systemd/preset-system/
That way preset files is the current vendor configuration,
/var/lib/systemd/preset-system has symlinks as to how the system was
configured at install time.
Later when system is upgraded and e.g. vendor presets change, I would
like to enable user to upgrade the install time config to the current
one (by running preset command again, which would update symlinks in
/var/lib/systemd/preset-system based on the new preset configuration)
Or something like that.

I'm working on a system which has a policy of units enabled by
default, with packaging discouraged from shipping files in /etc.

/etc is end-user modifiable however and is supported to store
overrides over what is shipped in /usr.


> Patching preset files during runtime is really against what they were
> designed for.
>
> Quite frankly, I have trouble following at all what is being attempted
> here...
>

I think i'll need to start again, or show/expain what I mean on Friday.

-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.