[Buildroot] Buildroot docker image

[Yann E. MORIN]

Thomas, All,

On 2023-12-10 18:02 +0100, Thomas Petazzoni spake thusly:
> On Sun, 10 Dec 2023 14:48:14 +0100
> "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:
> > M: strictly mandatory
> > T: optional, but helps use pre-built toolchains
> > S: optional, speeds up the build
> > C: needed to run check-package et al.
> > R: needed to run the runtime test-suite
> > 
> > Bazaar, mercurial and subversion are optional, and only required when a
> > package is bzr-, hg-, or svn-hosted, but if we want this image to be
> > usable generally, it should have all three.
> > 
> > Since mercurial is a python package, we can't drop python3, and the
> > remaining modules are relatively small in comparison to the rest.
> > 
> > Getting a more minimal image would be just about dropping qemu. That
> > would make for an image that we could not use in the CI, and that would
> > not be usable to test the changes done to Buildroot. I don't think that
> > would mkae for a good image.
> 
> It's mainly Python3 that is important to drop. Python3 is not part of
> our mandatory requirements, and it's a very frequent sources, as people
> don't have an easily accessible container to test Buildroot builds
> without Python3, so they forget BR2_TARGET_UBOOT_NEEDS_PYTHON3 or
> similar options.

Sure, but removing python3 means removing all the testing infrastructure
as well, and the ability to run check-package and flake8, and then we
would complain people are not running the linters (or are running them
on their host system without the proper versions).

Note also that, if we go the route your suggest, which is:

  - base image without python3 et al. for people to test-build,

  - CI image based on the above, plus all the testing infra;

then the CI would not be able to catch the issues such as a missing
BR2_TARGET_UBOOT_NEEDS_PYTHON3, because python3 would be part of the CI
image.

Also, I believe it is very optimistic to expect all contributors to
build-test in the docker image before they submit their changes. Some
will do (and some already do!), most won't.

> We have exactly two packages that use Mercurial.

The goal of that base image was also supposedly for people to reuse for
themselves, possibly with their own packages, not just for Buildroot.

So, we need three images:

  - an image with only the strictly required tools, which means some
    features will not be available: none of the VCS tools are mandatory,
    so they all must be excluded, yes, that also means git [0]: we can't
    exclude Hg and include git. Either the image is exactly right just
    the minimal with only the mandatory packages, or it is not;

  - an image that has all we need to run our tooling in the CI [1];

  - an image that people can reuse for themselves as a reference image
    that "just works".

I'm arguing that the two latter images are exactly the same, in fact, and
are the image we already have.

I am also arguing that the first image, without all of the optional
packages, is not going to be very useful in practice. Indeed, let's
take uboot as an example: one can chose an arbitrary version from an
arbitrary git tree, and thus you need git, so we can't build a lot of
our defconfig files in an image that has only the strictly mandatory
packages, and this is the image that would be able to catch the python3
issue...

Of course, we could make git part of the mandatory packages. Or we could
introduce host-git and treat it like host-lzip; and so on for host-svn,
host-cvs, host-mercurial, host-bazaar...

And maybe that is what we should do:

 1. promote git from optional to mandatory, like wget is: indeed, it is
    so common and pervasive that it does not make sense to keep it
    optional; then, and only then, it would make sense to have the first
    image with only the mandatory tools;

 2. add host variants of the other VCS tools (where that is not too
    difficult), so that we can use them if missing on the build machine.

[0] the manual states that rsync is both mandatory and optional, I'll
send a patch to fix that.

[1] ideally, it would also be used by the autobuilders, but that's
another topic entirely...

Regards,
Yann E. MORIN.

> pygame has the comment "stable 1.9.1 release requires V4L which has
> been wiped out of recent Linux kernels, so use latest mercurial
> revision until next stable release is out.", but there's a recent
> pygame 2.5.2 release from September 2023. And pygame is now on Github:
> https://github.com/pygame/pygame.
> 
> The other one is dvb-apps, which hasn't seen a single commit since
> March 2014: https://linuxtv.org/hg/dvb-apps. We could consider it
> obsolete/unmaintained maybe? :-)

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'