On Tue, Sep 27, 2016 at 1:55 AM, Leif Madsen <[email protected]> wrote:
> 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? > > There is PPA (): https://help.launchpad.net/Packaging/PPA > -- > 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 [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
