@cgwalters Okay, and how do non-Linux systems do this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Just to echo
https://github.com/rpm-software-management/rpm/pull/1255#issuecomment-645103007
here - inotify is used today for e.g. `/usr/share/applications` - when you e.g.
`zypper/apt/yum/whatever install firefox` that's how the desktops pick up the
change.
As far as portability, there are
Yeah, something built around a named pipe puts actually rpm in control of the
thing, and also has the benefit of being generic.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
A linux specific way would be to offer some functions around inotify().
We can also try something more generic: We could create a named pipe in
/var/lib/rpm. At the start of the transaction we open the pipe O_WRONLY, at the
end we simply close the fd.
Some other process that wants to be
Hmm, so it seems. Probably memories getting mixed up with BDB which I do think
supports multi-process notification (which of course is all part of the reason
its such a weird beeast). Since we can't really expect help from the database
itself here, so the options are limited.
--
You are
I don't think sqlite notification hooks work for different processes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Traditionally rpm-related daemons have been watching for changes in
/var/lib/rpm/Packages file, but hardcoded paths were always ugly and no longer
feasible at all because of multiple supported backends with different file
names and semantics over them.
We recently added rpmdbCookie() API for
