Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1967 MinGW.org-WSL installs everything as executable

WSL
closed
None
Bug
fixed
Feature_in_WSL_4.0
True
2014-09-17
2013-05-05
Keith Marshall
No

I've just built WSL from git master. On running:

make prefix=`pwd`/staged install

every file throughout the 'staged' tree is marked as executable, where none actually should be.

Following up, in Makefile.in, I see several instances of:

$(INSTALL) $(INSTALL_FLAGS) ...

This is wrong; every such instance should be:

$(INSTALL_DATA) ...

with INSTALL_DATA as already defined by AC_PROG_INSTALL, and made available by AC_SUBST, when running the existing configure script.

Attached patch corrects this defect. Note that I have left the $(INSTALL_FLAGS) in place, as an adjunct to the definition of INSTALL_DATA. Feel free to keep it so, if you wish, but my preference would be to remove it; I'm aware of no standard usage which mandates it, and it does seem of dubious value.

1 Attachments

Discussion

  • Earnie Boyd
    Earnie Boyd
    2013-05-06

    • status: assigned --> open
    • assigned_to: Earnie Boyd --> Keith Marshall
    • Resolution: none --> accepted
    • Category: Unknown --> Feature_in_WSL_4.0
     
  • Earnie Boyd
    Earnie Boyd
    2013-05-06

    This looks good to me. The INSTALL_FLAGS was mimicked from the original, already obviously bad, Makefile.in file; you may remove it as needed.

     
  • Keith Marshall
    Keith Marshall
    2013-05-06

    I assume that you've assigned this back to me, because you'd like me to go ahead and commit it myself? That's okay; I can do so, but I don't want to push from my current hg clone, because AFAIK hg-git still mishandles git's submodule gitlinks, so I'll need to get my hands dirty with git itself here.

    Did I mention that I utterly detest git? With a passion? Yes, of course I did; the question is rhetorical, but notwithstanding that, (and that submodule handling is amongst git's most disgusting failures), I'm confused...

    My original hg clone shows that your default working branch is called "4.0-dev", and that "master" lags a long way behind this. I thought we'd previously agreed that main-line development should progress along "master", with branches such as "4.0-dev" being cut to ring-fence release specifics. This doesn't appear to be the case here. Having pulled down a git clone, I'm placed on "master" by default, and that bears little resemblance to the version I generated my patch against. I'm guessing that I should update to "4.0-dev" before applying the patch, but should that not also be merged back to "master"?

     
  • Earnie Boyd
    Earnie Boyd
    2013-05-07

    I did merge the 4.0-dev code to master before tagging. And the browse view of the repository show the ChangeLog data matches between the two branches.

    4.0-dev is the working branch for that release. We should merge 4.0-dev with master before uploading the release and make a proper tag to identify it as I did with 4.0-rc1.

    If you would rather I apply the patch, you can reassign it back to me. Git isn't bad once you have it configured. I know nothing about HG so I can't speak to it. And then Chuck says submodules shouldn't be used regardless of the repository engine but I see the point of build-aux for a common configure machinery.

     
    Last edit: Keith Marshall 2013-05-08
  • Keith Marshall
    Keith Marshall
    2013-05-08

    SF seems to have dropped my original reply on the floor; says I edited
    the ticket, (I didn't; I replied), but the actual content is invisible!

    Trying again, (via e-mail)...

    On 07/05/13 14:38, Earnie Boyd wrote:

    I did merge the 4.0-dev code to master before tagging. And the
    browse view of the repository show the ChangeLog data matches
    between the two branches.

    Okay. I see that now; I'd managed to clone the old repository, (from
    before migration to Allura); of course it's hopelessly out of date.
    Time it was dead and buried, methinks; why didn't SF just take it down
    automatically, after a reasonable interval?

    I now have a correctly updated clone, and see "master" and "4.0-dev" in
    equivalent state.

    BTW, .gitmodules still carries a reference to the defunct repository,
    for the "build-aux" sub-module; I have a local commit on "master", to
    correct this.

    4.0-dev is the working branch for that release.

    Okay. Should I check out "4.0-dev", then, before I apply changes? How
    do we then keep "master" and "4.0-dev" in lock-step?

    We should merge 4.0-dev with master before uploading the release and
    make a proper tag to identify it as I did with 4.0-rc1.

    Seems kind of backwards to me. I would expect to see the main line of
    development on "master", with branches emerging from that, as releases
    are prepared, and tags attached to those branches, as each release
    milestone is achieved. Tags are not synonymous with branches.

    If you would rather I apply the patch, you can reassign it back to
    me.

    It's probably better if we don't rely on you, as sole committer, but we
    do all need a shared understanding of the development model, so we all
    pull in the same direction.

    Git isn't bad once you have it configured.

    It's the extent of that necessary configuration that I find so utterly
    frustrating; IMO, hg works much better OOTB, and offers a much more
    logical (friendlier) command structure, (particularly for users who are
    already familiar with other SCMs, such as CVS). Whatever you may say, I
    find git to be a serious obstacle to productivity; (definitely not
    Linus' finest effort). Google "git sucks", and you'll see I'm not alone
    in thinking that git is as repulsive by nature as it is by name
    (http://oxforddictionaries.com/definition/english/git?q=git).

    I know nothing about HG so I can't speak to it.

    From a user's perspective, hg and git appear to offer a superficially
    similar repository organisation; hg's command set just seems infinitely
    more logical and user friendly, (hence more productive). Indeed, with
    the exception of the known bug in handling gitlinks for sub-modules, hg
    works perfectly well with a git repository, yielding a much nicer user
    experience than native git, IMO.

    And then Chuck says submodules shouldn't be used regardless of the
    repository engine

    If git were my basis for reference, I'd probably agree with him; hg's
    implementation is light years ahead...

    but I see the point of build-aux for a common configure machinery.

    Yes, it is a good fit here.

     
    • Earnie Boyd
      Earnie Boyd
      2013-05-08

      SF seems to have dropped my original reply on the floor; says I edited
      the ticket, (I didn't; I replied), but the actual content is invisible!

      I've seen that not work as well. I suppose a support ticket for it is in order but I don't really want to.

      why didn't SF just take it down automatically, after a reasonable interval?

      We probably should go rename the directories or just remove them.

      Okay. Should I check out "4.0-dev", then, before I apply changes? How
      do we then keep "master" and "4.0-dev" in lock-step?

      Yes, checkout 4.0-dev to make the change and push origin 4.0-dev. We'll merge to master just before another release.

      Seems kind of backwards to me. I would expect to see the main line of
      development on "master", with branches emerging from that, as releases
      are prepared, and tags attached to those branches, as each release
      milestone is achieved. Tags are not synonymous with branches.

      Master is the point of reference for a new branch or a new tag. Development always happens on a branch other than master leaving master in an almost pristine state. Once a development cycle completes it is then merged to master and tagged before releasing. At least that is what I've been accustomed to.

      It's probably better if we don't rely on you, as sole committer, but we
      do all need a shared understanding of the development model, so we all
      pull in the same direction.

      I agree. We should write up a wiki page for it so we can point others to it.

       
      • Earnie Boyd
        Earnie Boyd
        2013-05-08

        SF seems to have dropped my original reply on the floor; says I edited the ticket, (I didn't; I replied), but the actual content is invisible!

        I've seen that not work as well. I suppose a support ticket for it is in order but I don't really want to.

        BTW, if you leave a ticket page open in the browser "too long" it will cause an edit or post to not post. I do have a support ticket for that case open. So if you have a ticket open, leave for a while and come back to it, be sure to refresh the page first.

         
        Last edit: Earnie Boyd 2013-05-08
  • Keith Marshall
    Keith Marshall
    2013-05-13

    • status: open --> closed
    • Resolution: accepted --> fixed