[Rpm-ecosystem] Photon and dnf

Stef Walter swalter at redhat.com
Tue Apr 28 14:06:21 UTC 2015

On 24.04.2015 15:57, Jan Zeleny wrote:
> Dne Pá 24. dubna 2015 07:50:30, Colin Walters napsal(a):
>> On Fri, Apr 24, 2015, at 01:11 AM, Krishna Ganugapati wrote:
>>> Jan,
>>> Thanks a ton for the note.  Great to know that you're considering a full C
>>> implementation for dnf. That would be an awesome thing to do - we do find
>>> a bunch of users who would like this minimal low footprint
>>> implementation.
>>> We're happy to look at libhif and if it meets our requirements using it.
>> There's a lot of important things that need to be lowered into a common C
>> base, like GPG key management.
>>> One of the key things we're looking to do is build an daemon that calls
>>> libtdnf or libhif but provides remotable APIs so that an end user can
>>> look at the state of the rpm database and perform operations remotely.
>> Sounds like PackageKit?  Although in keeping with most local management
>> APIs, it's DBus, not REST.
>> There's work on an rpm-ostree daemon:
>> https://github.com/projectatomic/rpm-ostree/pull/116
>> Which is planning to be used by Cockpit, which is a remote UI for server
>> management.
> Adding Stef to CC, as he might be interested in something like this (not just 
> for rpm-ostree but for management of rpms in general).

Yeah, a DBus interface would be interesting, depending on its scope.

But even without considering API, we've run into some fundamental
limitations implementing RPM based software updates in Cockpit. I
haven't had time to write up the issue in detail. But basically:

 * Cockpit needs to be able to implement an "update this machine"
   feature in a "maintenance free" way.

 * By "maintenance free" we mean that an admin should be able to
   schedule and/or perform a software update without an intimate
   knowledge of the rpms involved.

 * To do this, we will likely need to use offline updates. As far
   as I know PackageKit and OStree are the only implementations of

 * We all love updating our systems without rebooting, but RPM does
   not provide enough information to know what would be affected
   (ie: interruption of service) and/or what processes, cgroups,
   need to be restarted after such an update (eg: loaded vulnerable

 * At the present time PackageKit has had dependency problems (pulls
   in X, GTK+ and image processing libraries) which prevent it's
   use on servers. I think this is work in progress.

I'd be happy to discuss this in more detail if it helps.

But for now we're implementing OSTree software updates as our first
Cockpit feature in this area ... after which we'll spend more time on
figuring out how we might pull off updates for more traditional machines.


More information about the Rpm-ecosystem mailing list