[CentOS-devel] [altarch] multiarch docker images

Thu Jan 28 10:18:10 UTC 2016
Manfred Touron <mtouron at scaleway.com>

On 28 Jan 2016, at 07:34, Fabian Arrotin <arrfab at centos.org> wrote:
> more or less, yes, and that's how the actual armhfp .img files were
> created (yum --installroot=)

I will try to play with this, thanks

> As said before on irc, have a look at https://github.com/mndar/rbf <https://github.com/mndar/rbf>(and for example
> https://github.com/arrfab/rbf/blob/master/templates/centos-cubietruck.xml <https://github.com/arrfab/rbf/blob/master/templates/centos-cubietruck.xml>)

Does rbf works for non-arm images ? Can you provide an x86_64 example on the repository ?
rbf sounds really really good if it is not limited to the arm architecture.

> BTW, if you just need the RootFS, why not using one of the generated
> images, and get what you need from that image ?

Actually it works, but it results in doing:

- x86_64, i386 -> build an image from its kickstart + boot.iso disk == a minimal ready to use image, easy to read on GitHub (perfect)
- arm, mips, powerpc, arm64 -> import a disk image, then yum remove everything not needed, export the image and reimport it to avoid non-effective file removals due to Docker copy-on-write layering system.

Basically it will work, but it is harder to maintain, something like maintaining a `yum remove $(diff <(yum list x86_64 images) <(yum list arm image)).`
The image build procedure will also be more obscure.

This solution is my fallback if we can’t achieve to find a generic way to build CentOS on all architectures.

Manfred Touron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20160128/986a6ecd/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20160128/986a6ecd/attachment-0008.sig>