Fix for gh1336

[FrankMittelbach]

Internal housekeeping

Status of pull request

• Not yet ready to merge

Checklist of required changes before merge will be approved

• Test file(s) added
• Version and date string updated in changed source files
• Relevant \changes entries in source included
• Relevant changes.txt updated
• [n/a] Rollback provided (if necessary)?
• ltnewsX.tex (and/or latexchanges.tex) updated

There is an issue with rolling back graphics. It fails in graphics.cfg for luatex with \outputmode being undefined. Is this an issue with the graphics code?

A second potential issue are the lines

Package amsmath Warning: Unable to redefine math accent \hat.
Package amsmath Warning: Unable to redefine math accent \check.
Package amsmath Warning: Unable to redefine math accent \tilde.
...

Are those okay?

[davidcarlisle]

There is an issue with rolling back graphics. It fails in graphics.cfg for luatex with \outputmode being undefined. Is this an issue with the graphics code?

I don't think so I think it's just a limitation of rollback that the rolled back files can't always work in the context of a current installation.

graphics-cfg/graphics.cfg has

   \ifnum\luatexversion>85
      \ifnum\outputmode>0
      \chardef\x=4\relax
      \fi
    \else
      \ifnum\pdfoutput>0
      \chardef\x=1\relax
      \fi

so if the engine is older than luatex 0.85 the engine has pdftex primitive names and pdftex.def s used by default.
If the engine is later than that then the luatex.def is used by default. If you roll back graphics to a version that no longer tests for luatex but use it with a luatex that does not define pdftex names like \pdfoutput it fails.

It would be possible to try to "roll back" the engine changes and re-enable the pdftex names cf the luatex85 package, but this seems more than expected for a package rollback.

[FrankMittelbach]

Not quite getting that. We run in an engine that is current even if we roll back and with one for which the .cfg does work without rollback. So what does rollback do that makes \outputmode undefined?

Assuming rollback stops working at date XXX for graphics then perhaps we should not put in 1994-06-01 but XXX+1 with graphics, no?
If so what is XXX?

[davidcarlisle]

Not quite getting that. We run in an engine that is current even if we
roll back and with one for which the .cfg does work without rollback. So
what does rollback do that makes \outputmode undefined?

I'll trace exactly where it fails, but in general if you roll back graphics
(or latex) to a version that did not specifically test for luatex and
assumes that pdftex primitives are available, then things will go wrong if
you use that code with a current luatex where they are not available.

That's why I think I prefer 0000/00/00 date we use elsewhere as a general
indication of start date, it doesn't imply we tested with tex engines
current at that time. Using a specific date of 2001/03/03 or whatever gives
a false expectation that rolling back that far is a reliable emulation
even if you are just rolling back one package but all the binaries and
installed packages are current,

I started to test this but seems we more generally have an issue

\RequirePackage[2015-01-01]{latexrelease}
\documentclass{article}

fails in lualatex for that or any earlier date

LaTeX2e <2023-11-01> patch level 1
L3 programming layer <2024-03-14>
 (/usr/local/texlive/2024/texmf-dist/tex/latex/base/latexrelease.sty
! Undefined control sequence.
\@ifundefined ...e \expandafter \ifx \lastnamedcs 
                                                  \relax \else \@ifundefin@d...

l.1358 \@ifundefined{ExplSyntaxOff}
                                 {}{\latexrelease@postltexpl}
? 

[davidcarlisle]

If you roll back earlier than 2015 in luatex you do

\ifx\directlua\undefined\else
\IncludeInRelease{2015/10/01}{\luatexluafunction}
                             {LuaTeX (prefixed names)}%
    \directlua{tex.enableprimitives("",%
                 tex.extraprimitives("omega", "aleph", "luatex"))}
\EndIncludeInRelease
\IncludeInRelease{0000/00/00}{\luatexluafunction}
                             {LuaTeX (prefixed names)}%
\directlua{
  tex.enableprimitives(
    "luatex",

or rather it's not that adding the luatex prefixed ones makes things fail we go further and do

 end
  for _,i in pairs(t) do
    tex.print(
      "\noexpand\\let\noexpand\\" .. i
        .. "\noexpand\\undefined"
    )

and undefine all the unprefixed names.

which means all the luatex primitives are unavailable without the \luatex prefix and then most things, including latexrelease.sty itself, fail.

So either we need to test for that everywhere or (much simpler) just be less agressive with the emulation there and define the prefixed names in addition to the unprefixed ones

[FrankMittelbach]

I'll trace exactly where it fails, but in general if you roll back graphics
(or latex) to a version that did not specifically test for luatex and
assumes that pdftex primitives are available, then things will go wrong if
you use that code with a current luatex where they are not available.

but wouldn't that be resolvable if latexrelease loads simply loads luatex85 if in luatex and a rollback prior to a certain date is requested?

[davidcarlisle]

but wouldn't that be resolvable if latexrelease loads simply loads luatex85 if in luatex and a rollback prior to a certain date is requested?

yes probably, but first we need to fix that you can't roll back before 2015 at all with luatex currently. even luatex85.sty assumes the luatex primitives are available unprefixed

[FrankMittelbach]

yes probably, but first we need to fix that you can't roll back before 2015 at all with luatex currently. even luatex85.sty assumes the luatex primitives are available unprefixed

or we accept that as a cutoffpoint for LuaTeX and put a warning into latexelease that rolling back before 2015 with the luatex engine is not supported (and errors are likely to happen).

[davidcarlisle]

OK to cutoff but shouldn't just make a warning we should make sure that at least it avoids the undefined command error loading latexrelease, but simplest way to do that I think is just remove the lua loop undefining all the primitives. we could undefine them all except \lastcsnamedcs so at least latexrelease.sty gets to the end, but that's starting to be weird.

[FrankMittelbach]

OK to cutoff but shouldn't just make a warning we should make sure that at least it avoids the undefined command error loading latexrelease, but simplest way to do that I think is just remove the lua loop undefining all the primitives. we could undefine them all except \lastcsnamedcs so at least latexrelease.sty gets to the end, but that's starting to be weird.

Couldn't we just drop the undefining completely? I mean we do that elsewhere too in cases where newer commands are likely to be used in packages that do not roll back. Yes, I know e undefine in case somebody had defined the commands in their code or document, but maybe keeping the primitives here is better overall causing less isses on the whole in the rollback case.

[davidcarlisle]

Couldn't we just drop the undefining completely?

yes I think removing the entire undefine loop works best (but as I just commented in #1336 it's still not enough to make graphics work in -dev versions)

[davidcarlisle]

I redid tests with a clean build just removing the undefine loop and I think all works as expected, if you roll back far enough you get

LaTeX Warning: Suspicious rollback/min-date date given
               A minimal date of 2009/07/12 has been specified for package
               'epstopdf-base'.
               But this is in conflict with a rollback request to 2000-01-01.

but it still works, and that would not be fixable here.

@FrankMittelbach I could push that change to this branch?

[FrankMittelbach]

Yes please do.

[davidcarlisle]

some changes already pushed...