On Tue, Jul 19, 2011 at 18:21, Bill Nottingham <nott...@redhat.com> wrote:
> Kay Sievers (kay.siev...@vrfy.org) said:
>> On Mon, Jul 18, 2011 at 23:27, David Michael <fedora....@gmail.com> wrote:
>> > On Mon, Jul 18, 2011 at 5:16 PM, Bill Nottingham <nott...@redhat.com> 
>> > wrote:
>> >> Right, but that then causes 'last one wins' behavior among multiple DMs.
>> >>
>> >> I suppose we could use alternatives for this, as much as I dislike it.
>> >
>> > I meant creating that symlink was the replacement for
>> > /etc/sysconfig/desktop, the end-user configuration.
>>
>> Yes, this link will replace the config file.
>>
>> > As for what packages do about their DM service files, I would agree
>> > with letting alternatives manage a default
>> > /lib/systemd/system/display-manager.service symlink,
>>
>> We should not let packages create config files in lib, lib is more for
>> static content from rpms, not really for configuration. For the same
>> reason, 'systemctl enable/disable' acts on /etc only.
>
> It's not a config file, it's the default service. I mean, we could
> manage the one in /etc instead, but I don't know that that's that
> much better. You could make the argument that the symlink in /lib is
> the system maintained software, and therefore is the proper one.

Right, if we say that gdm places the link there, I don't see a problem
with that. As long as it isn't something the user can change with
anything else than (de-)installing rpms, all should be fine.

> Honestly, I'd prefer that 'systemctl enable', when called from
> spec files, enable under /lib to better define what the system defaults
> are. Of course, that might be better handled with the preset code.

We should make sure that no host-specific config ends up in /lib or
/usr/lib. We like to be able share all that read-only across many
hosts, and the enabled/disabled state of a service is probably
host-specific and should then only be stored in /etc.

Kay
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to