On Tue, May 15, 2012 at 7:19 PM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Tue, 15.05.12 17:47, Wulf C. Krueger (philant...@exherbo.org) wrote:
>
>> On 14.05.2012 23:34, Lennart Poettering wrote:
>> >> I'll bring this closer to home. Why does "make
>> >> DESTDIR=%{buildroot} install" write to $(sysconfdir) when you've
>> >> always proclaimed that it's admin territory? Why not write this
>> >> link as: $(systemunitdir)/getty.target.wants/getty@tty1.service?
>> > Since this is just about enabling, not about shipping
>> > configuration. People will frequently not enable the getty on tty1,
>> > on servers with serial gettys and on containers for example.
>>
>> I'd say, leave the entire enabling part to the distro/packager and
>> don't do the linking at all.
>
> Nah, I am kinda interested in having something that boots sanely after I
> do "make install".
>
> It's the distro's build scripts job to undo the enabling if this isn't
> desired.
>
>> It's up to the distro to decide about a sane default installation with
>> respect to about every other part of systemd already - why make this
>> an exception?
>
> It is totally up to the distro. Not sure what you mean.It is not an exception what systemd does, it's common and intended behaviour. Almost all tools install the default config file in DESTDIR/etc/ and overwrite anything that was there before, and ship a sensible default in the buildroot. Make install's default are supposed to work. It is surely up to the distribution to pick the stuff they want and to mark stuff as config or to-be-replaced at package upgrades. Please stop mixing up "make install" and "update package" they have a different behaviour for good reasons. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
