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. > >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...) > 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? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel