From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

NI Package Management Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
ChrisStrykesAgain

Blacklisting packages

Status: New

I'd like a way of "blacklisting" an NIPM package, even if it's in a feed and selected for install For example, I could register the feed for the package "ni-labview-2020-core-x86-en" and also want to install all of the recommended packages (using the --include-recommended flag), except for one. Let's say for some reason I don't want Report Gen Toolkit, for example.

 

The only option I can currently come up with is installing LabVIEW 2020 without any of it's recommended packages, then installing all of the recommended packages separately, except omitting RGTK. It would be really great if there was a command to simply prevent RGTK from ever installing, even when using the "--include-recommended" argument.

 

In terms of use cases, let's say an administrator wants to give their users some freedom, but never wants a particular package installed (or upgraded past a certain point) for some reason. This would be similar to the dpkg or apt functionality described here (https://www.linuxuprising.com/2018/10/how-to-keep-package-from-updating-in.html) or (I think) the okpg "flag" operation described here (https://openwrt.org/docs/guide-user/additional-software/opkg).

--------------------------------------
6 Comments
CL_eisenwr
Active Participant

I think you could lock a package so it is harder (CLI instead of GUI) to prevent upgrading a package. However that does not solve the prevent it from ever being installed case.

__________________________________
Bill Eisenhower
Certified LabVIEW & TestStand Developer
ChrisStrykesAgain
Active Participant

I'd actually be OK with that as well. Is locking a package currently supported?

--------------------------------------
CL_eisenwr
Active Participant

I believe it has been there for a while. I have not used it but it is listed in NIPKG.exe CLI and there are options for some commands to override locks. 

Unfortunately you have to use the command line to get the CLI help

https://www.ni.com/documentation/en/ni-package-manager/20.0/manual/cli-package-manager/

__________________________________
Bill Eisenhower
Certified LabVIEW & TestStand Developer
ChrisStrykesAgain
Active Participant

In retrospect I remember seeing that, but it /claims/ to only block the removal or upgrade of packages that are already installed. My actual goal is to prevent them from being installed at all.

--------------------------------------
WesW
Member

Hi Chris,

 

Yes, locking/unlocking is supported by NIPM, and you can do this from the CLI (nipkg.exe help lock and nipkg.exe help unlock)

 

But, to block it in advance, you could alternatively accomplish this with a design pattern like the following:

  1. Create an empty, placeholder package of any name, like "report-gen-toolkit-blocker"
  2. In its control file, have it "Provides" the exact name of the NI package you want to block. This means that, once this package is installed, that it will satisfy any incoming dependency on a package of that name.
  3. In its control file, set an attribute "Essential" to a value of "yes" (sorry, not sure why that one is not documented). This will cause the package to be not uninstallable from the NIPM GUI, and can only be removed using the nipkg.exe CLI using the "--force-essential" flag on uninstall.
  4. Optional: In its control file, set attribute "XB-UserVisible" to a value of "no" if you don't want the end user to see this by default.
  5. Install this package first, which will prevent the real package from being installed.
  6. Tip: If you have multiple packages you always want to block, you can just Provides multiple package names, as it's a comma-delimited list.
WesW
Member

Just to add...

Warning: Do be careful with the "Essential" attribute, as since it's not easy to uninstall, you probably don't want to publicly release a package with this set. It's OK to use within your organization if you understand this, however.