Intune Integration - Use Existing Dependency INTUNEWIN Packages

[davi808]

Is Your Feature Request Related To A Problem? Please describe.

At present when generating (converting) an Intunewin package, the conversion routine enforces the creation of intunewin packages for dependencies, even if they already exist. This results in excessive and timely re-generation of intunewin packages that are already present for the same product-version.

Describe The Solution. Why is it needed?

It's desired, not needed - to save time and eliminate unneeded processing.

Additional Context.

N/A

Related Issues

N/A - None that I can identify

[pauby]

I think this would be based on Chocolatey CLI internalizing those packages regardless if they exist or not. @corbob can you shed some light on this?

[corbob]

If I understand the issue correctly, this is on running choco convert package.nupkg --to intune. The process for converting is to traverse the dependency tree, and then convert each dependency on the tree. This could be prevented by running with --ignore-dependencies which will forego the whole process of checking dependencies.

The feature request then would be to prevent recreating intunewin files for packages that have already been converted so that when converting multiple packages you don't have to wait for it to convert already converted dependencies.

[davi808]

I understand (and agree) with @corbob and the suggested approach of --ignore-dependencies, however there could be benefits in considering an alternative approach.

As a User, the benefit of choco traversing the dendency tree and converting dependencies is immense, it would be a backwards step to lose that built-in check and potentially introduce issues further into the process during the push to Intune.

Could the focus of any new parameter switch relate to only generating missing dependecies, such as something like --ignore-existing-dependencies?

[gep13]

There is a semi-related issue in this regard when it comes to package-internalizer when it will traverse all dependencies and internalize each one of them. Which ever path is taken here, we should look to address it in both places.