[Buildroot] [PATCH v3 2/2] package/buildah: new package

[Christian Stewart]

Yann,

On Sun, Aug 21, 2022, 8:14 AM Yann E. MORIN <yann.morin.1998 at free.fr> wrote:

> On 2022-01-26 12:25 -0800, Christian Stewart via buildroot spake thusly:
> > Adds both host and target packages for buildah.
>
> I would question the need for having buildah on the target. Buildah is
> advertised as: "A tool that facilitates building OCI container images."
> I don't see a good reason for building images *on* the target. Please
> explain in the commit log why that would make sense to have buildah on
> the target.
>

Building container images with a tool like "docker build" on the target is
an extremely common practice. There are numerous reasons to do so. Almost
none of the container images I use on devices were built ahead of time,
rather on the target device. I don't see why it's necessary to explain that
on every commit message.

> The buildah tree does not ship with a default policy.json file, and
> instead
> > relies on packagers to provide one. A patch is added to create a basic
> barebones
> > policy.json which is installed to /etc/containers/policy.json with a
> hook.
>
> Don't add a patch; just add that as a file in the Buildroot tree, e.g.
> package/buildah/policy.json, and install that from the package dir, i.e
> $(BUILDAH_PKGDIR)/policy.json rather than from $(@D)/..../policy.json.
>

Did a similar thing to this with the upcoming podman package. Will update.

On 2022-01-27 12:31 -0800, Christian Stewart via buildroot spake thusly:
> > On Thu, Jan 27, 2022 at 12:01 AM Thomas Petazzoni
> > <thomas.petazzoni at bootlin.com> wrote:
> > > Considering that there are runtime dependency concerns, it would be
> > > nice to have a simple test case in support/testing/.
> > OK, something like "buildah pull" or so?
>
> A runtime test should validate that the package works as expected, in a
> minimal way. So, if 'buildah pull' can prove that runtime dependencies
> are exercised, then that's OK, yes.
>
> Obviously if runtiem dependencies are only required for specific cases
> and only "loaded" when needed, we will not notice any missing ones. But
> having an exhaustive test is not very important either; we do not want
> to have to run the full project's test-suite...
>

I would argue that in this case if the package compiles at all it will
work, as per the upstream tests. Not sure if it's really worth the time to
add the extra test here.

> > However, for LDFLAGS, it's a bit weird, as normally,
> > > LDFLAGS are different between host and target. However here, there are
> > > mostly used to pass these version-related -X options, that are in fact
> > > the same between host and target. Should we have a separate variable to
> > > pass those flags ? Not sure.
> > They are quite common for Go packages - could call them DEFINES or
> > something similar.
>
> But with LDFLAGS, it is possible to pass flags to the actual linker,
> with -extldflags something-something, so they should not be
> automatically inherited.
>
> And if we had something the DEFINES you hint at, they would again be
> different by default, because the host and target builds do not follow
> the same logic.
>

We are defining the Version here, which is the same on the host and target.

Thanks,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildroot.org/pipermail/buildroot/attachments/20220821/4660d85f/attachment-0001.html>