Installer does not roll back properly

fourpastmidnight commented 8 years ago

While installing Git 2.7.2, an error was encountered where C:\Program Files\Git\mingw64\bin was unable to be deleted. I was given a dialog with three choices: Abort, Retry, or Ignore. Well, it's fairly safe to say that ignoring this is not a good idea, and retrying didn't work (of course), so really, the only sensible option was to Abort.

When I clicked Abort, the status bar changed and said Rolling back.... However, my previous installation was now corrupted--as not all files were restored/rolled back. This is a pretty huge installer bug. The whole point of MSI's is that they're transactional.

If you're not going to support rolling back a failed installation, then remove the rollback steps in the installer.

dscho commented 8 years ago

The whole point of MSI's is that they're transactional.

We do not have an MSI.

If you're not going to support rolling back a failed installation, then remove the rollback steps in the installer.

How about you open a Pull Request and then we discuss how to continue?

fourpastmidnight commented 8 years ago

This was supposed to go under build-extra section of the Git for Windows GitHub repository. I apologize, I got the wrong issue tracker. And, it appears that the build-extra repository doesn't have an issue tracker.

dscho commented 8 years ago

This was supposed to go under build-extra section of the Git for Windows GitHub repository. I apologize, I got the wrong issue tracker. And, it appears that the build-extra repository doesn't have an issue tracker.

This is by design. We have a central bug tracker because it is unreasonable to ask users to figure out the correct repository.

Now, what about your PR?

fourpastmidnight commented 8 years ago

It's been a few years since I've really used WiX, so I'll try to look into the WiX project and see what I can make of it.

fourpastmidnight commented 8 years ago

Ok, just was Bing'ing around and found @robmen contribution that eventually resulted in the msi folder in the build-extra repo via your PR. At least I have something to work with :). It looks like the MSI installer project has been dormant since 19-JAN-2016. I'll see what I can make of it, but I may need help figuring out how to get it even better integrated into your build process. I see the release.sh file compiles a list of files to be installed and creates a WiX GitComponents.wxs file. I was able to successfully create a MSI, but since it's early in the development process, naturally, it's not as full-featured as the InnoSetup installer--yet. Hopefully, I can help improve that.

Of course, the whole thing that led to this issue was I thought I was using an MSI wrapped in a bootstrap EXE. I didn't realize the installer was InnoSetup. I'm hoping a MSI-based install will provide a better installation and upgrade experience, especially supporting rollback support.

dscho commented 8 years ago

Hopefully, I can help improve that.

That would be great!

Please note that I already wrote up a list of things that will need to be addressed before I can make official .msi installers: https://github.com/git-for-windows/build-extra/pull/96#issuecomment-177232211

fourpastmidnight commented 8 years ago

I already figured out why git-cmd.exe and git-bash.exe don't get installed: It's because of the sed script in release.sh and the actual location of these files. I'm working on mitigating that now. What are the [OPTIONS] that can be passed into release.sh?

The other things you mention are completely doable and I wouldn't ship an installer without those items, too.

Lastly, this might be more work, but, for instance, I never check the box to install the Git-GUI shortcut, I just don't need it. It would be great to not only not create a shortcut and context menu entry for Git-GUI, for example, but also to not install the required files for Git-GUI, either. Is there a way to know what all the dependencies are for git-bash.exe, git-cmd.exe and git-gui.exe? The MSI Feature tree could easily accomplish this. This doesn't need to be part of the initial release, but it would be nice.

dscho commented 8 years ago

I already figured out why git-cmd.exe and git-bash.exe don't get installed: It's because of the sed script in release.sh and the actual location of these files. I'm working on mitigating that now.

Very nice!

What are the [OPTIONS] that can be passed into release.sh?

Anything you want, really. The InnoSetup-backed script handles command-line options such as --force.

Is there a way to know what all the dependencies are for git-bash.exe, git-cmd.exe and git-gui.exe?

There is, but no automated one. For example, if you never want to call git gui nor gitk, you do not need Tcl/Tk. But the only way to know is to inspect the scripts to determine what requires what.

And it can get quite tricky to get it right. For example, if you do not want Git Bash, you also don't need usr/bin/bash,exe, right? Not so: parts of Git are still implemented as shell scripts, so they need a shell interpreter. So we could use usr/bin/dash.exe instead, correct? Again, not so: in preliminary experiments, many of Git's regression tests failed when using dash instead of bash.

