Gittup, a Linux distro on top of Git

Presuming tup is good, of course. I played with it but I hated the fuse dependency and ended up switching to meson (though I despise the build-time python dependency, see [0]) for cross-platform projects and plain jane gmake or pmake Makefiles for others. I also hand code ninja build files for stuff that’s not too crazy and platform dependent, basically for things that gulp would normally be in control of.

Hardcoding dependencies at build-time seems to me like a fundamental first step towards a stable system that has been absent from Linux since the late 90s.

They go in opposite directions in replacing make:

redo boils down to "How can we capture 99% of the value of make with 1% of the complexity" and does it well. It helps that you don't have to figure out whether sh or make will be interpreting your (similar, yet different enough to trip you up) expressions; redo is "sh all the way down" It also manages to automatically have dependencies on build rules which Make could really use.

Tup is more like "How can we limit what make can do in order to make a better special purpose tool?" Tup can't handle files with spaces and implementing "make install" is flat out impossible. It also is very inflexible with your directory tree. However, it is the best tool for "Many files in, one file out, rebuild if any inputs change" and making this implementation tractable is a specific result of being less flexible than make.

[edit]

Just found the Maak paper:

1) Ports actually does unify building and deployment by using make for deployment

1a) This does require writing (or modifying) makefiles for every single package

2) Nix fits in the same space as Maak, as you use nix both for building and deployment; it just may farm out some of the work to a secondary build system such as make. If you consider the build-script to be the generator (rather than e.g. `cc`) then it maps closely to Maak.

2a) There is no reason I can think of why you couldn't have a nix expression for every single .o file, and have nix-build handle incremental builds for you.

2b) Farming out much of the work to existing build systems is a pragmatic approach to reduce the amount of work needed to create a nix expression. 99% of the time if cmake or autoconf are used, a minimal nix file will give you a mostly working package. This is much more reliable than trying to autoconvert Make (which is composed of two turing complete languages) to some other system.

3) One that the paper claims that only the generators can have complete dependency information (Make, Maak, and Nix all farm out specifying dependency information to the author of the build script; though Nix attempts to prevent you from omitting dependencies by sandboxing), but Tup sidesteps this by sitting between the filesystem and the generator.

1. uncomment the deb-src lines in /etc/apt/sources.list; if you do not have these, simply copy each deb line and have it begin with deb-src.

2. apt-get update

3. apt-get source <packagename>

4. cd <packagename>-<version>

5. (do modifications here)

6. dpkg-buildpackage -us -uc

7. install the .deb packages in the parent directory with dpkg -i

Do note, this does not properly embed your modifications in a patch or whatever, I haven't figured out how to do this and lose my mind at the same time.

On my desktop, I run into the same problem as you; I think my system partition is just a little small. On the laptops, I have not had any trouble with snapshots.

I do like the idea, though - if an update breaks anything, just roll back to the last working state. Windows did this 15 years ago, it was about time Linux distros started catching up.