WIP: Merge osbuildbootc into here, use osbuild/images PR

[cgwalters]

• Take the code from https://github.com/achilleas-k/images/tree/bifrost-image/cmd/osbuild-deploy-container
  and merge it into this repository, using the code from Add support for building images from ostree containers and the Fedora CoreOS qcow2 image type images#243
  as a replace
• Also merge in osbuildbootc

OK this was all pretty straightforward until I hit:

$ make
(cd cmd && go build -mod vendor -o ../bin/osbuildbootc)
(top=$(pwd); cd cmd/osbuild-deploy-container && go build -mod vendor -o ${top}/bin/osbuild-deploy-container)
package github.com/cgwalters/osbuildbootc/cmd/osbuild-deploy-container
        image.go:7:2: use of internal package github.com/osbuild/images/internal/common not allowed
package github.com/cgwalters/osbuildbootc/cmd/osbuild-deploy-container
        main.go:12:2: use of internal package github.com/osbuild/images/internal/dnfjson not allowed
package github.com/cgwalters/osbuildbootc/cmd/osbuild-deploy-container
        image.go:8:2: use of internal package github.com/osbuild/images/internal/users not allowed
package github.com/cgwalters/osbuildbootc/cmd/osbuild-deploy-container
        image.go:9:2: use of internal package github.com/osbuild/images/internal/workload not allowed
make: *** [Makefile:20: bin] Error 1

So I think we're going to need to figure that stuff out right?

[achilleas-k]

package github.com/cgwalters/osbuildbootc/cmd/osbuild-deploy-container
image.go:7:2: use of internal package github.com/osbuild/images/internal/common not allowed
package github.com/cgwalters/osbuildbootc/cmd/osbuild-deploy-container
main.go:12:2: use of internal package github.com/osbuild/images/internal/dnfjson not allowed
package github.com/cgwalters/osbuildbootc/cmd/osbuild-deploy-container
image.go:8:2: use of internal package github.com/osbuild/images/internal/users not allowed
package github.com/cgwalters/osbuildbootc/cmd/osbuild-deploy-container
image.go:9:2: use of internal package github.com/osbuild/images/internal/workload not allowed

• dnfjson should be public and we're going to move it into pkg as part of this PR so it can also be used by osbuild-composer.
• The things from common are trivial: one is just a ToPtr() function for making pointers from literals and the other is basically the equivalent of uname -m for getting the machine architecture.
• workload should also be public. It's meant for configuring workload-specific customizations and would be useful to have in general (but maybe not for this). It's not really doing anything in this code (it's empty), I just needed a workload, any workload, to make the pipelines happy.
• users I'll have to think about. We can drop it for now if we don't care about creating users while creating the image and think about it. I think it will end up being part of the public API though.

[ondrejbudai]

Do we still need this PR? The Go code is already here. I'm not sure about the VM-related code - it adds more user-facing surface and complexity. Do we actually have any users who need this?

[cgwalters]

Do we still need this PR? The Go code is already here.

Yes, though the use of bootc install is not; osbuildbootc is attempting to serve as a reference for that still.

I'm not sure about the VM-related code - it adds more user-facing surface and complexity. Do we actually have any users who need this?

This is a good question. It's a tricky topic. My 90% day to day development environment does not involve root on host Linux system - I live in toolbox containers and launch unprivileged VMs (for both building disk images and testing). My host is only partially trivially reprovisionable (have some "pet" like aspects still) and on general principle I like to isolate root-privileged code.

Now, for cases like podman-desktop on Mac/Windows, it's the opposite; the Linux VM is (usually) ephemeral/reprovisionable and is already in a VM; we don't want to do nested virtualization.

I think where this problem becomes more real is the same problem around a flow that unifies "build" and "run"...we've had this discussion in many places. That problem is currently left on the floor for the podman-desktop flow (but there's some active discussions around reusing the podman-desktop VM code for these images).

If I'm on a Linux host, it would make sense to me to still support a fully unprivileged (modulo /dev/kvm) workflow...I don't think it'd be too much code; perhaps arguably we could use krunvm instead of the hacky bits we have in osbuildbootc with supermin...I need to play with that.

Anyways I'm fine to close this; we're already tracking the bootc install in the other issue, I can file a distinct one for the question of running this project unprivileged. In the short term I'm OK running privileged.