search

coreos / rpm-ostree

⚛📦 Hybrid image/package system with atomic upgrades and package layering
https://coreos.github.io/rpm-ostree
Other
856 stars 195 forks source link

--skip-inactive switch #1837

Open fbruetting opened 5 years ago

fbruetting commented 5 years ago

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? :)

mwmahlberg commented 5 years ago

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

jlebon commented 5 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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.