Re: Integration with gnome-software

[Richard Hughes <hughsient gmail com>]

On 24 March 2016 at 21:55, Peter Volpe <pvolpe redhat com> wrote:
> > * List the user-visible name for the remote
> This concept isn't consistently implemented yet.

Okay, I can hardcode something.

> The default remote is based on the current default deployment. If you are
> using rpm-ostree dbus it's in the Deployment tuple.

Thanks.

> AFAIK, you can use the rpm-ostree library to get this.
> https://github.com/projectatomic/rpm-ostree/tree/master/src/lib but that
> also has the rpm dependencies.

I ended up just using librpm for this.

> > * Download all the required commits for the newest version of a
> > specific remote *without* actually committing
> AFAIK, the rpm-ostree dbus api does not currently support this, but can be
> done using the ostree library directly.

Do you have any hints to what flags I need to use for this
download-not-deploy mode? Sorry for all the newbie questions, I hope
it's clear I'm willing to do the work where required :)

I also assume it would be okay to add extra things to the rpm-ostree
dbus interface just for my use?

> The dbus api only supports
> downloading the rpm directory so that you can preview what changes will be
> made. But it doesn't download the whole file tree.

Right, I think the main download is the one that will take all the
time, so I'll have to look at this for gnome-software. We can't use
librpm-ostree or libostree *writer* code directly as we're running in
the session.

> > * Display all the package names of all the updates in the
> > downloaded-but-not-staged commits
> This can be done with the DownloadDeployRpmDiff / GetCachedDeployRpmDiff and
> DownloadUpdateRpmDiff / GetCachedUpdateRpmDiff dbus methods.

Are there any docs for those? I can't find any generated docs other
than the implementation which is kinda sparse on comments.

> If using the dbus api, all the deploy methods only reboot if passed the
> reboot option.

Gotcha, thanks.

On 24 March 2016 at 22:07, Colin Walters <walters verbum org> wrote:
> All looks right to me - I'd say the Cockpit team did an *amazing* job
> on driving and helping implement the rpm-ostree DBus daemon,

Right, agreed. I've already been talking to Andreas and the others
about their code.

> and I'd take a look at the high level Cockpit design (such as orienting towards version numbers
> and the "deploy" concept) - the code implementing that should help
> answer some questions too.

Well, I was confused about the a.b.c.d version scheme. What kind of
policy should there be for fedora-worksation? I wasn't sure what the
format was meant to signify (major.minor.micro.patch, so
24.0.0.${build_number}?) so ideas or links to docs welcome.

Thanks,

Richard