MIME-Version: 1.0
In-Reply-To: <1453321034.24314.446.camel@gunduz.org>
References: <1453239881.24314.362.camel@gunduz.org>
 <CAMsr+YFqaX7shapoLRJ2S7QD1vst9ENrOtGU-_OD18Z=vpoHTA@mail.gmail.com>
 <CAMsr+YFNvjv1NDwuFqBvvg9SV4h1Y-CFVTwaLM4MJ5FHFg3o5w@mail.gmail.com>
 <1453321034.24314.446.camel@gunduz.org>
Date: Thu, 21 Jan 2016 09:21:14 +0800
Message-ID: 
 <CAMsr+YFS-fm_BbdqHj69tfZbnAYozoX4j+BNFkCM3hSqeBPp7A@mail.gmail.com>
Subject: Re: New and unified 9.5 spec file is in git
From: Craig Ringer <craig@2ndquadrant.com>
To: =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= <devrim@gunduz.org>
Cc: pgsql-pkg-yum <pgsql-pkg-yum@postgresql.org>
Content-Type: multipart/alternative; boundary=001a11420fba31a4200529cdeb12
Precedence: bulk
Sender: pgsql-pkg-yum-owner@postgresql.org

--001a11420fba31a4200529cdeb12
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 21 January 2016 at 04:17, Devrim G=C3=9CND=C3=9CZ <devrim@gunduz.org> wr=
ote:


> > I'm really happy about this, since it means the build depends are now
> > correct and it can be built without needing a dedicated build machine
> > using nothing but mock. No need to manually set up dependencies
> > anymore, set up a build box, etc. No need to juggle x86_64 and i386
> > either, you can run builds for *everything* from a single F23 box or
> > VM or docker or whatever.
>
> Well, we are building 100+ packages in 9.5 set. Setting up a new mock
> environment everytime would slow us down, IMHO. What do you think?
>

mock caches the build env so in practice it's very fast. mockchain helps
even more.

mock is what Koji uses and what's used to build all of Fedora and EPEL, so
it gets a fair bit of performance attention. There _is_ a performance cost
vs building bare on a preconfigured build box but it's (IMO) greatly offset
by the increased reliability and consistency of package builds. You don't
risk having undeclared dependencies, building against a version other than
the one declared in the spec file, etc.


> > If the same process is followed for other packages
>
> *All* of the *recently added* spec files are unified nowadays :)


Great!


> >  it's less of an issue than when the build boxes are hand-maintained,
> > but the great thing about mock is that it gets all the build depends
> > info straight from the spec file.
>
> All deps are already installed on our build servers. If not, we install
> them before building a new package.
>

That can cause issues though. For example I think that's how the Java 8
problems a while ago happened. The spec file declared a dependency on
openjdk 7 but the rpms were built against what was locally installed, which
is openjdk 8.

The nice thing with mock is that the buildroot can contain only exactly the
required packages for a build. No extras. It provides a lot more confidence
that the spec matches the actual build and that anyone can reproduce the
package build consistently without a special hand-created build env.

I've been using it for the BDR and pglogical builds and it does a pretty
good job. It's helped me find a number of bugs and oversights too.

--=20
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

--001a11420fba31a4200529cdeb12
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
1 January 2016 at 04:17, Devrim G=C3=9CND=C3=9CZ <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:devrim@gunduz.org" target=3D"_blank">devrim@gunduz.org</a>&gt=
;</span> wrote:<br><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">&gt; I&#39;m really happy about this, since it means the build dep=
ends are now<br>
&gt; correct and it can be built without needing a dedicated build machine<=
br>
&gt; using nothing but mock. No need to manually set up dependencies<br>
&gt; anymore, set up a build box, etc. No need to juggle x86_64 and i386<br=
>
&gt; either, you can run builds for *everything* from a single F23 box or<b=
r>
&gt; VM or docker or whatever.<br>
<br>
</span>Well, we are building 100+ packages in 9.5 set. Setting up a new moc=
k<br>
environment everytime would slow us down, IMHO. What do you think?<br></blo=
ckquote><div><br></div><div>mock caches the build env so in practice it&#39=
;s very fast. mockchain helps even more.</div><div><br></div><div>mock is w=
hat Koji uses and what&#39;s used to build all of Fedora and EPEL, so it ge=
ts a fair bit of performance attention. There _is_ a performance cost vs bu=
ilding bare on a preconfigured build box but it&#39;s (IMO) greatly offset =
by the increased reliability and consistency of package builds. You don&#39=
;t risk having undeclared dependencies, building against a version other th=
an the one declared in the spec file, etc.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><span class=3D"">&gt; If the same process is followed =
for other packages<br>
<br>
</span>*All* of the *recently added* spec files are unified nowadays :)</bl=
ockquote><div><br></div><div>Great!</div><div>=C2=A0</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span class=3D"">&gt;=C2=A0 it&#39;s less of=
 an issue than when the build boxes are hand-maintained,<br>
&gt; but the great thing about mock is that it gets all the build depends<b=
r>
&gt; info straight from the spec file.<br>
<br>
</span>All deps are already installed on our build servers. If not, we inst=
all<br>
them before building a new package.<br></blockquote><div><br></div><div>Tha=
t can cause issues though. For example I think that&#39;s how the Java 8 pr=
oblems a while ago happened. The spec file declared a dependency on openjdk=
 7 but the rpms were built against what was locally installed, which is ope=
njdk 8.</div><div><br></div><div>The nice thing with mock is that the build=
root can contain only exactly the required packages for a build. No extras.=
 It provides a lot more confidence that the spec matches the actual build a=
nd that anyone can reproduce the package build consistently without a speci=
al hand-created build env.</div><div><br></div><div>I&#39;ve been using it =
for the BDR and pglogical builds and it does a pretty good job. It&#39;s he=
lped me find a number of bugs and oversights too.</div></div><div><br></div=
>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"lt=
r">=C2=A0Craig Ringer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <a href=3D"http://ww=
w.2ndQuadrant.com/" target=3D"_blank">http://www.2ndQuadrant.com/</a><br>=
=C2=A0PostgreSQL Development, 24x7 Support, Training &amp; Services<br></di=
v></div></div></div>
</div></div>

--001a11420fba31a4200529cdeb12--