[elbe-devel] [elbe-users] ELBE v15.1

[Manuel Traut]

Hi Thomas,

> > > Deprecations and Removals
> > > -------------------------
> > 
> > I did not expect feature removals on a minor upgrade..
> 
> As indicated, I do think that nobody should be affected by these
> removals.
> 
> > > - The *internal* command `elbe adjustpkgs`.
> > > - The *internal* command `elbe buildchroot`.
> > 
> > I used 'elbe buildchroot' often directly in containers
> > triggered by a CI. This was quiet useful. But meanwhile
> > I use mkosi for this, so it does not hurt me.
> 
> This sounds reasonable, but I'm not sure if other users besides people
> intricately familiar with elbe are doing the same.
> It's not described in any way in the prose documentation and completely
> bypasses the documented initvm machinery and architecture.
> It also has drawbacks around license reporting and SBOM generation that
> a user would need to be aware about.

There was a talk about using it like this on a k8s cluster:
https://debconf22.debconf.org/talks/20-build-debian-based-embedded-images-in-the-cloud/

The code is here:
https://github.com/dcbe-project

But I don't expect that anybody is using it.

> FYI I intend to make the initvm abstraction more generic so for the
> container usecase the local machine can be used as "initvm".
> Also today its possible to use a normal qemu process instead of a full
> libvirt VM as initvm.

The problem with initvm is, that it is a single machine and this does
not scale for bigger projects.

It might be interesting to integrate imagebuild, SBOM, etc
into https://freexian-team.pages.debian.net/debusine/ in the future?

> > However for me it was no internal command. There was a
> > even a user visible man-page that described the command.
> 
> All manpages were user visible. Even those for commands like
> fetch_initvm_pkgs, xsdtoasciidoc and daemon. So that is a limited reason :-)
> And many of those removed commands were broken for quite some time.
> As they are not part of the regular elbe workflow I deemed it better to
> remove them instead of spending time trying to fix them or having users
> getting confused while looking at the docs.

For fetch_initvm_pkgs the man-page cleary states:

|This command is used by elbe internally during the creation of the initvm.
|It is currently not supposed to be called by users.

For me the power of UNIX is having small tools that can be combined with
other tools, pipes, etc. This is getting somehow lost here.

IMHO it eases also testing and debugging during development if parts of
the workflow can be easily executed manually.

> > Just wanted to mention, that there might be use-cases out
> > there for still having those commands.
> 
> If anybody wants them back, they can always be reintroduced.

Bringing the commands back is OK, if someone complains.

As you mentioned, some features seem to be only available if using
it in combination with the elbe-daemon.

It is an architectural decision, if elbe shall become an easy to
use predefined setup with a VM, or provide also commands for the
single tasks that ease the integration into scalable cloud-based CI
setup for more experienced users.

In my current project, this was the key argument against elbe.

Maybe this input helps for future architecture decisions.

But nevertheless elbe is still great for people with a small amount
of own small packages. Setting up a complete pkgbuild, repo and
imagebuild infrastructure without elbe needs a lot of experience.

Cheers
Manuel