robmen commented 8 years ago

Yeah, sorry, been pulled away for a couple months on other work. Still want to finish what was started but it won't happen in March.

fourpastmidnight commented 8 years ago

I've made good progress on adapting the existing release.sh and make-file-list.sh scripts, creating specific versions for generating the WiX source files. I anticipate completing those tomorrow.

Here's a rough outline of what's next:

Generating the WiX component *.wxs file(s) and check it/them for correctness
Create the WiX code necessary for the most basic installer UI
- This installer will lack the ability to set the console, CRLF options, and SSH client.
- It might not create all shortcuts
Modify the installer to bring it up to par with the existing InnoSetup installer.
- E.g. Implement selecting console, CRLF options, and SSH client selection
Tidy up any loose ends
- I'm hoping by this step, if not 3 above, we'll have a release-ready MSI installer
(Optional) Implement any desired setup enhancements, E.g. ability to not install Git-GUI if you don't want it, or any other enhancements.

dscho commented 8 years ago

@robmen no worries.

@fourpastmidnight excellent progress! Thank you so much! Any chance you can push your current state into https://github.com/fourpastmidnight?tab=repositories (I am curious)?

fourpastmidnight commented 8 years ago

@robmen same here, no worries.

@dscho Yeah, I just installed the SDK, but I'll need to fork the build-extra repo after "cleaning up my mess" ;)

I hope to have the bulk of the shell scripts squared away tonight--I'd like to get eyes on what I've done very soon before I go to much further.

Also, that plan was just my initial thoughts for a roadmap, so please feel free to make any suggestions or provide any other helpful feedback. :)

I'll look into getting build-extra forked. Is this the only repo I'll need to fork?

dscho commented 8 years ago

Is this the only repo I'll need to fork?

Yep.

fourpastmidnight commented 8 years ago

So, I got around to forking the build-extra repo, but I haven't committed anything. I have a fairly good idea of what I'm trying to accomplish, but as I was preparing to finalize the individual pieces, the solution is taking a slightly different turn than I expected. It's no big deal, but this revelation set me back a few hours.

Of course, it didn't help that my computer decided to be special tonight, so tonight was unexpectedly update night. Yay! Um, no, rather annoying. Oh well.

dscho commented 8 years ago

@fourpastmidnight oh yeah, I know those days! Keep up the good work!

fourpastmidnight commented 8 years ago

So that slightly different turn ended up being more complicated to figure out; but also, I wanted to ensure the correctness of what I'm doing as compared to my actual installation of Git for Windows, such as the number of packages that are listed and their constituent files.

I'm trying to finish the initial changes to the release.sh script to update the logic for generating the WiX component files. Once that's done, I'll push it up---I want to get eyes on it once these initial changes are complete. I'm hoping to have this completed by the end of the weekend.

fourpastmidnight commented 8 years ago

So, after dissecting the existing script and trying some things out, I've determined that my idea wasn't going to work as well as I would've liked. But, all is not lost.

The good news is that I've found a way to fix the generation of the GitComponents.wxs file so that the issue mentioned in Pull Request #96 with respect to git-bash.exe and git-cmd.exe not being installed has been resolved.

Also, when creating the installer from the original release.sh, upon examining the generated MSI installer database, it was properly referencing the ProgramFiles64Folder folder into which Git for Windows would be installed. In addition, I see the $WIX_ARCH bash variable being passed on the command line to candle.exe's -arch option. So it seems, based on the examination of the MSI database and the current invocation of candle.exe, that this issue has been resolved in some prior commit.

The other two issues mentioned in that pull request are still issues:

The Start Menu group and shortcut links therein still require additional research. Shortcuts need to be specified in the same component as the file to which they point to. I have some ideas about how this might be done, but I need to research this a bit more.
Off the top of my head, it seems the "post-install.bat file being left behind" issue will require a custom action to be run to execute this file (this file is a self-deleting file--so apparently it's not running as part of the installation). I'm guessing this custom action will need to be set to run immediately (and asynchronously) so that the batch file can execute and delete itself. Not sure how this may affect MSI's file tracking capability for "Repair" installations--need to research this some more. (Currently, the MSI is set to disable "Change" installation options functionality---I don't remember if this same setting disables "Repair" funcitonality. In any event, I would like to re-enable this functionality.)

I'm hoping I'll be able to push up an updated release.sh script later today.

fourpastmidnight commented 8 years ago

@dscho OK, finally pushed up a revised release.sh and created a make-file-list.sh script that's specific to creating the MSI. You can find it here.

As mentioned in the above post:

The issue with git-bash.exe and git-cmd.exe not being installed has been resolved.
Shortcuts are still not created, nor is the Start Menu folder.
I haven't done anything with post-install.bat.
This version of the installer script makes no provisions for an upgradeable Git MSI.

The next step is to resolve the shortcuts and Start Menu folder issues.

fourpastmidnight commented 8 years ago

@dscho I also managed to push up a revision to release.sh that creates a MSI installer with the Start Menu shortcuts for git-bash.exe, git-cmd.exe and git-gui.exe. It doesn't generate any MSI ICE (Internal Consistency Evaluation) errors or warnings. BUT, I haven't tested installing.

I'm wondering, also, if @robmen could take a quick look at this to double-check me on this---shortcuts can be a bit tricky.

The commit is here.

fourpastmidnight commented 8 years ago

The commit adding the Start Menu shortcuts is most probably not a good implementation. Yes, I get no ICE warnings/errors when generating the MSI, but it won't result in correct behavior for the shortcuts. I'm still trying to figure this out.

fourpastmidnight commented 8 years ago

@robmen: I'm attempting to fix the shortcuts in the MSI. I'm getting the "expected" ICE38, ICE43, and ICE57 errors (due to mixing per-machine and per-user concerns---which in this case can be safely ignored). However, I'm also getting ICE69 errors:

D:\Projects\GitForWindowsSDK\usr\src\build-extra\msi\GitComponents.wxs(19) : 
    warning LGHT1076 : 
        ICE69: Mismatched component reference. 
            Entry 'GitBash' of the Shortcut table belongs to component 
            'GitProgramShortcuts'. However, the formatted string in column 'Target' references
            file 'git_bash.exe' which belongs to component 'git_bash.exe'. 
            Components are in the same feature.

D:\Projects\GitForWindowsSDK\usr\src\build-extra\msi\GitComponents.wxs(25) : 
    warning LGHT1076 : 
        ICE69: Mismatched component reference. 
            Entry 'GitCMD' of the Shortcut table belongs to component 
            'GitProgramShortcuts'. However, the formatted string in column 'Target' references 
            file 'git_cmd.exe' which belongs to component 'git_cmd.exe'. 
            Components are in the same feature.

D:\Projects\GitForWindowsSDK\usr\src\build-extra\msi\GitComponents.wxs(31) : 
    warning LGHT1076 : 
        ICE69: Mismatched component reference. 
            Entry 'GitGUI' of the Shortcut table belongs to component 
            'GitProgramShortcuts'. However, the formatted string in column 'Target' references
            file 'git_gui.exe' which belongs to component 'git_gui.exe'. 
            Components are in the same feature.

Could not generate ./bin/Git-2.7.3.0-64-bit.msi

I followed the example at FireGiant. The major difference is I'm installing 3 shortcuts, not 1. Here's the relevant WiX code:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
    <Fragment>
        <ComponentGroup Id="GitComponents">
            .
            .
            .
            <Component Id="GitProgramShortcuts" Directory="GitProgramFolder">
                <Shortcut Id="GitBash"
                          Name="Git Bash"
                          Icon="git.ico"
                          Target="[#git_bash.exe]"
                          WorkingDirectory="WIX_DIR_PROFILE"
                          Arguments="--cd-to-home" />
                <Shortcut Id="GitCMD"
                          Name="Git CMD"
                          Icon="git.ico"
                          Target="[#git_cmd.exe]"
                          WorkingDirectory="WIX_DIR_PROFILE"
                          Arguments="--cd-to-home" />
                <Shortcut Id="GitGUI"
                          Name="Git GUI"
                          Icon="git.ico"
                          Target="[#git_gui.exe]"
                          WorkingDirectory="WIX_DIR_PROFILE" />
                <RemoveFolder Id="GitProgramFolder" On="uninstall" />
                <RegistryValue Root="HKLM"
                               Key="Software\GitForWindows"
                               Name="installed"
                               Type="integer"
                               Value="1"
                               KeyPath="yes" />
            </Component>
            .
            .
            .
            <Component Directory="INSTALLFOLDER:\cmd\">
                <File KeyPath="yes" Id="git_gui.exe" Source="cmd\git-gui.exe" />
            </Component>
            <Component Directory="INSTALLFOLDER">
                <File KeyPath="yes" Id="git_bash.exe" Source="git-bash.exe" />
            </Component>
            <Component Directory="INSTALLFOLDER">
                <File KeyPath="yes" Id="git_cmd.exe" Source="git-cmd.exe" />
            </Component>
            .
            .
            .
        </ComponentGroup>
    </Fragment>
