2023-12-11 20:09:56 +01:00
|
|
|
A brief guide to backward-incompatible changes
|
|
|
|
|
that are likely to break configurations or workflows
|
|
|
|
|
|
2023-12-11 21:18:28 +01:00
|
|
|
2023-07-13
|
|
|
|
|
|
|
|
|
|
* a significant re-arrangement of modules and services, which will
|
|
|
|
|
probably break any configuration written before this time. For a
|
|
|
|
|
detailed explanation, see
|
|
|
|
|
https://www.liminix.org/doc/configuration.html#modules
|
|
|
|
|
|
2023-12-11 20:09:56 +01:00
|
|
|
2023-12-10
|
|
|
|
|
|
|
|
|
|
* configurations (usually) need no longer import modules from
|
|
|
|
|
modules/outputs because devices are expected to do this instead. This
|
|
|
|
|
change is because the outputs that make sense in any given context are
|
|
|
|
|
usually a property of the device being installed onto.
|
|
|
|
|
|
|
|
|
|
2023-12-11
|
|
|
|
|
|
|
|
|
|
* rename outputs.flashimage to outputs.mtdimage (and also diskimage to
|
|
|
|
|
mbrimage). This change is made in the expectation that "fooimage" is
|
|
|
|
|
the name of an outputs that gloms together other filesystem-like
|
|
|
|
|
outputs with some kind of partition table - so we might in future have
|
|
|
|
|
gptimage or lvmimage or ubimage.
|
|
|
|
|
|
2024-01-03 20:44:49 +01:00
|
|
|
2024-01-03
|
|
|
|
|
|
|
|
|
|
Liminix is now targeted to Nixpkgs 23.11 (not 23.05 as previously).
|
|
|
|
|
Upstream changes that have led to incompatible Liminix changes are:
|
|
|
|
|
|
|
|
|
|
* newer U-Boot version
|
|
|
|
|
* util-linux can now be built (previously depended on systemd)
|
|
|
|
|
|
2024-02-12 22:10:52 +01:00
|
|
|
2024-01-30
|
|
|
|
|
|
|
|
|
|
New port! Thanks to Arnout Engelen <arnout@bzzt.net>, Liminix
|
|
|
|
|
now runs on the TP-Link Archer AX23
|
|
|
|
|
|
|
|
|
|
2024-02-12
|
|
|
|
|
|
|
|
|
|
* we now build wifi drivers (mac80211) from the same kernel source as
|
|
|
|
|
the running kernel, instead of using drivers from the linux-backports
|
|
|
|
|
project.
|
|
|
|
|
|
|
|
|
|
* in general, we build kernel modules (e.g. for nftables) at the same
|
|
|
|
|
time as the kernel itself instead of expecting to be able to build
|
|
|
|
|
them afterwards as though they were "out of tree". Refer to commit
|
|
|
|
|
b9c0d93670275e69df24902b05bf4aa4f0fcbe96 for a fuller explanation
|
|
|
|
|
of how this simplifies things.
|
2023-12-11 20:09:56 +01:00
|
|
|
|
2024-02-13 22:41:43 +01:00
|
|
|
2024-02-13
|
|
|
|
|
|
|
|
|
|
So that we can be more consistent about services that would like their
|
|
|
|
|
state to be preserved across boots (assuming a writable filesystem)
|
|
|
|
|
these changes have been made
|
|
|
|
|
|
|
|
|
|
* /run/service-state has been moved to /run/services/outputs
|
|
|
|
|
to better reflect what it's used for
|
|
|
|
|
* /run/services/state is either a symlink to /persist/services/state
|
|
|
|
|
(if there's a writeable fs on /persist) or a directory (if there
|
|
|
|
|
isn't)
|
|
|
|
|
|
|
|
|
|
The `output` and `mkoutputs` functions defined by ${serviceFns}
|
|
|
|
|
have been updated, so unless your services are hardcoding service-state
|
|
|
|
|
then the change should be seamless
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
21:02:51 GMT 2024
|
2023-12-11 20:09:56 +01:00
|
|
|
|
