[tlbuild] patches from Debian

[luigi scarso]

On Fri, Mar 6, 2015 at 3:25 PM, Norbert Preining <preining at logic.at> wrote:

> Hi Luigi,
>
> (reincluding tlbuild)
>
>
> > Compiled with zlib 1.2.8; using 1.2.8
>
> Yes, that is the optimum, but not necessarily reality.

for luatex and zlib


>

> The problem is 1.2.11 vs 1.2.12 and I don't like it
>
> No, the problem is
>         1.2.5 versus 1.2.6
> etc. Both should be API compatible, and luatex should ignore the .5/.6
> part.
>
> no, for me the problem is
1.2.11 vs 1.2.12 because with 5  digits the check is ok while the number
differs.
1.2.5 versus 1.2.6 is not the problem because the check fails
 and this is ok for me.

The last digits in SO names are normally API compatible changes,
> if not this is a failure of maintainers (I don't say this doesn't
> happen, but is very rare)
>
> and this exactly what I have seen (with libpng )

> So i'm for keep 5 digits, maybe even to move to 8.
>
> In fact it should not be digits, but:
> - parse into \d+\.\d+\.\d+
> - check the first two numbers, ignore the third
>
assuming a sane numeration
aa.bb.cc (i.e. 8 digits) for zlib is enough  --- otherwise it's a sign that
something wrong is going on


> For peace of soul one could give a warning when the third differs,
> but don't stop.
>
> I am patching this in luatex since years in Debian, on abut 15
> architectures,
> with several zlib upgrades.
>
> I don't udnerstand what you are scared? That upstream makes something
> stupid in the minor version?
>
> For the upcoming luatex 0.80 for TL I can put 4 instead of 5

/* make sure header and library version are consistent */
    const char* version = zlibVersion();
    if (strncmp(version, ZLIB_VERSION, 4))
    {
        lua_pushfstring(L, "zlib library version does not match - header:
%s, library: %s", ZLIB_VERSION, version);
        lua_error(L);
    }

so we check a'.'b'.'
assuming a and b a single char --- as also all the strings with the same
prefix of length 4, of course.
A next luatex will have a better  <major>.<minor> checker.

-- 
luigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tlbuild/attachments/20150319/7e1c0d41/attachment.html>