On Fri, 05.12.14 16:02, Didier Roche (didro...@ubuntu.com) wrote: > >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.
Yeah, the default policy of "enable *" would have the largest possible line number, so that any other line number wins. > 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. correct. > Sounds like a nice way to handle Alias. Happy to have a look at > this. Would love to take a patch for this. > >>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? Not sure I grok what you are proposing. I'd be very careful with keeping yet another layer of service enablement states (even if just as "history") in systemd upstream. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel