Here I described some ideas related to Gentoo that from time to time come into my brain. There are few odds I will implement them (alone, at least), and intention of this page give its chance to be implemented by someone else. Let me know if you fired up with some of the ideas below!
emerge can use binary packages (and even check that found binpkg have required USE flags). Assume we have machine and intention to don’t use it for building for some reasons: slow compilation, low memory amount, bad cooling, use cases when a power supply available sporadically, etc…
I found quite useful (in theory) to give that machine possibility to request building of a binpkg that isn’t exists at the moment. Concept is very like old
getdelta service (does it work up to now? does anyone remember it?) where a machine with slow/costly internet access might request the service to download two versions of a package (the first that the machine have, the second that it want), unpack it, create delta (diff), pack the delta and give it for us. But binpkg service should build and give us binary package, not source.
I would be create the service in such manner that allow to check C(XX)FLAGS and even build-time dependencies matching. The implementation therefore should build packages in their own chroot/docker environments. I hope there is reasonable tradeoff between count of environments the service manages and accuracy of reproduction of a target machine environment.
Idea to think over: OverlayFS at top of sshfs (with image of the target system) for the building environment.
It’s just one particular problem, not the idea. I should report it to the upstream, I guess.
Distcc has concept of “backoff period”, the time that server “disconnected” from queue if it fails compilation of some compilation unit (file). The problem that configure phase often has tests that should fail. When only one remote server available, the first minute (or so on) of building will performed locally. We should check result (exit code) of the local compilation and disconnect the server only when the result of local compilation differs from remote one.
A kind of user-specific meta-repository on top of
Allow to pull a specific package from a Gentoo overlay into the local ebuild tree (e.g. using
layman) w/o pulling all contents of the overlay into the tree. Automatically pull eclasses and packages from the overlay that required by the package and absent in the local tree.
It downloads necessary overlay into some intermediate directory and copy only needed parts of it into a directory visible for portage.
The tool can be named
olm for fast typing.
List of necessary package::overlay pairs should be held into /etc/overlayman/packages or /etc/overlayman/packages/*.
Fast releases delivery
A some kind of auto creating ebuilds from:
- GitHub releases (not sure what I think about when it was appear in my notes…);
- PyPi (ebuilds somehow called
There are two use cases I have in the brain. Created ebuilds can be tested and released into the Gentoo tree (or an overlay) manually. Or it can be made w/o human participation by forming an overlay of autogenerated packages. Imagine overlay of all PyPi packages — isn’t it cool?
When emerge doing its work (building / installing packages) it’ll show fancy ascii graph with packages in vertices and dependencies as edges. The graph should show a currently building package (highlighted), some packages it depends and some depend on it. Try to keep displaying subgraph small.