More flexible dependencies

We have some software that has some annoying installation ordering requirements. The customer needs v24 and v32 of the software, and they install side-by-side just fine, but only if you install them in the oldest-to-newest order.

ImmyBot supports the following things to support ordering:

  1. Software Ordering. Unfortunately if v24 fails to install, ImmyBot will just go ahead and install v32 anyway which means I have to uninstall v32 before I can go back and install v24. These are huge pieces of software and it’s a bit of a pain if something had a download hiccup during deployment.
  2. Dependencies. I think this will solve the issue in this case, and these are fairly speciailised pieces of software so I doubt i’ll get caught out by needed to assign to another client, but it still isn’t the most clean solution.

Ideally i’d be able to create an ordering rule or dependency for v32 like “if v24 is also targeted for this device then v24 is a requirement”


You could just build it into the v32 software, no? Take a look at Sage 50 Accounts, it has a ton of dependencies:

The problem with making v24 a dependency of v32 is that sometimes v24 isn’t required. And they are 5-10GB installers and take ages to install.

There’s a number of other ordering requirements too. Again, not dependencies, just that they need to be installed in order like A then B then C then D then E. It’s perfectly fine not to install (say) B and C, but if they are installed, they have to be installed in that order.

The underlying issue is that v32 and v24 both install various components, and v24 won’t install older versions on top of newer versions, or simply not install the older components. The installer just says no, even though the product runs just fine with the newer versions.

If only vendors wrote good software that didn’t have these issue :wink:

If only users of good software would propose good solutions to the folks that write that good software, these issues probably wouldn’t persist :wink:

How would you propose something be implemented to “sometimes” install v24 and “sometimes not”? To me, this is really the underlying problem here that I can’t say I understand. If you can describe when/why v24 is actually needed and when it is not, then coming to a solution is much more likely to happen. As it stands, I don’t know how I could reproduce the issue in order to propose a solution that improves the status quo. All I can see is “if I assign v24, then it is required.” But, that doesn’t really tell the story completely–we don’t even know what software you’re actually talking about.

I also get the “needing to install things in a certain order,” but what do you propose the behavior of Immy should be in the event that one of those items fail if you don’t create a “dependency chain” (as @Dakota_Lewis described, which I agree with) besides stopping/failing the entire session over it?

Why does v24 fail to install? Is that something that’s addressable?

I wouldn’t really care for the appropach of aborting the session, but you could create a task that checks for successful installation of v24, and if it fails, abort the entire session.

Alternatively, you could write a test for v32 to uninstall/reinstall if it detects that v24 was installed on a later date/time than v32. But, I don’t know if that also means the final application needs to be reinstalled as well? (And if so, a similar test could be written for that software also).

Trying to help out here–but the necessary details to help are just not there–and also seems like the dependency chain already solves the problem, other than the “sometimes” problem that hasn’t been defined.

One “feature” that may get you what you want is the concept that I’ve floated with @DarrenDK a time or two that I call a “Deployment Group” that is an ordered list of deployments that can have an overarching set of parameters that feed into the parameters of the deployments within the group.

Then, there is a feature being worked on called “Child Actions” that allows a single task to create “children” that each report their own compliance (think Windows Updates, and the child actions are all of the individual windows updates being installed).

Not sure if any of that helps you at all, but if not, give us some more specific details so we can try to understand how to effectively solve the problem with Immy.

Okay here are the rules:

  • v24 and v32 can run side-by-side
  • v24 fails to install of v32 is already installed (see below)
  • user A needs v32 only
  • user B needs v24 and v32
  • as newer versions come out we may need those too

The solutions i’m thinking of are:

  • Use Dependencies
    • This ensures that v24 is always installed before v32, and if v24 has a hiccup while installing, v32 will not install and so won’t leave the computer in a bad state where I need to uninstall v32 to install v24
    • Unfortunately this forces v24 to install on user A’s computer. This isn’t necessarily a deal breaker and is probably what i’ll end up doing. These are 10+GB installs though so ideally i wouldn’t have to.
  • Use Ordering
    • This gets things installed in the right order, but only if v24 installs first go. If v24 has a hiccup and fails though, v32 will install and i’ll have to uninstall it which is a long drawn out process. The installs i’ve done so far have been smooth, but there is plenty to go wrong with a 12GB download.

The flexibility i’m looking for here are to say “v32 is dependent on v24, but only if there is a deployment of v24 for this computer”.

The actual reason for the failure is that there are a heap of sub-components for each version of the software, and each version installs it’s own version of the subcomponents. When v24’s installer see’s that v32’s subcomponents are installed, it just aborts. There are no options to not install those subcomponents either. If you install v24 and then v32 though, the subcomponents are upgraded and v24 is fine with it.

Uninstallation requires uninstalling all of those subcomponents one by one. About half of them want reboots. And 2 of them have an interdependency and put up a prompt even in silent mode to say that uninstalling this one will break the other one.

But why does “user A need v32 only” and “user B needs v24 and v32”? And what software are we even talking about?

If any needed software won’t install, you’re in a “bad state” because presumably your user can’t work–so at least part of this problem is making the script tolerate the problems that would prevent v24 from installing properly.

I’ve taken similar steps with the ImmyBot Agent installation script–my goal with that is to make absolutely sure the installation will succeed. It sounds like this mystery software needs some additional scripting work to deal with these nuances as opposed to an Immy feature.