[systemd-devel] Have custom agetty behaviour even after upgadres

Kay Sievers kay at vrfy.org
Tue May 15 10:38:56 PDT 2012


On Tue, May 15, 2012 at 7:19 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 15.05.12 17:47, Wulf C. Krueger (philantrop at 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 at 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


More information about the systemd-devel mailing list