[Buildroot] external, how to achieve our needs?

[Ludovic Desroches <ludovic.desroches@microchip.com>]

Hi,

We are currently using it for linux4sam but it seems it has limitations
and I would like to know if you have advice to share or the same issue.
I did a quick search in the mailing list, I found a discussion with few
answers and patches from Yann for external toolchains, jpeg and openssl.
Unfortunately, it doesn't cover all our use cases.

At the beginning, we forked buildroot in the buildroot-at91 tree. It was
mostly done to put patches we sent upstream. We release a distribution
called linux4sam which contains bootloaders, kernel and rootfs. We can't
wait for the next release of Buildroot to get our patches. It was also
useful to handle additional defconfigs, buildroot bug fixes and sometimes
patches that are not accepted upstream.

When the external feature was released, we thought that it should be better
to rely on Buildroot vanilla and to release only our external. The goal was
to remove the buildroot-at91 fork. At least, it was the plan...

Now, we still have buildroot-at91 + buildroot-external-microchip trees. We
faced several problems which make difficult to only provide an external.

One of the latest issue is we are adding support for a GPU in cairo and
this work is not upstream yet. It involves patching cairo sources
(that's not a big deal) but also to modify cairo.mk to add dependencies and
new configure options. I discussed with Thomas who helped me to achieve it
with some tricks. I added a cairo_microchip package, I had to patch some
libraries to link with this version of cairo and use the external.mk to
force extra dependencies for cairo and pango. Honestly, even if it works,
I am not pleased with the solution. It will be so much easier and cleaner
to do this in buildroot-at91 instead of buildroot-external-microchip. We
discussed again, internally, about the external and the fork of buildroot
but we have different opinions. I would like to emphasize that recent
changes in buildroot make us think that it won't be easy to get rid of
buildroot-at91: devmem2 deprecated, rgnd which increases the boot time
since it uses the lib jitterentropy, curl library name change and others.

My feeling is that the external is not flexible enough to allow us to
remove buildroot-at91. Is it planned to offer a way to modify package
configs and makefiles or is it totally against Buildroot philosophy? I
think this is a strength of the Yocto layers but it's also a weakness as
it becomes difficult to know what is built and how. I also wonder if we can
have one version of the external to support several versions of buildroot
or if we'll need to tag it according to the version of buildroot it has
been tested against. Do we put too much hope in the external?

If I try to summarize our options with their pros and cons:

- buildroot fork:
  - pros:
    - one tree
    - full control, can do whatever we want
  - cons:
    - fork
    - need to rebase patches for new releases
    - may not be able to keep the pace of buildroot releases

- buildroot external:
  - pros:
    - one tree
    - not dependent on buildroot version (in theory) so no rebase to do
  - cons:
    - can't modify buildroot package makefiles, only the source code
    - can't quickly solve bugs in buildroot
    - may have dependency on the buildroot version

- buildroot fork + external:
  - pros:
    - full control, can do whatever we want
    - less patches to rebase (only the ones on top of buildroot)
  - cons:
    - fork
    - two trees
    - may not be able to keep the pace of buildroot releases
    - may have buildroot fork with no patches on top of it sometime


If you have any suggestions, about improvements for Buildroot or the way we
manage our Buildroot offer, I would be happy to hear them.


Regards,

Ludovic