[Rpm-ecosystem] Photon and dnf

[Jan Zelený]

On 28. 4. 2015 at 16:06:21, Stef Walter wrote:
> 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.

What granularity of updates do you have in mind? I assume that not having an 
intimate knowledge of the rpms involved means that you just want to update the 
entire system, not any specific parts of it, right? Or perhaps updating per 
errata?

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

Why do you need offline updates? For the scheduling part? If so, we already have 
some (very vague) initial plans how to tackle this as well but we need 
business cases to help us better plan features like these. I think we are off 
to a good start here.

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

There are several tools that address this issue:
needs-restarting [1]
yum ps [2]
tracer [3, 4]

[1] http://man7.org/linux/man-pages/man1/needs-restarting.1.html
[2] http://koji.fedoraproject.org/koji/rpminfo?rpmID=6132154
[3] http://www.tracer-package.com/
[4] http://koji.fedoraproject.org/koji/rpminfo?rpmID=6187334

Is that a good start?

-- snip --

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

Please let us know when you do, we will do our best to help you. This ML is a 
great place to have such a conversation.

Thanks
Jan