[NTG-context] How can I make a Gentoo Linux package for ConTeXt LMTX?

Hans Hagen j.hagen at freedom.nl
Thu Aug 18 09:31:04 CEST 2022

On 8/18/2022 2:51 AM, Max Chernoff wrote:
> Hi Amano(?), Hans
>>> Can you make it easier to make an OS package for ConTeXt LMTX by
>>> releasing versioned (source) archives, including BUILD/INSTALL
>>> instructions in the versioned archives, and so on? I wish I could just
>>> extract a versioned binary archive into certain locations or use GNU
>>> autotools or use meson build system which is far better than GNU
>>> autotools.
>> there is a github repository for the tex stuff
> For reference, the GitHub repository is at:
>     https://github.com/contextgarden/context-mirror/
> It's semi-official mirror, but the authoritative source is the zips hosted
> by Pragma.
>> and have no experience
>> with all that versioning / release / os packaging stuff (couldn't test
>> it anyway and continuously adapt to teh subtle differences in
>> distributions and os's) ... we just post zips (already for decades) but
>> anyone is free to come up with such instructions (e.g. aditya did some
>> for arch)
>> anyway, lmtx is still kind of experimental and at some point
>> installation will move to the garden (not much is needed, just a web
>> server) and the packaging scripts are / will be in the distribution  ..
>> there are no dependencies (and we keep it that way: self contained bins)
>> sorry, i just can't spent time on all the possible variant ways of
>> installation .. that is up to volunteers
> I think all that Amano is asking for is for older versions of the
> zips/binaries to be kept available. Right now, the only files available
> for download that I'm aware of are the latest versions.
> This is problematic from a reproducibility standpoint, since if you have
> multiple people, say, writing a large textbook, it would make sense that
> they wouldn't want to upgrade their systems constantly in case something
> breaks. These people can easily just avoid upgrades, but if someone new
> joins the team, they can only download the newest version. However, that
> won't necessarily match the older version that everyone else has, which
> can lead to problems.
> Having older versions available would also help in the case of major
> short-term regressions, since users would be able to (manually)
> downgrade to an older version if necessary.
> An easy solution to this would be the following: instead of overwriting
> the whole "/install-lmtx/" tree on every update, you would install all
> the new files to something like "/install-lmtx-2022-08-07/", then have
> "/install-lmtx/" be a symlink to the latest "/install-lmtx-YYYY-MM-DD/".
> I don't think that this would be very hard to implement from a technical
> perspective, and the only downside that I can think of would be extra
> disk space used. This is a fairly common implementation among other
> software.
> One other solution would be to have "dl.contextgarden.net" mirror a
> zip/binary combo once every few months or so. These would often be out
> of date, but they would provide a stable archive that would be useful in
> cases like this.
> This is just a suggestion though; it's not something that I personally
> need, although I see how it could be potentially valuable for others.
At some point binaries won't change much. After all, we don't package 
the luatex binaries either and they also can relate to versions of tex 
code (in the early days of luatex dev we had a similar situation).

Now, when it comes to reproducability: the idea behind the relatively 
small installations is that one just keeps an old tree around. So, say 
you install, then decide to update but don't want any risk, you then 
copy the whole tree because there can be engine-texcode depdencies.

The current 'installer' actually works liek this:

- you download the small zip
- using that you install the tree which initially means download and 
unzip (it uses the build in unzip)
- then it makes some symlinks etc

a next time you update, it will first check what got changed, for which 
it uses the hashes in the tma files and that download then doesn't use a 
zip but an unpacked tree on the server

so, in your proposal that would mean that i had to keep around plenty of 
zips (as each platform has one) as well as all these unpacked trees

I now run this on a relatively small virtual machine on one of the 
servers and don't look forward to expanding that: i can easily push 
updates there. Of course all can be done, and extending script is easy 
but one needs a very good reason (to spend spare time and money on this 
as after all it comes for free).

Mojca and I have been discussing the binary part wrt githib but even 
with the relatively small luametatex binaries it's a bit of a challenge 
on git. We have some ideas but need time to do it and it doesn't have a 
high priority. I expect that one of these days the binaries won't change 
that much. We're still enhancing / improving the math sub-engine so that 
can create a depedency but at some point there will be a stable version. 
We do all dev in a separate repository anyway. Also, when the sources 
are in the distribution users can compile themselves, read: they then 
could in principle generate the binary for their (updated) platform for 
an older tree. So .. in due time all will be sorted out.


                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl

More information about the ntg-context mailing list