</Wix>

I'll keep looking into it, but I'm really not understanding what the difference is or whether or not I can simply ignore this error.

dscho commented 8 years ago

@fourpastmidnight thank you so much, and sorry for my silence! Rest assured, I am very interested in your work, I just happen to be real busy elsewhere.

fourpastmidnight commented 8 years ago

@dscho no worries.

fourpastmidnight commented 8 years ago

@robmen I think I figured it all out. @dscho After much research, I think I have successfully included Start Menu shortcuts for Git Bash, Git CMD, and Git GUI as part of the installer. I say "think" because I haven't yet tested the installer--though it does not generate any ICE errors or warnings at this point (I turned validation back on by removing the -sval command line switch that was passed to light.exe).

Before proceeding any further, I'm going to setup a virtual machine so I can test the installer as it currently is. You can find the commit here.

robmen commented 8 years ago

Sorry, I'm a bit dark until after March...

fourpastmidnight commented 8 years ago

@robmen No problem; didn't know how dark "dark" was going to be. Hope everything's going well.

fourpastmidnight commented 8 years ago

Just an update: I've been getting some virtual machines set up so I can test installers as I move forward. I will be taking into consideration all the feedback given thus far.

fourpastmidnight commented 8 years ago

Update: I tested the installer from the last commit I made on my branch. Here's what I found:

I logged the installation of the Git for Windows installer. post-install.bat does attempt to execute, but an error is encountered while it runs. The logs gave me some leads to look at to resolve the error(s).
Start Menu shortucts are properly created, per-machine, in the All User's Start Menu. I was able to modify a start menu shortcut (in this case, Git Bash) to "Run as Administrator" (hence how I discovered no permissions issues when running elevated).
The PATH environment variable is properly updated upon installation and removal.
I tried using a custom action supplied with WiX to set the Working Directory property of the Start Menu shortcuts. In native WiX (and MSI database, for that matter), you cannot set the Working Directory property to %HOMEDRIVE%%HOMEPATH%. It's not a valid value. The WixCA and corresponding WIX_DIR_PROFILE property evaluated to the installing user's home directory and path, hard coded (e.g. C:\User\Username). I'm going to need to research another way to do this. I have a few ideas.
Uninstalling generally worked. However, there were some files left behind. Specifically, files that were created post-install in /etc and /dev. Not a big deal--just need to add a component to ensure that the INSTALLDIR\ProgramFiles$(var.Bitness64)Folder\Git directory is removed on uninstall, even if files that weren't installed by the installer exist within those folders.

Other than that, this installer works as well as I had expected it to! Which is great! I feel, as far as the MSI in and of itself is concerned, that this effort is on a very good trajectory.

Next Steps:

Resolve the issue of left behind files.
Do more research and/or attempt to resolve the Start Menu shortcut Working Directory property value.
Look into the error(s) that occur while executing post-install.bat.

dscho commented 8 years ago

I logged the installation of the Git for Windows installer. post-install.bat does attempt to execute, but an error is encountered while it runs. The logs gave me some leads to look at to resolve the error(s).

Oh, nice. Is the error a secret, or can you share it with us?

I tried using a custom action supplied with WiX to set the Working Directory property of the Start Menu shortcuts.

Why not just use the --cd-to-home option of both git-cmd.exe and git-bash.exe?

Uninstalling generally worked. However, there were some files left behind.

Maybe we can add a custom uninstall action? I feel that removing the entire directory wholesale, including files that might have been added by third-party installers, is the inappropriate thing to do.

fourpastmidnight commented 8 years ago

Oh, nice. Is the error a secret, or can you share it with us? I'll post the relevant section of the log file later today. It's a file permissions issue; but that error could also mean several things, such as the file was locked when modification was attempted. Anyway, I'll update this issue with the info.

Why not just use the --cd-to-home option of both git-cmd.exe and git-bash.exe ?

I am already doing that. I was just copying (admittedly, cargo-cult style in this case) what I witnessed as the result of the existing InnoSoft Setup installer when the shortcuts were created. If the --cd-to-home argument is enough, then this is a non-issue.

Maybe we can add a custom uninstall action? I feel that removing the entire directory wholesale, including files that might have been added by third-party installers, is the inappropriate thing to do.

There's only one installer running, Git for Window. If the files are in the program files directory, then upon uninstallation, they should be removed. Otherwise, those files belong elsewhere, such as in C:\ProgramData\Git (for system-wide settings) or in a per-user location for user-specific settings.

The files that were left behind were the ones in /dev and a few in /etc folders of the C:\Program Files\Git installation folder, such as fd, mtab and hosts. These should be removed if one completely uninstalls Git for Windows from their machine.

One of the most annoying aspects of incorrect installers are those that leave stray, useless files polluting the filesystem and Windows Registry (the files are useless once the program that uses them is no longer installed). When I remove a program, with the exception of (possibly) user-setting data (in case I decide to reinstall), I want no trace of the program left on my computer.

In this case, it's just an oversight in the authoring of the installer. I've seen How-Tos in the WiX documentation on how to accomplish this--it's a perfectly normal thing to find when developing an installer with a well-known solution (I just don't know it off the top of my head).

dscho commented 8 years ago

Maybe we can add a custom uninstall action? I feel that removing the entire directory wholesale, including files that might have been added by third-party installers, is the inappropriate thing to do.

There's only one installer running, Git for Window. If the files are in the program files directory, then upon uninstallation, they should be removed. Otherwise, those files belong elsewhere, such as in C:\ProgramData\Git (for system-wide settings) or in a per-user location for user-specific settings.

That is not always possible. Take credential helpers, for example. Or third-party remote helpers. They need to be somewhere on the PATH visible from Git for Windows. The only appropriate place for that is in C:\Program Files\Git\mingw64\libexec\git-core (or the 32-bit equivalent).

Assuming that it is okay to uninstall them is incorrect.

The files that were left behind were the ones in /dev and a few in /etc folders of the C:\Program Files\Git installation folder, such as fd, mtab and hosts. These should be removed if one completely uninstalls Git for Windows from their machine.

Agreed. We know that those files are installed by us, though. That is why it is appropriate to remove them upon uninstallation.

fourpastmidnight commented 8 years ago

That is not always possible. Take credential helpers, for example. Or third-party remote helpers. They need to be somewhere on the PATH visible from Git for Windows. The only appropriate place for that is in C:\Program Files\Git\mingw64\libexec\git-core (or the 32-bit equivalent).

That's a good point you make. I would argue, then, that the git-credential-manager should be handled as a "bundled" install--meaing, it's distributed and installed (by default, unless unselected) with Git, but it should be it's own installation outright (in its own filesystem location independent of git--after all, you don't need git-credential-manager, but it's awfully nice to have), putting itself on the PATH so git and other programs can easily invoke its services. This avoids the whole complication about what should/shouldn't be uninstalled. This provides a much cleaner install/uninstall scenario for the end-user.

dscho commented 8 years ago

Unfortunately, it is already practice by some third-party installers to reuse our path... So I guess we have to work with it.

fourpastmidnight commented 8 years ago

I was just looking over the Git Credential Manager for Windows repo. I guess you're right. Well then, scratch that item off the list. ;)

fourpastmidnight commented 8 years ago

Here's that MSI log where the Custom Action executes the post-install.bat file:

MSI (s) (C4:04) [00:28:35:307]: Executing op: ActionStart(Name=ExecPostInstallBat,,)
MSI (s) (C4:04) [00:28:35:526]: Executing op: CustomActionSchedule(Action=ExecPostInstallBat,ActionType=3137,Source=BinaryData,Target=WixQuietExec64,CustomActionData="C:\Windows\system32\cmd.exe" /c "C:\Program Files\Git\post-install.bat")
MSI (s) (C4:34) [00:28:35:651]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI363B.tmp, Entrypoint: WixQuietExec64
MSI (s) (C4:0C) [00:28:35:885]: Generating random cookie.
MSI (s) (C4:0C) [00:28:36:167]: Created Custom Action Server with PID 3028 (0xBD4).
MSI (s) (C4:C4) [00:28:38:167]: Running as a service.
MSI (s) (C4:C4) [00:28:38:432]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
WixQuietExec64:  mkdir: cannot change permissions of '/dev/shm': Permission denied
WixQuietExec64:  mkdir: cannot change permissions of '/dev/mqueue': Permission denied
WixQuietExec64:  'C:\\Windows\\System32\\drivers\\etc\\hosts' -> '/etc/hosts'
WixQuietExec64:  'C:\\Windows\\System32\\drivers\\etc\\protocol' -> '/etc/protocols'
WixQuietExec64:  'C:\\Windows\\System32\\drivers\\etc\\services' -> '/etc/services'
WixQuietExec64:  'C:\\Windows\\System32\\drivers\\etc\\networks' -> '/etc/networks'
WixQuietExec64:  The batch file cannot be found.
WixQuietExec64:  Error 0x80070001: Command line returned an error.
WixQuietExec64:  Error 0x80070001: QuietExec64 Failed
WixQuietExec64:  Error 0x80070001: Failed in ExecCommon method
CustomAction ExecPostInstallBat returned actual error code 1603 but will be translated to success due to continue marking

