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

--skip-inactive switch #1837

Open
fbruetting opened this issue May 20, 2019 · 5 comments
Open

--skip-inactive switch #1837

fbruetting opened this issue May 20, 2019 · 5 comments

Comments

@fbruetting
Copy link

Scripting rpm-ostree is a little bit cumbersome when one of the programs in a list is already provided in base, because without --allow-inactive we get an error and with --allow-inactive it would get added to “inactive requests”. (In my example, I target both FSB29 and FSB30, so I get different results.) For not getting a larger list of inactive requests cluttering rpm-ostree status output, I think adding a --skip-inactive or --ignore-inactive switch would be a good solution for just ignoring those packages. What do you think? :)

@fbruetting fbruetting changed the title skip-inactive switch --skip-inactive switch May 20, 2019
@mwmahlberg
Copy link

Take provisioning with Ansible, for example. It expects command to be idempotent.

@jlebon
Copy link
Member

jlebon commented Jun 3, 2019

I agree something like this could be useful, though --allow-inactive isn't something you need to be actively avoiding. Note it only shows up in status when in verbose mode.

(In my example, I target both FSB29 and FSB30, so I get different results.)

E.g. in this case, isn't --allow-inactive what you want? So on one it'll be inactive, and on another it'll be active. The end result is that your package is definitely installed regardless how. If you made it conditional on being in the base or not, then e.g. upgrading that f29 box to f30 would simply lose that layering (assuming it's in the f29 base but not f30).

Take provisioning with Ansible, for example. It expects command to be idempotent.

That would be --allow-inactive --idempotent, right?

@akostadinov
Copy link

For some reason with version 2022.2 as found in coreos, I still get error: Package 'NetworkManager-1:1.32.12-2.fc35.x86_64' is already in the base with both --allow-inactive --idempotent.

@jlebon
Copy link
Member

jlebon commented Apr 29, 2022

@akostadinov This is when trying to install a local RPM of NetworkManager, right? Is the intent there that you want that exact RPM to be installed if the base ever dropped NetworkManager?

@akostadinov
Copy link

Intent was to download a number of RPMs and install them from local storage. I couldn't make that work with a random set of RPMs. So I manually installed only NetworkManager-wifi, wireless-regdb and wpa_supplicant to enable wifi and then installed the rest online.

$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sun 2022-05-01 10:00:28 UTC)
Deployments:
● fedora:fedora/x86_64/coreos/stable
                   Version: 35.20220410.3.1 (2022-04-26T21:56:45Z)
                BaseCommit: 83cb95041c99fb812714d5c1544504d77dbb76b7798f0b6d59bf40356bd8d058
              GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F
           LayeredPackages: ddclient iw vim vte-profile
             LocalPackages: NetworkManager-wifi-1:1.32.12-2.fc35.x86_64
                            wireless-regdb-2021.07.14-2.fc35.noarch
                            wpa_supplicant-1:2.10-2.fc35.x86_64

  fedora:fedora/x86_64/coreos/stable
                   Version: 35.20220327.3.0 (2022-04-11T16:21:43Z)
                BaseCommit: dcd18c80388d8b9266b52f2cba97d4f81b9f296f27e9505aa5f543efa422058c
              GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F
           LayeredPackages: ddclient iw vim vte-profile
             LocalPackages: NetworkManager-wifi-1:1.32.12-2.fc35.x86_64
                            wireless-regdb-2021.07.14-2.fc35.noarch
                            wpa_supplicant-1:2.10-2.fc35.x86_64

Btw this solution is not ideal because these packages remain as LocalPackages and I assume will not be updated automatically. And the original intent was to install packages from local storage only because network was not available without them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants