On Sun, Sep 25, 2016 at 01:19:21PM +0000, Alexandru Avadanii wrote: > Hi, Luke, > My experience so far included mostly DEB packages, which fell in 3 categories > for Armband: > > - Backported from newer distro (lots of Ubuntu Xenial arm64 DEBs > backported to Trusty) > > - Patched until upstream pulls our fixes (lshw is a good example, > it’s broken in all arm64 Ubuntus - all distros) > > - Divergent functionality (we roll our own grub2, based on an Ubuntu > pacakge, but with added patches from Fedora and OpenSUSE – it’s hard to fiind > a grub2 package that satifies all conditions for integrating with our Cobbler > integration approach) > > As for RPMs, we built only 2 custom packages, which I’m sure won’t be > upstreamed soon: > > - qemu-user-static for CentOS7 (implied building some static libs as > well, including libc), which is used by Fuel to cross-build images (e.g. > arm64 chroots on a x86 machine); > > - cobbler-grub-aarch64 (contains a single EFI-compatible arm64 > binary of grub2-efi-arm64 standalone, used by cobbler as the netloader of > choice for Armband) > > In my opinion, handlng the above by hand or using obscure external procedures > (most Fuel plugins build some DEBs and/or RPMs, each in a different way) is > prone to error > and code duplication over time. > > Also, and maybe I should have started with this, consider the case where the > ISO build process is tied to x86 (like Fuel currently is), and the artifacts > are expected to contain > packages for different architectures (AArch64?), which cannot be locally > built [easily], in which case fetching some precompiled packages from an > OPNFV public repo would be nice.
Do you have a particular method in mind here? I think my biggest issue would be around building yet another system to build packages. For example, for RPMs, it would be almost trivial to employ the COPR build system and host any custom packages in that namespace. What I would hate to see, would be a set of custom scripts or applications to build packages, and then host them within the OPNFV namespace, along with having to maintain that whole pipeline. I assume there is some sort of DEB equivalent of COPR where those packages could be hosted, and packages build on a remote service? -- Leif Madsen | Partner Engineer - NFV & CI NFV Partner Engineering Red Hat GPG: (D670F846) BEE0 336E 5406 42BA 6194 6831 B38A 291E D670 F846 _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss