bugGNU Zile (Zile is Lossy Emacs) - Bugs: bug #34076, git2cl in buildreq in...

 
 

bug #34076: git2cl in buildreq in bootstrap.conf fails

Submitted by:  Reuben Thomas <rrt>
Submitted on:  Fri 19 Aug 2011 05:22:25 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Status: InvalidAssigned to: None
Open/Closed: ClosedRelease: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 21 Aug 2011 11:41:37 AM UTC, comment #4:

Hmm... wait a second, when it comes to real releases, we'll have taken the time to test Zile *with one particular checkout* of the gnulib submodule. Rerunning bootstrap inside a release tarball will very likely pull in a completely different set of gnulib module implementations, potentially with a very different set of dependencies, and certainly in a configuration progressively more different from what was used at the time the release tarball was rolled up. And then we get to support that mess when distributions put it on a CD and give it to a few hundred thousand users. This has actually happened with M4, I forget the details, but a big distro (maybe ubuntu) took m4-1.4.12 (or so) and rebootstrapped it with newer gnulib and newer libtool, causing it to break subtly and the mailing list start to fill up with 'm4 is buggy as hell' complaints, until Eric figured out what had happened.

Anyway, even after editing git2cl out of bootstrap.conf, bootstrap will still warn that bootstrapping outside the git checkout directory is likely to lead to trouble, although it will run to completion.

So, on reflection, I'd rather tell the nix folks not to mess with the particular selection of gnulib files any given release tarball was designed to work with, and to clone our git repo if they want to try messing with bleeding edge versions, or else to stick with the post-bootstrap files if they want to build from a stable release.

</rant> ;)

Gary V. Vaughan <gary>
Project Administrator
Sun 21 Aug 2011 11:28:05 AM UTC, comment #3:

Well git2cl cannot work outside of a git repository in any case.

Even so, that brings up an interesting question. So far I've thought that if you are in a position to be running Zile bootstrap, then it's better to know sooner rather than later if you are missing some of the tools you'll need to be able to run all of the Make rules we provide (make distcheck being the case in point).

None-the-less, I guess it's also legitimate to soften that a little, and assert that you might be interested in running the Zile bootstrap just to get a HEAD binary, in which case you don't need all the tools I've listed in bootstrap.conf for buildreq.

The nix build may be analogous to the HomeBrew Formula I wrote for Zile HEAD (https://github.com/gvvaughan/homebrew-alt/blob/alternate/duplicates/zile.rb) where I simply delete git2cl and gpg from the list so that you can build and install the latest Zile binary without adding those two extra packages (which, you may very well not need for anything else!).

We should consider whether to advise the nix folks to edit their local bootstrap before running it as I did for brew, or if it's better for our adoption rates to remove git2cl and gpg from buildreq in our repo, and rely on being able to figure out why distcheck and/or release rules don't work when those tool are missing without the early failure at bootstrap time... I have no strong preference, so I'm happy to implement whatever you prefer.

Gary V. Vaughan <gary>
Project Administrator
Sun 21 Aug 2011 06:55:04 AM UTC, comment #2:

Because git2cl doesn't accept --version, if it is run outside a git repository, then it fails.

(Of course, one would not normally run bootstrap except in a git checkout; but that's what nix does (in a tarball build); I'll try to find out why.)

Reuben Thomas <rrt>
Project Administrator
Sun 21 Aug 2011 04:04:59 AM UTC, comment #1:

Zile ./bootstrap has many improvements over the gnulib bootstrap, including:

If `some-program --version </dev/null >/dev/null` exits normally, it can be listed in buildreq with a version of `-', so at least you can list (unversioned) build requirements for tools that don't respond to --version.

Actually, git2cl doesn't even need this particular improvement, because ./bootstrap first tries `git2cl --version`, and since that succeeds (it actually ignores --version and goes ahead and outputs the ChangeLog) and there is no version check required then the buildreq check is satisfied that there is a program called git2cl on the PATH that exits normally when called with --version.

Is there an actual bug here? Or was it just an observation?

Gary V. Vaughan <gary>
Project Administrator
Fri 19 Aug 2011 05:22:25 PM UTC, original submission:

git2cl doesn't respond to --version, which is required by programs listed in buildreq. Thanks to Rob Vermass for the heads-up.

I hadn't noticed because git2cl simply ignores the argument, and so it still succeeds if run inside a git repo.

Reuben Thomas <rrt>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by gary (Posted a comment)
  • -unavailable- added by rrt (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 06 Sep 2011 01:37:34 PM UTCrrtStatusWorks For Me=>Invalid
      Open/ClosedOpen=>Closed
    Sun 21 Aug 2011 04:04:59 AM UTCgaryStatusNone=>Works For Me

    Back to the top


    Powered by Savane 3.1-cleanup1