Thanks for your quick response. Not sure we're using BoxStarter in a “sophisticated manner”, I think I may have simply been trying to leverage Chocolatey's dependency handling capabilities a wee more than BoxStarter is happy with.
In regard to your suggestions...
I am not using Install-BoxstarterPackage for invocations within packages, only to call the initial package.
Referring to my previous example, I call:
None of the packages have calls to CINST
. Instead they use Chocolatey’s package dependency feature defined in the
files. For example, the C2.nuspec
file would look like this:
<description>Installs package C v2.0 and all it's dependencies.</description>
<dependency id="C" version="1.0" />
Based on my experience with the technologies so far seems like Chocolatey is handling these dependencies exactly as I’d expect, installing A1, A2, A3, B1, then C1, before getting to C2 (assuming the
files for the other packages have their dependencies defined correctly). If I understand what you’re saying BoxStarter may not play well with Chocolatey if and when Chocolatey packages have dependencies defined in this way and causes reboots
within the package chain.
The benefit of using Chocolatey’s dependency mechanism, in my view, is the ability to only have to specify the top level dependencies for a given package without worrying about any dependencies on down the line; the child packages are aware of their own dependencies,
obfuscating them from the package one’s requesting (e.g. C2). Calling CINST
, instead, would require a package to know all of it’s dependencies, child dependencies, etc., up front; not a big deal, but maintenance could become a nightmare, especially
as our package library grows.
If that’s the way to go I’ll give it a shot, but I’m running into another issue. As mentioned previously we have our own set of internal package libraries which we point BoxStarter to with:
Set-BoxstarterConfig -LocalRepo \\<Some Machine>\<Our BoxStarter Package Library Root Folder>
But when I call CINST
for one of our internal packages, say
, I get:
C:\Windows\system32> cinst sw-stuff
Chocolatey (v0.9.8.23) is installing 'sw-stuff' and dependencies. By installing you accept the license for 'sw-stuff' and each dependency you are installing.
Unable to find package 'sw-stuff'.
Command 'install' failed (sometimes this indicates a partial failure). Additional info/packages: sw-stuff
Reading environment variables from registry. Please wait... Done.
If I can get CINST
working for our local packages then your solution should (hopefully) do the trick.
In terms of your second point, what I’ve been doing to get us by for now is tell the installs encapsulated by my packages to run silently and ignore reboots then, once the install is done, call
). I was under the assumption that if I allowed the install to cause the reboot this would prevent BoxStarter from regaining control again until after the machine came back up. If I
understand you correctly I should allow the install to start the reboot, then BoxStarter will automagically detect this while it’s in progress?