=20 =20 ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "infra" <infra@ovirt.org> Sent: Monday, May 5, 2014 6:39:53 PM Subject: Package building and build process
Hi!
Lately we had some issues when trying to build some of the projects, a= nd we wanted to start a discussion to clarify what do we want and how to get=
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ut5KeQuHDK9anwIkd85SuJEOGNdVSwa9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/05/2014 05:51 PM, Alon Bar-Lev wrote: there.
We can split the thread if it gets too large for all the subjects.
The main points to discuss:
* How the source tarballs should be built =C2=B7 Should we use a jenkins job for it, so the maintainer just do=
wnloads the
tarball from it =C2=B7 Should we force the maintainer to build it and supply the tar=
ball himself
=C2=B7 Should we allow both =20 Not sure why you manage this discussion. You just forgot to mention that up until now it worked perfectly ok, we= had a job to build releases out of tarballs, and all worked perfectly. It was broken when you decided not to install certain dependencies on b= uild slaves.
Arising from different version of some projects requiring different versi= on of different packages and different test requiring different sources for the= same packages (testing against nightly, stable, pep8 latest, pep8 epel, ...) w= e had to introduce some job isolation, and reserving one slave for each job tha= t is running became unproductive and hard to maintain (at first, we had some s= laves for each project, then started installing and removing packages on each j= ob, then not only installing and removing packages but also repositories, iso= lating the build on the same slave became a necessity).
=20 Anyway... =20 This is up to maintainer to decide.
It's up to the CI/infra/release team to provide the platform to build the= projects for the maintainers to use.
Build infrastructure should be able to get upstream tarball (any upstre= am not just ovirt) and produce binaries for all our supported platforms a= s a service, just like koji, brew or any downstream service. The root resource of open source is the source tarball, this is the rel= ease not the binary. That's what the next point is about.
People here at ovirt tend to confuse what open source is. =20
* Separate source release from binary release
* Which tools to use to build the rpms =C2=B7 plain rpmbuild =C2=B7 Mock =C2=B7 Docker =C2=B7 copr =C2=B7 Open Build System =C2=B7 koji
=20 Once upstream releases source tarball, this is not important. This is the entire idea of open *SOURCE*. It might not be important to you, but we want to provide the easiest way = for the users to use oVirt, not only for someone to build it, having a binary rel= ease for the major platforms helps TREMENDOUSLY on getting users to use the pr= oduct.
=20
* How to organize the rpm/tar build jobs =C2=B7 One job for all the projects =C2=B7 One job per-project =20 If we cannot provide single job for generic tarball build, we have a hu= ge problem. I don't agree.
=20 I worked very hard with all maintainers (except vdsm) to be able to ach= ieve the standard sequence of: =20 # rpmbuild -tb <tarball>
You are not taking into account all the dependencies that rpmbuild -tb <t= arball> has, each project has it's own, and they are incompatible between project= s and between versions. And not just building the rpms, building the tarballs a= lso have some requirements that must be met. So building a package is not jus= t rpmbuild, but setup the repos, install packages, then rpmbuild, then clea= nup packages and restore repos.
=20 Regards, Alon Bar-Lev. =20
PD. Opened an etherpad to keep the points http://etherpad.ovirt.org/p/build_discussion -- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --Ut5KeQuHDK9anwIkd85SuJEOGNdVSwa9b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTZ7f3AAoJEEBxx+HSYmnDku8H/0fsG5LEkLYCc8X0j/XPWW/u X7rdoZuuLGaXjs966YmeM1sQD3VjtAg35qo1EXr/GdQesft0Ysn8zAzohjkrf+YH A/iX+QzC/N1M5mGYWgKTxCDDIdsxraQiLAQ14ykDhzAniF8UdGnmrRTdmUxBCbyh kZi7yMeD79iEJR1YoZY5oFY6CsBAdfeyZW6z3Gj7+deDhgOh9AtrsYVKvdvDmQVy 81WwAW5PWuMFPS1NuM7KrToaoiq1bsLO0Yj/8QdPJaaJ3BoybESchKsUr8f6SMXi jaKVXzX6axvZIqD4W+RKa1VPzGSj78edxjUlxvJITJz4j8OHL91l5GG11O1ztyU= =JVm7 -----END PGP SIGNATURE----- --Ut5KeQuHDK9anwIkd85SuJEOGNdVSwa9b--