Le 05/12/2014 14:52, Lennart Poettering a écrit :
On Fri, 05.12.14 11:06, Didier Roche (didro...@ubuntu.com) wrote:
It seems maintaining this list in sync for all flavors would be a growing
pain (this is a positive effect of the disable by default: you don't have to
maintain such a list), or do you think we can come with something
better?
Hmm, yuck. No good suggestion. I figure this problem doesn't exist
with the fedora default of everything is disabled by default...
All open to ideas...
Can we maybe extend the preset dictionary by having an alias (or
alias-default) keyword taking a pair of arguments, like:
alias display-manager.service lightdm.service
Then, the preset command, for each alias, will stop at the first one it
encounters. If the service doesn't exist, it's a noop, if it's there, it
enables (--force in case something else was enabled for that Alias?)
lightdm.service. It means of course that lightdm.service should contain:
[Install]
Alias=display-manager.service
or preset would then generates a warning.
So far this is not how presets work: they are just a database you pass
in as key a service name, and it tells you whether to enable it or
not, in a simple boolean way. It is something where you pass in the
name of a unit you want to enable/disable, and after you got that, you
do that, but you do not verify again the individual steps
enabling/disabling precisely entail.
It also is currently entirely stateless: you could in theory ask a web
server for such a preset question, and it will always tell you the
same answer, because it does *not* take your local configuration and
set of packages into consideration... This kind of "disconnected" logic
I'd really like to keep.
Hmm, what about this proposal:
Whenever the preset db is queried we'll no longer just return the
verdict boolean, but also a numeric overall line number, of the line
we found the verdict on. Then, when "preset-all" is invoked, we
determine all the operations to execute for everything. Then, before
applying them, we check if there are any conflicting operations. If
so, we remove the ones with the higher line number.
In effect this would mean: if you list to DMs as "enable" in the
preset file, and both are to be installed, then the one that is
enabled "earlier" will win in case of "preset-all". To me this appears
quite a natural extension of the logic already in place.
And I guess the default behavior (enable *) has a lower priority than
overrides? (enable/disable). Also, I guess you concatenate all preset
files as if it was a single one (ascii ordered?) to build that list.
So, retaking the display-manager (on the principle they all have:
Alias=display-manager.service) example, that would mean:
* ubuntu-desktop would ship 99-defaults with:
enable lightdm
* If someone, install the gnome-ubuntu-desktop metapackage on the same
install, they would get an additional preset file 50-gnome-ubuntu with:
enable gdm
And so, lightdm would be removed on a preset-all call as conflicting
with gdm (due to sharing the same Alias) and having higher line number.
Sounds like a nice way to handle Alias. Happy to have a look at this.
How does this all precisely work on on ?
Most of them shipped a conffile like /etc/default/<service_name> file with
an ENABLED=true/false keyword. This doesn't really map in the systemd world
(repetition of enablement/disablement states)
* "apt-get remove" keeps conffiles
* "apt-get remove --purge" deletes them.
* When an upgrade occurs:
- if the package conffile didn't change -> kept with the modifications if
any
- if the package conffile did change -> infamous debconf prompt about "a
maintainer configuration file changes, do you want to apply maintainer
changes/keep as it is/see the diff…"
That's how all those use cases are handled on sysvinit.
Of course, we could introduce that back with ExecStartPre=`grep …` but well,
2 places (systemd symlinks + a /etc/default/ file) to decide one thing isn't
really appealing nor wanted :)
To be honest I find the entire stuff with ENABLED=true/false really
questionnable, I think it would be agreat step ahead to get rid of
it. (But then again, I cannot make Debian's decisions there...)
Agreed, I already removed it from some ubuntu-only packages like
whoopsie, xdiagnose… and I'm trying to investigate the right way to get
a systemd-oriented solutions (while still being compatible with older
init system for debian)
Only preinst can (getting the "install" or "upgrade" argument), not postinst
(getting "configure" in both case). And we need to run the preset/enable in
postinst (meaning: after unpacking).
This sounds quite a limitation. Maybe you can keep a couple of touch files
in /var/lib/ somewhere where you store whether you already applied
"systemctl preset" before?
This is possible, but really not encouraged (due to some possibility to
have unpacking or other intermediate states failing).
This would also only "fix" the newly installed case, not the upgrade
with new distro defaults or various purge vs remove ones. That's why I
think some kind of previous state db can help getting all those
requirements met as you propose, and doing some comparisons between
states (only when they deviated from defaults).
Then, we can run preset on packages that matches previous defaults
(meaning: where the admin didn't override the default choice) as a dpkg
trigger (when new units are installed/upgraded and on a new/updated
preset file shipped).
Would that makes sense?
Didier
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
