Hi, Luke, Leif, Thank you for your feedback!
I do not have any preferences towards the method we use, if we can use something as-is, I'm all for it. I was not aware of COPR, but I'll try to get up to speed and add it to the etherpad. As for PPA, that is an interesting approach I haven’t thought about … any thoughts on using a private PPA for each OPNFV project? Ideally, end-users should also be able to submit fixes/patches that we can easily check into our packaging source tree – not sure PPA fits very well this requirement (?). If you have any other suggestions for a DEB alternative, I really want to hear them, so far the most interesting solution would be Perestroika from Mirantis, shipped as part of Fuel@OPNFV. So far, we used git-buildpackage and custom scripts for DEB building, but that is neither easy to maintain, nor is it an integrated, ready-to-use solution. BR, Alex From: Luke Hinds [mailto:lhi...@redhat.com] Sent: Tuesday, September 27, 2016 1:20 PM To: Leif Madsen Cc: Alexandru Avadanii; opnfv-tech-discuss@lists.opnfv.org Subject: Re: [opnfv-tech-discuss] OPNFV Packaging CI On Tue, Sep 27, 2016 at 1:55 AM, Leif Madsen <lmad...@redhat.com<mailto:lmad...@redhat.com>> 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 opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss