#2008 MSYS should use mingw-get's post-install scripting capability

[Keith Marshall]

mingw-get has supported a post-install scripting capability since version 0.5. MSYS should exploit this capability to install its desktop or start-menu shortcuts, (there's a JScript helper installed with mingw-get, to facilitate this), and to invoke it's own post-install script.

[Cesar Strauss]

I attach my first try for the shortcut handling in the post-install hook. I was inspired on the post-install hooks of mingw-get-gui.

However, this line seems a bit "hackish":

msys_root = os.getenv( "APPROOT" ).."msys\\1.0\\"

Ideally, there should be an API to retrieve the root from the profile.xml. Something like:

msys_root = setup.sysroot_path("MSYS")

[Cesar Strauss]

And here is may take on initializing the /mingw entry of /etc/fstab.

[Keith Marshall]

Thanks, Cesar.

I'll take a look at your scripts, when I have a bit more time. I do somewhat disagree on the "hackish" use of Lua's os.getenv -- an established and tested API -- over a bespoke (currently undeveloped and untested) setup.sysroot_path API. It is possible, in this case however, that $APPROOT may not be the most appropriate of the environment variables defined by mingw-get, to inspect. For reference, when it invokes any Lua script, mingw-get will always have defined:

  $APPROOT  --  mingw-get's own installation root path
  $SYSROOT  --  the sysroot path for the package being processed

together with a set of additional reference paths for every subsystem declared in profile.xml's system_map:

  $<SUBSYSTEM>_SYSROOT  --  the sysroot path for named <SUBSYSTEM>

where <SUBSYSTEM> is replaced by the uppercase form of each subsystem name, (so for our default profile.xml configuration, we will have $MINGW32_SYSROOT and $MSYS_SYSROOT). Maybe, in this case:

msys_root = os.getenv( "MSYS_SYSROOT" )

would be the appropriate API choice?

[Keith Marshall]

I'm wondering if msys-core is the most appropriate attachment point for the post-install hooks? Surely, since its purpose is to start up a shell session, msys-bash would be more logical for the shortcut creation hook? Maybe also, although less obviously so, for the fstab setup hook?

[Earnie Boyd]

IMO, the creation of the shortcut belongs in the msys-base package and the creation of fstab belongs with msys-bash.

Another possibility is to create packages msys-shortcut and msys-fstab that other packages require to do the post-install and post-uninstall steps.

[Keith Marshall]

IMO, the creation of the shortcut belongs in the msys-base package ...

The problem with that would be that msys-tiny would then need to replicate that same script, whereas attaching it to msys-bash would allow both msys-tiny and msys-base to benefit from a single instance, while removing the burden from msys-core, for a feature that, IMO, logically belongs to msys-bash alone.

Another possibility is to create packages msys-shortcut and msys-fstab ...

That's certainly a possibility which may be worthy of consideration; it does mean two additional (mostly redundant) meta-packages, but a potential advantage would be that users could then select either one of those to add the shortcut or the fstab to an existing installation which was previously lacking them, without reinstalling the underlying real package.

[Keith Marshall]

I'd like to push out an implementation for the shortcuts, based on the code I showed previously, but...

IMO, the creation of the shortcut belongs in the msys-base package and the creation of fstab belongs with msys-bash.

surely this is the wrong way round; the shortcut belongs with bash/sh, (because that's what it invokes), and the fstab creation really belongs with msys-core, (because it relates to core infrastructure), which is a fundamental requirement of msys-base, (and msys-tiny), along with everything else related to MSYS.

Anyway, my proposed implementation for shortcuts consists of a separate .lnk component, which requires msys-bash; each of msys-tiny and msys-base require the .lnk component, (in addition to msys-bash anyway, and msys-core).

[Keith Marshall]

I added this:

      <component class="lnk">
        <release tarname="bash-3.1.17-4-msys-1.0.16-lnk.tar.lzma">
          <download tarname="none" />
        </release>
        <action class="post-install">
          setup = require "setup"
          sysroot_prefix = os.getenv( "MSYS_SYSROOT" )
          if sysroot_prefix then
             setup.create_shortcuts(
               '--description="Start MinGW Shell"',
               '--icon="'..sysroot_prefix..'\\msys.ico"',
                sysroot_prefix..'\\msys.bat', '"MinGW Shell"'
             )
          end
        </action>
        <action class="pre-remove">
          setup = require "setup"
          sysroot_prefix = os.getenv( "MSYS_SYSROOT" )
          if sysroot_prefix then
             setup.delete_shortcuts(
               "--if-linked="..sysroot_prefix.."\\msys.bat",
               "--force", '"MinGW Shell"'
             )
          end
        </action>
      </component>

to my local copy of msys-bash.xml; with the changes I've committed to mingw-get master over the last few days, and these preferences for the gui client added into my profile.xml:

  <preferences client="gui">
    <!--
      The preceding "preferences" section applies exclusively to the
      CLI client, (where command line options may be used); here, we
      specify defaults for the GUI client, (which provides no support
      for command line options), such that shortcuts will be created
      on the desktop, and in the start menu, for the current user.

      Note that matching of the "client" attribute will be performed
      case-insensitively, against a keyword defined by the respective
      client; any "preferences" section with no "client" assignment
      will be matched for ALL clients.
    -->

    <option name="desktop" />
    <option name="start-menu" />
  </preferences>

(with the existing preferences designated as client="cli"), it WJFFM from both CLI and GUI.

[Cesar Strauss]

I tested your msys-bash-lnk component and it seems to handle the shortcuts very well.

However, I think msys-bash-lnk should require the existence of msys.bat itself, which is provided by msys-core-ext. On the other hand, there is no need for msys-bash-lnk to require msys-bash-bin (it will be provided indirectly by msys-core-ext).

I agree with msys-base requiring msys-bash-lnk. However, msys-tiny doesn't have msys.bat, so having a shortcut to it doesn't make sense.

[Keith Marshall]

Finally got around to looking at the fstab element; FWIW, I think it should be associated with msys-core-bin itself, (rather than msys-core-ext), whereas I do still think that the shortcuts element belongs with msys-bash-bin.

What do you think of the attached adaptation of msys-core, to deliver the fstab element, and to initialize /etc/fstab? Delivered in the form of a minor upgrade from msys-core-1.0.18-1 to msys-core-1.0.18-2, it offers:

1. /etc/fstab.sample delivered with the package, but adjusted at installation time, to reflect actual installation choice for /mingw mount point association.

2. /etc/fstab created if necessary, with correct mapping of /mingw mount point.

3. Any pre-existing /etc/fstab content preserved, but with /mingw mount point adjusted to match installation choice in mingw-get's profile.xml.

[Cesar Strauss]

Seems great! I'll take a deeper look.

Note that I am preparing right now the release of MSYS 1.0.19, due to an important bug fix. I'll integrate your work on this new release. There is no need to create a minor upgrade.

Regards,

Cesar

[Cesar Strauss]

Any pre-existing /etc/fstab content preserved, but with /mingw mount point adjusted to match installation choice in mingw-get's profile.xml.

I disagree with this. If the user already has a fstab file, we can assume it's already taylored to the user's need. Maybe the user is trying out a different compiler, mounted on /mingw, in which case silently overwriting the fstab entry after an update would be confusing.

Otherwise the new postinstall script looks good. The fstab parsing code could be removed, in case we do decide to drop the fstab update functionality.

Regards,
Cesar

[Keith Marshall]

Gosh! It's been about sixteen months since I contributed that. No criticism intended, but I've forgotten most of the motivation behind my choices at the time.

If I'm understanding you correctly, we're in agreement on my aspects (1) and (2), but you have reservations about (3); your concern is that a user may have remapped the /mingw mount point to something which might differ from mingw-get's concept of what should be mounted there, and so wouldn't want an MSYS upgrade to override their change, and reassert the $MINGW32_SYSROOT assignment? That being so, I accept and agree with your reservation.

I would recommend that we commit the script as I've provided it, before we modify it to preserve any user's mount point adjustment. That way, we preserve the code to achieve that default mount point assertion, but don't ultimately deliver it. Then, if any user subsequently asks why we don't just assert it, (as someone likely will), we can show how we considered doing so, and explain why we ultimately rejected the idea.

I'm back home now, after six months in Australia and New Zealand, so may be able to devote a bit more time to MinGW issues; would you like me to revisit the script in question?

[Keith Marshall]

Okay, I've now taken some time to review what I originally submitted; I think my rationale for always rewriting /etc/fstab was to ensure that the configuration intent is honoured, to ensure that the /mingw mount point will be mapped. See, if the user has a pre-existing /etc/fstab which lacks a /mingw mount point mapping, you lose this intent, if you don't rewrite the file.

However, I do accept your reservation that a pre-existing, user assigned, /mingw mount point mapping should be preserved as-is, and the fstab.lua script, which I originally provided, fails to honour this. The attached patch, to my original submission, corrects this.

[Keith Marshall]

Oops! Forgot to update the copyright notice for year of revision, in the previous patch. Corrected version attached.

[Cesar Strauss]

Gosh! It's been about sixteen months since I contributed that.

Indeed. I have been distracted by some personal projects and lack of time.

I would recommend that we commit the script as I've provided it, before we modify it to preserve any user's mount point adjustment.

Agreed.

However, I do accept your reservation that a pre-existing, user assigned, /mingw mount point mapping should be preserved as-is, and the fstab.lua script, which I originally provided, fails to honour this. The attached patch, to my original submission, corrects this.

Thanks. The patch looks fine to me.

A few more comments:

1) The script deletes commented out lines from /etc/fstab. This is not nice, IMHO. The user may have put there a commentary about the following mount point. Or it could be a commented out mount specification that the user does not need at the moment.

2) The <action> in msys-core.xml should check the existence of fstab.lua before loading it. Otherwise, when installing a previous version that does not ship fstab.lua, mingw-get raises a lua error about a missing fstab module.

Thanks,
Cesar

[Cesar Strauss]

I would recommend that we commit the script as I've provided it, before we modify it to preserve any user's mount point adjustment.

Agreed.

Done.

[Cesar Strauss]

Dear Keith,

I added your new lnk component to the latest release of MSYS Bash 3.1.23-1.

I'll handle the update to msys-base, next.

Thanks,
Cesar

[Cesar Strauss]

The fstab handling script was released in msys-core version 1.0.19.
Thanks Keith for you help.
Regards,
Cesar