> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
