How can I define installation order of dependencies during NI Package Installation?

[VigneshGV]

Hello everyone!

We have our software deployed to target machines through NI packages, where the package is built in below hierarchy:

eg:

SoftwareInstall_Package v1.5.0.0 (Wrapper package)

  - SystemDependencies v1.0.3.0(Instrument Drivers, LabVIEW, Teststand, etc)

  - SoftwareDeployment v1.5.0.0 (Software Application)

Our expectation is that SystemDependencies will get installed first followed by that SoftwareDeployment package will get installed and completes the dependencies installation for Wrapper package.

Reason: Without SystemDependencies (i.e LabVIEW, TestStand, etc.) getting installed at first place, the SoftwareDeployment package installation will cause some files that are deployed to be in corrupt stage after the installation.

I also understand the installation order is completely owned by NI PM to handle the packages child dependency requirement but felt it would be helpful that we can atleast prevent random order of software files installation.

Based on the above, I would like check - is there a way to control the order of installation for dependencies, or atleast set priorities for dependencies as part of package build spec?

Vignesh G V,

Soliton Technologies

[Rohith_Grandhi]

You can define relationship between your packages. NIPM follows debian format - https://www.debian.org/doc/debian-policy/ch-relationships.html#

You can specify the dependency relationship as follows for your scenario:

in the control file of `SoftwareInstall_Package` -> add

depends: SoftwareDeployment (>=1.5.0.0)

And in the control file of `SoftwareDeployment` -> add

depends: SystemDependencies (>=1.0.3.0)

[VigneshGV]

Rohith,
The dependencies are already defined as "depends" with strict version constraint "=" as below:

SoftwareInstall_Package v1.5.0.0

  - SystemDependencies (Depends) = v1.0.3.0

  - SoftwareDeployment (Depends) = v1.5.0.0

And installation priority for SystemDependencies and SoftwareDeployment is not configurable, as both are marked as "depends"

Vignesh G V,
Soliton Technologies

[cbutcher]

I think the suggestion was that if SoftwareDeployment depends on SystemDependencies, then SystemDependencies should be listed as a dependency in the SoftwareDeployment package (not just in the SoftwareInstall_Package).

I would also ask actually what the overarching package is for - why not just use the two other packages (with one depending on the other)?

Maybe the real case is more complicated and it's been simplified/made publishable for the forums, but as described I don't know why you'd need a 3rd package.

Maybe I misunderstood what you have?

[VigneshGV]

We have different system and instrument types supported by our software, and for a specific system the SystemDependencies are bundled with required drivers and named uniquely (eg: A-SystemDependencies, B-SystemDependencies),

Whereas SoftwareDeployment is common package where it cannot have any particular the SystemDependencies as its child.

Now, SoftwareDeployment and SystemDependencies (specific to system) will contribute to create a System level Wrapper package like (eg: SoftwareInstall_Package-A, SoftwareInstall_Package-B)

[cbutcher]

Forgive typing on a phone, will abbreviate names a little but hopefully still clear.

I would suggest that if softdepl depends on something to work, it should list that as a dependency.

In the description you gave now, I suspect that SysDepends (A, B, C) may have some core elements (that SoftDepl depends on) and then some other elements (A, B, C) that are unique to the system?

If that is the case, you could split your SysDeps into SysDepsCore and SysDeps_A, etc, then have SoftDepl depends on Core, and the wrapper package you mention now depends on SysDeps_A and SoftDepl (and transitively, or explicitly, on SysDepsCore).

Would that work for you?

[Rohith_Grandhi]

Vignesh, 

I am not sure if it was clear in my above point. If you need strict ordering of package installations, you need to have depends relationship defined between them. In this case, there should be a dependency relationship defined between these two packages  - SystemDependencies and SoftwareDeployment. 

[Rohith_Grandhi]

Vignesh,

For this specific case where you have two versions of the same package such as `A-SystemDependencies` and `B-SystemDependencies`.  Then in this case what you can do is add provides: SystemDependencies in the control file of both the versions. And then just add the dependency on `SystemDependencies` in SoftwareDeployment package.

In this way, you can create separate installers for both cases. 

More info on provides https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides

And additionally if you don't want `A-SystemDependencies` and `B-SystemDependencies` to present at the sametime, add a conflicts relation between the two. More info on conflicts  - https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts 

[VigneshGV]

cbutcher, That's right

We have SysDeps_A with some core dependencies packed and those are already separated and added as dependent to SoftwareDeployment package like

SoftwareDeployment 

  - FrameworkCore

But even here, there are certain system specific dependencies required to be installed before SoftwareDeployment which is a specific use case for our software files

[JoshuaP]

The way NIPM works is that it always install dependencies first. If your packages don't have a dependency between one another, there is no way to enforce an order. You can't order things that are simply piers in the dependency hierarchy. Note circular dependencies can also result in indeterministic order. 

I agree with that the best solution is to leverage Provides as a way of saying Package A depends on a generic Package B that multiple other packages can satisfy. Note, you can also use provides and conflicts together to ensure only one type of Package B is installed.