git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: "docs: stop using asciidoc no-inline-literal" breaks asciidoc 8.2.5

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
May 29, 2012, 12:31 UTC
Message-ID
<CACBZZX5iOB5PCZUCX5ksR4hpw+DTLTaP4jOnyHAJ8hZVe9xo5w@mail.gmail.com>
In-Reply-To
<87ehq3mbxg.fsf@thomas.inf.ethz.ch>
On Tue, May 29, 2012 at 2:03 PM, Thomas Rast <trast@inf.ethz.ch> wrote:
Show 15 quoted lines
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Jeff King's 6cf378f0cbe7c7f944637892caeb9058c90a185a broke my Git
>> build on CentOS 5.5. The patch suggests that it only breaks
>> compatibility with asciidoc 7 but that isn't actually the case.
>
> The commit message of 6cf378f0 is not correct in that respect.  My
> ancient 71c020c5 has the right numbers: asciidoc 8.4.1 is the one that
> introduced the new inline-literal behavior.  Based on my little survey
> in
>
>  http://thread.gmane.org/gmane.comp.version-control.git/191738/focus=191790
>
> we decided that "nobody" really uses such an old asciidoc any more.
> Evidently you are a counterexample.
Well, me and and others using current production RHEL releases:
    $ cat /etc/redhat-release && yum info asciidoc.noarch|grep Version
    CentOS release 5.5 (Final)
    Version    : 8.1.0
    $ cat /etc/redhat-release && yum info asciidoc.noarch|grep Version
    CentOS release 5.5 (Final)
    Version    : 8.2.5

I can't quite recall how I ended up with 8.2.5 on one of the boxes, but it seems 8.1.0 may actually be the stock version.

Show 11 quoted lines
>> I suggest just ejecting this patch and trying again, these RedHat
>> systems are still used in a lot of environments, especially by various
>> companies.
>
> Do you/they have to *build* the docs, as opposed to using the prebuilt
> ones coming from Junio?  Perhaps we can make it so 'make man' refuses to
> run if asciidoc is too old, and give a message to the effect that you
> should 'make quick-install-man' instead.
>
> Otherwise we'll be working around the f{asterisk}{asterisk}{asterisk}ing
> quoting rules for years to come.

I could personally change my build process to do something else, but the reason I'm running "all doc" occasionally on this older toolchain is to smoke out issues like these for other users on slightly older toolchains as well.

I think it's too soon to break the stock toolchain on systems as recent as RHEL 5.5 in the name of slightly nicer asciidoc syntax.

We could also keep the nice syntax and have some simple sed-based pre-processor that converts the syntax to the older and more widely supported version.

Or we could just decide to break RHEL 5 and systems released at a similar time, but that isn't what the patch suggested it was doing, so we should probably step back and ponder whether that's something we want to do.

Personally I think having a hard dependency on a version of a software package released more recently than 2007 (8.2.5 came out on 2007-11-18) is way too soon, it would be similar to breaking on a GCC older than 4.2.0 which came out around the same time.

Previous: Thomas RastNext: Junio C Hamano
Message 3 of 15 in “"docs: stop using asciidoc no-inline-literal" breaks asciidoc 8.2.5”
  1. Ævar Arnfjörð BjarmasonMay 29, 2012
  2. Thomas RastMay 29, 2012
  3. Ævar Arnfjörð BjarmasonMay 29, 2012
  4. Junio C HamanoMay 29, 2012
  5. Jeff KingMay 29, 2012
  6. Jeff KingMay 29, 2012
  7. Dennis KaarsemakerMay 29, 2012
  8. Ævar Arnfjörð BjarmasonMay 29, 2012
  9. Ævar Arnfjörð BjarmasonMay 29, 2012
  10. Jeff KingMay 30, 2012
  11. Matthieu MoyMay 30, 2012
  12. 0/3 docs: asciidoc version tweaksJeff King, May 30, 2012
  13. 1/3 INSTALL: update asciidoc recommendationJeff King, May 30, 2012
  14. 2/3 docs: drop asciidoc7compatible flagJeff King, May 30, 2012
  15. 3/3 docs: drop antique comment from MakefileJeff King, May 30, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.