Now, the line where it says The batch file cannot be found. I'm fairly certain has nothing to do with the error at hand and that this line is here because the post-install.bat file deletes itself. (I also believe this may be the cause of those Error 0x80070001 lines.) I believe these two lines, however, are what I need to focus my attention on for resolving the issue:

WixQuietExec64:  mkdir: cannot change permissions of '/dev/shm': Permission denied
WixQuietExec64:  mkdir: cannot change permissions of '/dev/mqueue': Permission denied

I tried changing some things in the installer, such as user impersonation, deferred vs. immediate execution, when it's scheduled to run, etc,, all to no avail--either light.exe complained about mis-authoring of the MSI (i.e. ICE violations) or the installer worked no better or worse than it had before, producing the same log output.

dscho commented 8 years ago

Now, the line where it says The batch file cannot be found.

That's easily explained: the post-install.bat script is supposed to delete itself, similar to Mission Impossible's mission descriptions.

WixQuietExec64: mkdir: cannot change permissions of '/dev/shm': Permission denied WixQuietExec64: mkdir: cannot change permissions of '/dev/mqueue': Permission denied

Those two are expected. As I hinted earlier, the POSIX permission system assumed by the mkdir command (it tries to execute mkdir -m1777 /dev/shm) is simply incompatible with Windows' ACLs, same for /dev/mqueue/. It is no use to create the directories manually, though, because the same init script (provided by MSYS2, so it is a bit funny why they insist on the 1777 permission) will try to chmod 1777 /dev/shm if that directory already exists.

So I think we will have to live with that message.

