However, if we dispense with the tree- image and keep just the latest- image, which is the way
Dockerfile works now, we could layer the schemes and get more layer-friendly images I think. Back to the drawing board.
But the benefits of layer-friendliness is lost as soon as updates come into play.
Here, you get layer friendliness across both axes.
Nope, you don't. After one weekly update the basic layer is not related to the minimal layer anymore.
Okay, so the week 0 latest-minimal image has the
base and tlmgr install scheme-minimal layers, right?
1 reply
Then the week 1 latest-minimal image has the
base, tlmgr install scheme-minimal, and tlmgr update layers.
1 reply
You go up and then right.
1 reply
Each week, the image grows one layer to the right.
Right, we don't update the
base image in what I drew.
Ah, yes. Since week 1, the updates for the different schemes are unrelated, you are right.
But here is the kicker:
Your whole up-arrow is only valid in the first week. And otherwise you only get the right-arrows. Hence, we can save us the trouble of doing step-wise installation in week 0 in the first place.
The deduplication saves our ass precisely in week 0. The size of updates over the year is negligible compared to the first installation.
1 reply
So perhaps we don't care so much that the updates to the different schemes are unrelated after week 1, inclusive.
1 reply
It won't necessarily be easy to set up, but I assure you that the updates over the year are more than a factor of ten smaller compared to the initial download of TeX Live in week 0, which is precisely why it's crucial to deduplicate in week 0 by layering the schemes but not necessarily in the following weeks. It's easy to demonstrate that by downloading a TL 2021 ISO and then updating it.
2 replies
Yeah, we would probably need a separate Dockerfile for the week 0 seed image.
And there are other concerns, too. It's not ideal to use a year-old base image, so perhaps we want to at least apply security updates once every N weeks.
3 replies
Actually, we don't. We take the current
Dockerfile. We need a new Dockerfile.update which basically does:ARG image
FROM $image
RUN tlmgr update --self --all --reinstall-previously-removed
I can run the numbers and we can decide afterwards if we think it is worth it.
1 reply
:point_up: Edit: The deduplication saves us precisely in week 0. The size of updates over the year is negligible compared to the first installation.
We would lose the historical
tree images but get historical schemes.
3 replies
Or do they?
They do.
And yet, we still have #19 open.
That confused me. 😉
Oh, I thought I marked it to be closed by !23. Seems I did not. I'll close it.
No, see multi-arch builds are done in a single command. 🙂
1 reply
It would slow things down, but they are a single command that produces a single fatter image.
TL installs are specific to the architecture so it will actually blow up size quite a bit.
The .gitlab-ci.yml file would still be nice and simple, though.
Forget about Docker, I can't get biber working on my Raspberry Pi without compiling it myself.
Right. But situation is improving for linuxmusl (i.e. alpine) iirc. So that could be a viable alternative because MUSL is self-contained and should also be able to be run on ARM.
From the tex-live mailing list, I got the vague impression it's unavailable because the author did not care to release the binaries for ARM.
Raspbian compiles their biber, so it's clearly doable, just useless because it's not kept in sync with current biblatex.
1 reply
Well, not completely useless, but you have to use Debian's TeX Live.
Which is quite... historic.