public inbox for [email protected]  
help / color / mirror / Atom feed
From: Craig Ringer <[email protected]>
To: Devrim GÜNDÜZ <[email protected]>
Cc: pgsql-pkg-yum <[email protected]>
Subject: Re: New and unified 9.5 spec file is in git
Date: Thu, 21 Jan 2016 09:21:14 +0800
Message-ID: <CAMsr+YFS-fm_BbdqHj69tfZbnAYozoX4j+BNFkCM3hSqeBPp7A@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAMsr+YFqaX7shapoLRJ2S7QD1vst9ENrOtGU-_OD18Z=vpoHTA@mail.gmail.com>
	<CAMsr+YFNvjv1NDwuFqBvvg9SV4h1Y-CFVTwaLM4MJ5FHFg3o5w@mail.gmail.com>
	<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-pkg-yum>

On 21 January 2016 at 04:17, Devrim GÜNDÜZ <[email protected]> wrote:


> > 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.

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


view thread (11+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: New and unified 9.5 spec file is in git
  In-Reply-To: <CAMsr+YFS-fm_BbdqHj69tfZbnAYozoX4j+BNFkCM3hSqeBPp7A@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox