On 7/2/2021 9:38 AM, Jan U. Hasecke wrote:

Am 02.07.21 um 01:07 schrieb Bruce Horrocks:
One option you might try, if your cooperative has a web-server available to editors, is to store your own ConTeXt repository. That way you can update the LMTX version when you are ready to.

This works because "install.sh" can have a "--server" parameter supplied. By default it goes to lmtx.pragma-ade.com/install-lmtx but if you were to copy the install-lmtx directory and host the copy on your own server at the same path, then you could 'freeze' your LMTX version until you were ready to change.


Thanks for this hint.

This might solve one more problem. We would like to pin the installation to a version that is known too work.

BTW: Are there plans to use a GitHub repository or an alternative to it? As that would ease pinning a bit.
All uploads end up here too alsk kind of an archive:

official    : https://bitbucket.org/phg/context-mirror/src/beta/
experimental : https://github.com/mojca/context2

The official oen can be checked out, the experimental one is a playground because for quite a while Mojca and I have some ideas for a more extensive install on github which would then involve:

-- core context code (with luametatex in source tree too: tex/texmf-context in the distribution

-- the minimal set of resources: tex/texmf in the distribution

-- binaries (which is the more complex part)

-- modules: texmf/modules

So, basically several repositories alongside (totaling to the amoutn we now have in the zips). We then have doif-it-yourself-zips, the garden installer, the lmtx self updater and install-from-github as alternatives. I have a sort of proof of concept for it. We looked into the binary bit and things have changed a bit over the years so maybe it's more doable now.

One of the complications is always that it depends on helper programs:

- zips are easy as all systems have it (ok, some linux distributions don't install unzip but one can easily add it)

- the garden install needs a matching rsync (we need to ship on for windows and sometimes a mismatch will require an update on other platforms); it reminds me that we have to swap the cygwin bins by mingw bins; anyway. one problem is that organizations block the port

- the lmtx installer needs a (luametatex) binary which is no big deal; it uses http and there might be organizations that demand https and ssl keeps evolving so in the long run it can fail to update older installations (it anyway means that we need to also ship e.g. curl or libcurl (the later works ok for us); no big deal but more work)

- a github install demands that git is installed; that itself is a big piece of software (a small git binary for windows is already 200 MB due to all the dependencies while actually we only need a stupid fetch); the gh binary is still 25M but might be a solution, apart from the fact that we then expect users to have a recent bin ... will a 5 year old installation update?); of course users can also decide to completely do it themselves (check out etc) but for a local project-specific run one doesn't want all those gigs

So, each approach has pros and cons, and we need to prevent lock into some specific technology.

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
       tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Reply via email to