New DBus API to enable/disable yum repos

[kalev]

I'm looking at making third party layered package install work in gnome-software and I'd need a new DBus API to enable/disable repos for that. Any suggestions what it should look like? I'm happy to implement it.

PackageKit has:

<method name="RepoEnable">
  <arg type="s" name="repo_id" direction="in">
  </arg>
  <arg type="b" name="enabled" direction="in">
  </arg>
</method>

Does that make sense or should it be something else? Where should it live? rpmostree1.OS interface I guess?

[kalev]

Could also be a more generic ModifyRepo which would allow changing any fields, not just "enabled". I guess it would have to take an array of key value pairs to update.

[jlebon]

Could also be a more generic ModifyRepo which would allow changing any fields, not just "enabled". I guess it would have to take an array of key value pairs to update.

Hmm yeah, I think that makes sense in case we want to eventually surface it to the CLI level. Minor bikeshed: ModifyYumRepo? Since we have two kinds of repos in RPM-OSTree systems :)

I wonder if we should also integrate this as part of UpdateDeployment so that we can also have transient modifications (so then we could have functionality similar to dnf --enablerepo/--disablerepo on the CLI). I think that just involves not actually calling dnf_repo_commit()? Anyway, something we can add later.

In the past, we've held off on things that dnf knows how to do while trying to figure out a way to leverage it (see e.g. rpm-software-management/dnf#991). That said, repo config changes is pretty straightforward logic where all the heavy lifting is already in libdnf.

[kalev]

I think for the use case I'm thinking about it would be better to globally enable the repo and not just for one transaction. It would totally make sense to have dnf --enablerepo/--disablerepo-like functionality for the CLI though.

ModifyYumRepo sounds like a good name to me!

[jlebon]

Yeah, I didn't mean one or the other. I mean actually having both an API for persistent changes and another for transient changes (through UpdateDeployment modifiers/options). But again, totally fine with keeping the latter out of scope for this ticket! Though it's good to keep it in mind.

[jasonbrooks]

I'd really like to have rpm-ostree install --enablerepo/--disablerepo on the cli. I'm writing a howto and getting ready for some sed action.

[kalev]

Sooo ... how about this for starters?

    <!-- Available modifiers:
         "set-enabled" (type 'b')
    -->
    <method name="ModifyYumRepo">
      <arg type="s" name="repo_id" direction="in"/>
      <arg type="a{sv}" name="modifiers" direction="in"/>
      <arg type="s" name="transaction_address" direction="out"/>
    </method>

To extend it in the future we can just add more modifiers, such as:
"set-baseurl" (type 's')
"set-gpgcheck" (type 'b')

or even a generic change-everything:
"set-options" (type 'a{ss}'), where 'a{ss}' is an array of key-value pairs to set

[jlebon]

Would it make sense to be able to specify multiple repos here? So e.g. one can disable all the repos in one single call? Hmm, or actually maybe we can just have a repo_id of * mean "all the repos".

"set-options" (type 'a{ss}'), where 'a{ss}' is an array of key-value pairs to set

Or WDYT how about just centering the API around that? E.g. make modifiers a a{ss}. That way there's no magical set-* keys; it's just a straight mapping onto the yum repo config.

[kalev]

Would it make sense to be able to specify multiple repos here? So e.g. one can disable all the repos in one single call? Hmm, or actually maybe we can just have a repo_id of * mean "all the repos".

I guess it makes the API a little bit more complicated to use, but maybe it doesn't matter. It's not like a large number of clients are going to be using the API anyway :)

Where we definitely need to have a way to specify multiple repos is the other API addition to UpdateDeployment, to support --enablerepo and --disablerepo. If we want to support something like dnf --disablerepo='*' --enablerepo='rawhide' then we are going to have to have a way to pass multiple repos in one go. And I guess if we go with multiple repos in UpdateDeployment it makes sense to do the same in ModifyYumRepo as well to keep things similar.

"set-options" (type 'a{ss}'), where 'a{ss}' is an array of key-value pairs to set

Or WDYT how about just centering the API around that? E.g. make modifiers a a{ss}. That way there's no magical set-* keys; it's just a straight mapping onto the yum repo config.

Sure, works for me. That was my original plan actually but then thought I'd try to wriggle in a way to make it slightly easier to use on the client side with set-enabled.

[jlebon]

And I guess if we go with multiple repos in UpdateDeployment it makes sense to do the same in ModifyYumRepo as well to keep things similar.

Yeah, no strong opinion there. Maybe a slightly lean towards keeping ModifyYumRepo simple. Even if it operates on a single repo only, and a future UpdateDeployment API allows specifying multiple repos, hopefully we can just call the same backend code in a loop iterating over the repos. :)

[kalev]

Nice, thanks guys!