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

[Dave Reisner]

On Tue, Jun 10, 2014 at 06:26:47PM +0200, Lennart Poettering wrote:
> On Sun, 08.06.14 09:37, Dave Reisner (d at falconindy.com) wrote:
> 
> > On a related topic, could we please stop shipping hardcoded symlinks in
> > /etc in favor of documented reccomendations for downstream packagers?
> 
> Hmm, well. The way automake currently works is that all config files are
> overwritten on "make install". WHich is probably the right thing to do I
> think. People who use "make install" without DESTDIR= should be prepared
> to get their configured reset in one way or another...

I guess I've been under the assumption that this was more of a "you're
on your own" situation -- that the build sys was tailored towards the
folks who are going to be doing the packaging for downstream. It sounds
like this isn't really the case; that's fine with me.

Perhaps there's a middle ground we can find. Tom mentioned the idea of
a "package" mode during configuration. How about a simpler idea -- if
DESTDIR is empty, add the symlinks. Otherwise, don't.

> Creating a couple of symlinks in /etc, and dropping a number of
> configuration files in, doesn't appear to be so much of a difference to
> me. Can you explain to me why we should depart from automake's
> traditional behaviour here, and wh symlinks should be something
> different from configuration files?

Traditional configuration files have their own content. They can be
hashed and tracked by your package manager. On upgrade, you can make an
intelligent decision about what to do with the new file (replace,
ignore, merge) based on the original and current hash of the existing
file, and the has of the incoming file.

Symlinks are more of a binary decision -- either they exist, or they
don't. But, they're still configuration in this context. There's no way
to track this on/off "bit", so distros (well, speaking of Arch) simply
nuke the symlinks and add back what they see as "sane defaults" during
installation (explicitly leaving the symlinks untracked).

> I mean, ideally we'd just invoke "systemctl preset" for these things,
> but for the sake of cross-compilation we can avoid this easily. 
>
> We probably should ship make sure to ship the very same symlinks we
> create with "make install" with a preset file though...

Yeah, this sounds prone to drift unless it could be generated from some
"master" list.

d