explain package/module distinction, add notes on side tracks

Daniel Barlow 8 months ago
parent e8880c199b
commit b7ff973b4b
  1. 7
  2. 33

@ -23,3 +23,10 @@ expression or there is more than one reference to `up`, `down` etc.
* where a `let` form defines multiple names, put a newline after the
token `let`, and indent each name two characters
* should it be a package or a module? packages are self-contained -
they live in /nix/store/eeeeeee-name and don't directly change
system behaviour by their presence or absense. modules can add to
/etc or /bin or other global state, create services, all that
side-effecty stuff. generally it should be a package unless it
can't be.

@ -129,3 +129,36 @@ DONE 17) rename nixwrt references in kernel builder
19) syslogd - use busybox or s6?
chat -s -S ogin:--ogin: root / "ip address show dev ppp0 | grep ppp0" "/nix/store/*-s6-linux-init-*/bin/s6-linux-init-hpr -p"
Working towards a general goal of having a derivation we can
usefully run `nix path-info` on - or some other tool that will
tell us what's making the images big. The squashfs doesn't
have this information.
Towards that end (really? can't remember how ...) what would be a
way for packages to declare "I want to add files to /etc"? Is that
even a good idea?
Thinking we should turn s6-init-files back into a real derivation.
Tue Sep 27 00:31:45 BST 2022
> Thinking we should turn s6-init-files back into a real derivation.
This turns out to be Not That Simple, because it contains weird shit
(sticky bits and fifos).
Tue Sep 27 09:50:44 BST 2022
* allow modules to register activation scripts that are run on the
root filesystem once all packages are installed
- do they run on build or on host? if we're upgrading in place
how do we ship filesystem changes to the host?
* allow modules to declare environment.*, use pseudofile on build and
create real files on host. will need to keep the implementation on
host faily simple because restricted environment