[systemd-devel] systemd-network-wait-online symlinks to systemd-networkd

Tom Gundersen teg at jklm.no
Mon Jun 9 08:55:10 PDT 2014


On Mon, Jun 9, 2014 at 4:08 PM, Dave Reisner <d at falconindy.com> wrote:
> On Mon, Jun 09, 2014 at 10:12:35AM +0200, Tom Gundersen wrote:
>> Hi Dave,
>>
>> On Sun, Jun 8, 2014 at 3:37 PM, Dave Reisner <d at falconindy.com> wrote:
>> > Commit 2dcf7ec6ec added the following to Makefile.am:
>> >
>> > +GENERAL_ALIASES += \
>> > +       $(systemunitdir)/systemd-networkd.service $(pkgsysconfdir)/system/multi-user.target.wants/systemd-networkd.service \
>> > +       $(systemunitdir)/systemd-networkd.service $(pkgsysconfdir)/system/network-online.target.wants/systemd-networkd-wait-online.service
>> >
>> > Which, of course, results in systemd-networkd-wait-online being a
>> > symlink to systemd-networkd.  This doesn't seem correct at all.
>> > Shouldn't it link to systemd-networkd-wait-online.service?
>>
>> Indeed, that's a copy-paste error. Feel free to fix up, or I'll do it
>> when I get home tonight.
>>
>
> Thanks for confirming -- pushed.

Great. Thanks!

>> > On a related topic, could we please stop shipping hardcoded symlinks in
>> > /etc in favor of documented reccomendations for downstream packagers?
>>
>> I believe the aim here is to make "./autogen.sh c && make && sudo make
>> install" give the "recommended" installation. I suppose one
>> alternative would be to ship some preset instead (and hook into that
>> from make install) which should be simpler to drop from the package?
>
> Well, hooking into 'make install' doesn't really change the end result
> if there's no way to disable the hook. I strongly believe that the
> overbearing majority of systemd users are installing systemd from their
> distro's package manager, and not 'make install'. Since writes to /etc
> in this case are likely discouraged (as they override the site admin),
> it'd be really nice to separate out these additions somehow.

I guess the reasoning is that packaging is something only very few
people do a few times (i.e., it is done by scripts that could just
delete everything in /etc/systemd/system if that is the policy),
whereas anyone wishing to help develop/test systemd are likely to just
do "make install", so that should probably work out of the box.

Perhaps a compromise would be if passing (or not passing) a specific
switch to ./configure would trigger the "upstream presets". Then we
could make this the default switch in "./autogen.sh c", but packagers
would obviously do the opposite.

Cheers,

Tom


More information about the systemd-devel mailing list