RE: mock goals and non-goals
-----Original Message-----
From: fedora-buildsys-list-bounces(a)redhat.com
[mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of
Andreas Thienemann
Sent: Thursday, May 11, 2006 2:10 PM
To: Discussion of Fedora build system
Subject: Re: mock goals and non-goals
Hello,
On Thu, 11 May 2006, seth vidal wrote:
> goals:
> - make clean and consistent build environments to be used
by fedora's
> buildsystem and packagers
> - simplify building and testing process for packagers
> - be able to canonically identify the 'build environment'
for fedora
> systems to discourage confusion on what should be where
> - simple interface with good defaults.
Why not a bit more generic and see mock as a tool to build
rpms in a clean and consistent buildroot. After all, we heard
that SuSE RPMs can be built with it too. And that's a feat s
the last time I looked SuSE RPMs were pretty bad dependency-wise.
SuSE has taken a little bit of work to get working with mock. My
position, though, is that I cannot afford, time-wise, the effort it
would take to set up hundreds of different build environments for every
distro out there. It is much more efficient for me to just add the extra
bits to support SUSE in mock. I really would like to see one build
environment to rule them all(TM). Mock seems simple, flexible, and
extensible enough to handle lots of different distros with a modicum of
cooperation from the distros. Yes, there are a few problems, and no, you
cannot do an entire distro build of SUSE out of the box. But it works
for my stuff, which is all I need.
From my perspective, every major rpm-based distro coming out has
native
yum support, so mock (built on yum) looks like the winner.
> - specifying multiple srpms on the command line for a
SINGLE config -
> provided that the buildroot is refreshed/cleaned each time
- unless,
> of
This time, I do not really see the difference between calling
mock with several srpms and calling mock several times on the shell.
It is just a matter of complexity. The added complexity in my script to
handle this is a pain, but inside mock itself, the changes are minimal.
Or, stated another way, the total system complexity is smaller doing
this inside mock.
> course, the --no-clean option is passed in
> - caching mechanism to create a cached pristine chroot that
will allow
> for quickly recreating the chroot into that state simply by putting
> that cached copy back.
This would be simply great. Right now, the cycle of cearting
the chroot, installing the base-packages, doing the full
depsolve-cycle, building the rpm and then removing the
buildroot again takes ages.
Something faster there might be great.
Seconded.
--
Michael