brigadier
brigadier copied to clipboard
timsutton
7zip
I've "finally" persuaded where I am to try Brigadier as the amount of images one man is maintaining is getting frankly ridiculous.
Now my colleague preinstalls his images with 7zip version 9.2. This sadly does two things: 1) installs into the program files x86 directory and 2) causes the 7zip package brigadier needs to not be installed due to the detection code not picking up that it's the wrong version.
End result is the package fails to decompress and the installation fails.
May I suggest as a quick + dirty hack a forcible uninstall of any existing 7zip installs before putting on the version brigadier requires? We're going to work around this by no preinstalling it in future.
Is your colleague installing the 32-bit version of 7zip? If so, is there a particular reason? (Assuming this is 64-bit Windows..)
I'll check when we're back in the office on Sunday. (Islamic weekend is Friday Saturday).
I'll have to assume he is doing that.
This is a 64bit windows 8.1 running on the latest MacBook Pro as a test.
Just to add, I'm not a fan of the idea of pulling out any pre-existing version, because then I'd want to make sure I can put the desired version back. Admittedly the existing code for checking the existence of 7-Zip could be more robust, and include more paths..
On the whole I'd agree but it does seem like the latest stable version of 7zip can't handle the latest bootcamp driver package, but the beta version can.
I see. So there could be a case where someone's installed 9.20, and even if we detect and use that, it's not sufficient to handle all the Boot Camp packages out there.
Since we have the luxury of having 7-Zip available as a standalone exe.. I'm starting to think it'd be better to just download the standalone exe in any case and run it from a temp location. Then we can dispose of any checks and state to do with having detected an existing version, etc.
I'd like there to be a configurable way for someone to ship their own copy and not depend on the 7-Zip website being up, but as I'm still thinking of some changes to the CLI interface, so maybe that can wait until then.
Oh, never mind. The .exe downloads are still installers, they just aren't MSIs.
So, it's also possible to pass /S and /D options to the current Beta (15.05) and install it in a separate place, but what I still don't like is that if we install 7-Zip to a hidden place and then uninstall it, the MSI database now doesn't show 7-Zip, even though a copy may exist from an admin in c:\program files.
Probably not a big deal...
I can’t vouch for anyone else, but that’s not a deal breaker for me.
However i’m wondering why they got rid of the .msi installer? Seems strange to me.
Maybe the Nullsoft installer had issues. The new installer still has the silent options, at least.
If you or your colleague know of a way that this specific installation of 7-Zip could be removed from the MSI database on removal, without affecting any possibly existing installs (which could be any version, really), I'd love to know!
Or ideally, if there's a way to simply download the binary from an authoritative source in a format that's not an installer or another 7z archive...
After some discussion, our workaround here is not pre-install 7zip as we were doing and just let SCCM push it to the computer afterwards. It's probably the easiest thing to do.
Unfortunately, Igor doesn't provide the 7z standalone executable outside of a 7z file... Kind of a chicken and egg issue. Another option could be to set a minimum required version of 7zip. If it is lower than 15.14 or whatever version added DMG support, then save out the version info, upgrade, extract, uninstall, then download and install the version that was removed. The URL is the same for all versions just substituting the numbers, so it would be pretty trivial to add the logic.
