How best to package suites of apps (e.g. sysinternals)?

[JohnLBevan]

Currently, to install ZoomIt I'd need to install the full sysinternals suite (available from msstore source rather than winget). For some of the apps in that suite though, there are individual manifests:

winget search sysinternals
Name                              Id                                     Version Match             Source
----------------------------------------------------------------------------------------------------------
Sysinternals Suite                9P7KNL5RWT25                           Unknown                   msstore
Process Monitor                   Microsoft.Sysinternals.ProcessMonitor  3.92    Tag: Sysinternals winget
Process Explorer                  Microsoft.Sysinternals.ProcessExplorer 17.02   Tag: Sysinternals winget
Autoruns                          Microsoft.Sysinternals.Autoruns        14.09   Tag: Sysinternals winget
Desktops                          Microsoft.Sysinternals.Desktops        2.01    Tag: Sysinternals winget
BGInfo                            Microsoft.Sysinternals.BGInfo          4.32    Tag: Sysinternals winget
TCPView                           Microsoft.Sysinternals.TCPView         4.17                      winget
Remote Desktop Connection Manager Microsoft.Sysinternals.RDCMan          2.92                      winget

Of course, we can create more individual manfiests too; but it feels like this may be duplication of effort.

Is there any strategic guidence on how we best tackle things like this?

I'd assume the best solution would be to create a manifest per "minimal viable program", then where a particular set of programs are recognised as a suite provide a manifest for that suite which has the individual programs listed as dependencies, so they all get installed via their existing packages / reducing duplication.

Another approach for suites could be to create a package for everything in that suite, but provide options to selectively include/exclude particular programs.

Or a combination could be used; where we package things according to the first suggestion (individual manifest per MVP with a grouping manifest for the suite), whilst allowing the second approach for easier installation (e.g. installing the suite, but using parameters to exclude certain programs).

[denelon]

We're learning along with the community here.

I think it's going to depend on both the publisher and their users.

We've been thinking about "virtual packages", but there are dragons to be slayed there. One thought is to have the suite as something like:

Publisher.Suite

Followed with "child" packages like:

Publisher.Suite.package1
Publisher.Suite.package2

Something like that could afford a manifest for the suite, and then individuals as children.

I think the challenges comes in when there isn't an "installer" for the suite, and it's more of a logical grouping.

If both the suite and one or more of the "children" is installed, then we would have some interesting interactions with the upgrade scenario. A user could end up with two versions of a tool and no good way to resolve which one gets called via CLI (usually based on path search order which has strange behaviors depending on whether the parent or the child shows up "first" based on the path search order.