i think limiting to systemd is wrong. maybe the package should be fedora-config-<foo> it could put other config snippets, or pull in packages for the experience of the product.
Yes, we could potentially obsolete the NetworkManager-config-server package.
However, two concerns:
1) We have to consider what happens when multiple of these things are
installed simultaneously. It's good that we will have a more clear
technological distinction between Workstation and Server (and Cloud) -
but sadly the "Workstation on a Server" is still a valid use case. Now
projects like Cockpit attempt to reduce the need for this, but the
truth is we still have legacy server-oriented GUI apps that people
want to run.
We should ensure at least a "not completely broken" result occurs if one installs
fedora-config-workstation and fedora-config-server simultaneously.
In the case of DHCP for example, it would work out, as the NM default
will be DHCP on, and if you have both -config-workstation and -config-server,
you get DHCP off, which is correct.
But should you get say GDM on by default? I think that's probably
OK, although this use case is more about VNC.
2) What about RPM transaction ordering? If we try to enable a new
service by default, unless we ensure that the new -config package
is installed *before* the service RPM, then the %post won't see
the updated preset file, and it won't be enabled.
With having the presets in the systemd package itself, we get
out of this problem as the RPMs Require(post): systemd-units.
(At least I think - does that ensure that if newer versions of
both are part of the same "transaction", that the newer systemd
will be installed before the service?)
Now this would all be instantly saner if %systemd_post happened
in %posttrans instead of %post.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
