[Rpm-ecosystem] Photon and dnf

[Pavel Odvody]

On Tue, 2015-04-28 at 16:06 +0200, 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.
> 
>  * 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.
> 
>  * 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).

You could inspect the candidate RPMs to see if they contain any
unit/service files for systemd, but this obviously works only for
one-level inspection - if pkg A 1) provides a service 2) depends on pkg
B - now it can happen that you upgrade pkg B, which in turn means that
you need to upgrade pkg A as well ...

So I'd probably take the candidate pkg set, as well as local pkgs set,
and "taint" all local pkgs that, even indirectly, depend on any of the
pkgs from the candidate set. Next introspect the intersecting (tainted)
pkgs like above to figure out what units need to be restarted.

> 
>  * 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.
> 
> Stef
> 
> _______________________________________________
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem


-- 
Pavel Odvody <podvody at redhat.com>
Software Engineer - EMEA ENG Developer Experience
5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20150429/9a70b5c4/attachment.asc>