What we do not have to live with is that the /etc/post-install/*.post scripts run again after installation. The purpose of the post-install.bat script is to run those scripts, including 99-post-install-cleanup.post which is supposed to just nuke all of the /etc/post-install/*.post scripts.

And that is exactly where things go wrong. The 99-post-install-cleanup.pots script reads thusly:

# Only remove post-install scripts if we're not in the SDK.
# They need to be there to build the installer packages.
if [ -f /ReleaseNotes.html -o -f /README.portable ]
then
  rm -rf /etc/post-install
fi

The idea is that this file is not allowed to nuke anything when run in the SDK. Because if it does, then the files are gone by the time when we need to include them in the installer!

That means that we have to come up with a way to tell that we're not in the SDK, e.g. by including the ReleaseNotes.html file (which we should do anyway, because the official Git for Windows installer includes said file, too).

dscho commented 8 years ago

Here's that MSI log

@fourpastmidnight could you please educate me where I can find that log?

fourpastmidnight commented 8 years ago

@dscho: The portion of the log I posted above is the only portion of the 11MB log file that's relevant. Everything else worked as expected. But, I've attached it for you.

Thanks for the explanations above. I'll look into authoring the ReleaseNotes.html file into the MSI--it was on my list of things to do, I just didn't realize it played a "critical" role in the installation. Git_Install-verbose.log.txt

fourpastmidnight commented 8 years ago

@dscho: I authored in the RealeaseNotes.html file and "magical" things happened:

post-install.bat ran, and /etc/post-install/ was removed during installation.
While there are still those error messages in the MSI log re: /dev/shm and /dev/mqueue (which as has been noted is expected), those errors are no longer present when starting Git Bash after installation--presumably because the various /etc/post-install/*-post-install*.post files got executed due to the presence of ReleaseNotes.html.

To recap where we are:

The installer installs Git for Windows per-machine.
The installer correctly copies all Git for Windows files, including
- git-bash.exe
- git-cmd.exe, and
- git-gui.exe
The installer correctly installs Start Menu shortcuts in the per-machine Start Menu in a Git folder.
ReleaseNotes.html is installed in the main installation directory.
- As a result of this, the /etc/post-install/*-post-install*.post scripts are executed and removed.
- It appears the various /dev files/folders get their permissions set correctly, so no more errors appear when starting Git Bash.
- NOTE: A Start Menu shortcut is not created for this file. Do you want one created for it?
The installer appropriately modifies the system PATH environment variable on installation and uninstallation.
The installer creates the appropriate Windows registry entries in HKLM\SOFTWARE\GitForWindows.
- That's not to say that all required entries are created--just the ones that are necessarily required for clean installation/uninstallation by msiexec. For example, the InnoSetup installer creates an entry called LibExecPath. This is not yet authored into the installer.

I'll try to get the latest changes pushed up as soon as I have a chance. The next few days are going to be a bit busy for me.

After I get these changes pushed up, I'll begin to work on filling in the details by pouring over the InnoSetup scripts. At the same time, I'll be making note of the various UI requirements (e.g. implementing the ability to choose the console window to use, CRLF options, etc.).

There's still quite a bit of work ahead, but significant progress has been made.

dscho commented 8 years ago

The portion of the log I posted above is the only portion of the 11MB log file that's relevant.

Whoops. I meant to ask instead: where can I find the log in my setup? (I am really a noob when it comes to MSI installers...).

BTW great progress, and thanks so much for your detailed write-up.

FWIW the DisplayVersion registry entry is more important than the LibExecPath entry, as the former is used by third-party software to determine whether Git for Windows is installed or not.

fourpastmidnight commented 8 years ago

@dscho: You have to run msiexec from the command line:

C:\> msiexec /i {package_name.msi} /l[log_options] {path\to\logfile.log}

Here are the options to /l:

Logging Options
    /l[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] <LogFile>
        i - Status messages
        w - Nonfatal warnings
        e - All error messages
        a - Start up of actions
        r - Action-specific records
        u - User requests
        c - Initial UI parameters
        m - Out-of-memory or fatal exit information
        o - Out-of-disk-space messages
        p - Terminal properties
        v - Verbose output
        x - Extra debugging information
        + - Append to existing log file
        ! - Flush each line to the log
        * - Log all information, except for v and x options
    /log <LogFile>
        Equivalent of /l* <LogFile>

/l*v! produces that 11MB monstrosity in this case ;). I found that /lier! worked well enough. You only need the heavy duty verobsity when you have a real stumper of a problem. You can find all the other available options via msiexec /?.

I'll be sure to include that Registry value; thanks for the heads-up.

fourpastmidnight commented 8 years ago

@dscho: I found some time to push up my latest changes of the working MSI installer. As I said, there's still a lot of work to be done yet. I hope my commits are more fine-grained for you this time, with better explanations of the changes that were made.

dscho commented 8 years ago

@fourpastmidnight thanks! How about opening a Pull Request? That way I can keep better track of the iterations and can help more efficiently...

dscho commented 8 years ago

You have to run msiexec from the command line:

C:\> msiexec /i {package_name.msi} /l[log_options] {path\to\logfile.log}

@fourpastmidnight thanks!

fourpastmidnight commented 8 years ago

Sorry, been busy with work the past couple of days. I hope to get back to work on this over the weekend.

dscho commented 8 years ago

@fourpastmidnight no worries, I am really glad that you are giving the MSI installer some love.

fourpastmidnight commented 8 years ago

Just checking in--I am making some slow progress on the UI front. I'm just taking it slow, making sure I account for everything that needs to be accounted for.

fourpastmidnight commented 8 years ago

Checking in--I've been working on this every night and on weekends. I'm getting into the "finer" details of the installer and it's just been slower going than it was when I first started this. Things are coming along and I hope to have some progress to show soon.

dscho commented 8 years ago

Thanks for the update!

robmen commented 8 years ago

I've rolled up the minimal set of changes to address the feedback at the bottom of git-for-windows/build-extra#96 with PR: git-for-windows/build-extra#112.

If 112 looks good, it'd be awesome to break down any remaining work @dscho wants completed into smaller issues so we can effectively divide and conquer.

git-for-windows / git

Installer does not roll back properly #682