Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to Bob v0.2.0 among other fixes #48

Draft
wants to merge 21 commits into
base: main
Choose a base branch
from
Draft

Conversation

obiwac
Copy link
Member

@obiwac obiwac commented Nov 23, 2024

To do:

  • Update to Bob v0.2.0.
  • Add regular old FreeBSD sanctioned templates (so I can run AnaNAS on that instead of aquaBSD core).
  • Use subcommands instead of cryptic switches, like aquarium create or whatever.
  • Depend on /usr/src headers for ZFS stuff instead of manually maintaining a copy here (checks in build.fl, Bob utilities for logging? Like Fs.assert_access(SRC_PATH + "/include/whatever", "Is /usr/src populated?"), or maybe this should be built in to assert like assert Fs.access(SRC_PATH + "/include/whatever"), "Is /usr/src populated?").
  • Update CI to latest version of FreeBSD. I'm disabling CI for now. I'd like to do this more smartly, by having a cache for the OpenZFS sources as well as the templates.
  • Make aquarium files symlinks instead of weird "manual" symlinks. Let's not worry about changing this right now, it doesn't impact all that much.
  • Put aquariums in /usr/local/etc/aquariums instead of /etc/aquariums and clean up the directory structure for this a bit.
  • Move away from libcopyfile and libmkfs_msdos and simply issue commands (bring out fsutil and cmd from Bob for this?). Actually they're fine. I still want fsutil at some point but for now this is fine.
  • Automatic code formatting. There are too many ugly macros that autoformatting kind of fucks up, so no.
  • Find solution for not having to do doas chown root:wheel .bob/prefix/bin/aquarium && doas chmod +s .bob/prefix/bin/aquarium manually after each build. (Maybe also a warning for if we dynamically link a setuid binary, or is that hard to do?). I'm thinking the ability to hook to different parts of the build process and to execute arbitrary commands (e.g. pre() and post() callback functions).
  • Update README.
  • Update tests/examples.
  • Ability to overlay other templates a posteriori (e.g. src).
  • Replace TRY_FREE with just free (free is guaranteed to do nothing if passed NULL, so there's no need for this).
  • Fix devfs rulesets (for now, just allowing all).

Personal notes:

The first two steps are obviously the most important, as after this I'll be able to restart AnaNAS and port the creation script over from there. Maybe this is also the opportunity to support aquarium definitions in build.fl files. This would require multiline strings in Flamingo to be ergonomic, and actually I could do one cooler and have Markdown-like code strings which Tree-sitter could highlight in the right language:

import bob

let aquarium = Aquarium("amd64.freebsd.14.1-RELEASE-p5", "amd64.freebsd.14.1-RELEASE-p5")
aquarium.copy(...)

aquarium.sh(```sh
#!/bin/sh
set -xe

/etc/rc.d/os-release onestart
```)

let image = aquarium.image()

install = {
    image: "bootable_image.img"
}

Or maybe just use """ like in Python, so code examples aren't annoying to write in Markdown.

The other big thing is how do we do installing 3rd party software to an aquarium? Do we use the dependency system? If so, should these be built in their own little aquariums to target the one we're generating? I'm guessing a pretty elegant solution would be to have the install map install to the aquarium when one is set up, but then that precludes having multiple aquariums at once.

The only thing I need to prevent is having to build inside the target aquarium, because then you need all the build dependencies and that's a lot of bloat for nothing. And it also means you can't cache stuff run-to-run.

Maybe there's also an external-to-bob solution to all of this. Maybe we just build normally with all the dependencies we want (optionally inside a build aquarium) and install to an aquarium instead of a regular prefix. This would certainly allow us to generate multiple aquariums at least. We could also also have a main build.fl file for the aquarium, which can shell out another build.fl to build the stuff in that aquarium which itself runs in a temporary aquarium that can be cached.

Say, in build.fl:

import bob

// This creates a build aquarium based on FreeBSD 14.2-RELEASE (no kernel) in which Bob is built (mandatory).
// The contents of the "build" directory are then copied to the aquarium, and the built Bob is used to build this.
// This can all obviously be cached build-to-build.
// Since this build aquarium config is for the most part just going to be dependencies and stuff, maybe we can inline it here and automatically create the project in question behind the scenes.

let build_aquarium = Aquarium.builder("amd64.freebsd.14-2-RELEASE", "build")

// This creates the final output aquarium we want, which we unfortunately can't cache build-to-build (but the hope is that most stuff .
// Since we're going to create a bootable image out of this, we naturally need a kernel.

let aquarium = Aquarium("amd64.freebsd.14-2-RELEASE")
aquarium.add_kernel("amd64.freebsd.14-2-RELEASE")

build_aquarium.install_to(aquarium)

let image = aquarium.image()

install = {
   image: "./bootable_image.img", // XXX Relative install paths?
}

@obiwac obiwac added the enhancement New feature or request label Nov 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant