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

[Lennart Poettering]

On Tue, 10.06.14 13:10, Dave Reisner (d at falconindy.com) wrote:

> 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.

This sounds fragile... people should get the same results if they avoid
DESTDIR= or if they use it and then copy the result to /... I mean,
that's how DESTDIR has been traditionally defined, and I don't think we
should add any magic to that...

> > 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).

Symlinks should probably just be considered different type of file, that
have a contents and stuff. The contents is usually a file name, and
there's a size limit, but other than that it's just a magic kind of
file, where the symlink destination is the conents. That's how git
handles this, for example.

I have the suspicion that this is really something to fix in your
package manager. It should learn to handle symlink upgrades the same way
as configuration file upgrades....

> > 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.

Well, given that it's not a hundred symlinks, but just a few, I think
having a list in the preset files and one in the makefile isn't too
error-prone...

Lennart

-- 
Lennart Poettering, Red Hat