Re: Adding Avahi and USB drive support to libostree

[Colin Walters <walters verbum org>]

On Fri, Mar 17, 2017, at 12:09 PM, Philip Withnall wrote:

> > > and update it just
> > > before polling for updates. However, this is a bit ugly, prone to
> > > synchronisation problems between the update processes, 
> >
> > Because it involves mutating the remote on disk?
>
> Yeah, and hence if the daemon is updating the remotes on disk, another
> process which is about to do a pull can’t be entirely sure that the
> remotes.d files are up to date without synchronising state with the
> daemon.

Temporarily replying to just this bit because I want to understand
this more - do you *actually* have other processes besides eos-updater
which are reading from /etc/ostree/remotes.d?  Do you have scripts
that call `ostree admin` directly for example?  If so, what do they
do and why are they separate?

For rpm-ostree I'm basically trying to drive everything through
the rpm-ostree daemon.  We recently added for example `rpm-ostree cleanup`
which does what `ostree admin cleanup` does *plus* handles all
of the extra rpm-ostree logic like pruning imported package branches.
https://github.com/projectatomic/rpm-ostree/pull/614

That thread is going to continue.  Wrapping `ostree remote add` like
flatpak does would be another case, though it's currently only Fedora
that needs it.  I'd like to even do the random corner
cases like `ostree admin unlock`.  I don't see a near future where we
actually don't ship `ostree admin` for Atomic Host (or for that matter `ostree`, having
`ostree ls` is super handy, though of course one can do that from a container),
but the general principle applies.

Or is what we're talking about in the eos case really just the ugliness
of writing to /etc?  And if that's the case, do you like the idea of having
systemd-style logic for pulling "drop ins" from /run? 

Admittedly that doesn't help upstream a lot of code initially or anything,
but it does provide a general framework I'm sure could be reused for other
things as well, and would clean up the code/logic - the USB key wouldn't
be in the mirrorlist on reboot etc.