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

[Mike Gilbert]

On Tue, Jun 10, 2014 at 1:32 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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....
>

The problem with installing these symlinks as part of a package is
that the user may have removed them from /etc/systemd using systemctl
disable. The next time they install systemd, the package puts the
symlinks right back.

Gentoo's Portage package manager has functionality to protect modified
config files under /etc from being overwritten during reinstalls and
upgrades. However, this protection does not apply to files which have
been removed entirely by the sysadmin.

We can implement post-install logic to avoid this problem, but that
means we either need to remove the symlinks from DESTDIR manually or
we need the build system to not create them in the first place.

If rpm or dpkg have a way to detect when the sysadmin has removed a
file and will not replace that file, that's news to me.