Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New DBus API to enable/disable yum repos #1771

Open
kalev opened this Issue Mar 1, 2019 · 9 comments

Comments

Projects
None yet
3 participants
@kalev
Copy link
Contributor

kalev commented Mar 1, 2019

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

This comment has been minimized.

Copy link
Contributor Author

kalev commented Mar 1, 2019

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 jlebon added the enhancement label Mar 1, 2019

@jlebon

This comment has been minimized.

Copy link
Member

jlebon commented Mar 1, 2019

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

This comment has been minimized.

Copy link
Contributor Author

kalev commented Mar 1, 2019

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

This comment has been minimized.

Copy link
Member

jlebon commented Mar 1, 2019

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

This comment has been minimized.

Copy link
Member

jasonbrooks commented Mar 2, 2019

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

This comment has been minimized.

Copy link
Contributor Author

kalev commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Member

jlebon commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Contributor Author

kalev commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Member

jlebon commented Mar 7, 2019

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 added a commit to kalev/rpm-ostree that referenced this issue Mar 8, 2019

daemon: Add new ModifyYumRepo DBus API
This allows clients such as gnome-software to enable and disable
yum repositories.

Closes: projectatomic#1771

@kalev kalev referenced a pull request that will close this issue Mar 8, 2019

Open

daemon: Add new ModifyYumRepo DBus API #1780

kalev added a commit to kalev/rpm-ostree that referenced this issue Mar 15, 2019

daemon: Add new ModifyYumRepo DBus API
This allows clients such as gnome-software to enable and disable
yum repositories.

The API is generic, but for now we only allow changing the 'enabled'
key. If needed, it's easy to allow changing other settings in the
future. See the discussion in the PR for the reasoning.

Closes: projectatomic#1771
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.