mock goals and non-goals

[seth vidal]

Hi folks,
 Given the patchfest from yesterday I felt it would be best to have some
discussion of goals/non-goals for mock in/around fedora's build
environment.

This is my opinion on the subject. It is not final nor terminal, it just
is where I am:


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.

non-goals:
- this is not a tool to manage many, many builds with queuing, etc -
that is plague.



So, with regard to the patches we've seen so far here's what makes sense
to me:
- global/shared config to reduce the replication in the mock configs
- specifying multiple srpms on the command line for a SINGLE config -
provided that the buildroot is refreshed/cleaned each time - unless, of
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. 

Patches that don't make sense to me:
- multiconfig - this is what shells and/or plague is for, use one of
them.
- parallel builds - plague is your friend.


Patches which I am ambivalent about:
- the fake buildreqs/sneaky buildreqs patch for rebuilding items with
BROKEN buildrequires:
   - I hate the idea of enabling broken shit
   - I realize that there are lots of broken things that people need to
work around and I'm sympathetic to that, to some extent. Doesn't mean I
can't hate it.


so, there, my flames are all away, feel free to bombard me with your
own.

-sv

[Andreas Thienemann]

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.

>  non-goals:
>  - this is not a tool to manage many, many builds with queuing, etc -
>  that is plague. 
ack IMHO. Even though plague needs still a bit of work it seems.
livna's 
plague installation only became stable as soon as I sent them a few 
patches, which dcbw handed me on irc after bugging him about a few 
problems. ;-D
 
>  - 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.

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

>  Patches which I am ambivalent about:
>  - the fake buildreqs/sneaky buildreqs patch for rebuilding items with
>  BROKEN buildrequires:
>     - I hate the idea of enabling broken shit
>     - I realize that there are lots of broken things that people need to
>  work around and I'm sympathetic to that, to some extent. Doesn't mean I
>  can't hate it. 
Well, nobody expects you to like it, it just has to be in mock.
;-D 


bye,
 andreas

[seth vidal]

On Thu, 2006-05-11 at 21:10 +0200, Andreas Thienemann wrote:
>  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. 
then the suse config would have a different buildsys-build package/set
of pkgs.

>  non-goals:
>  > - this is not a tool to manage many, many builds with queuing, etc -
>  > that is plague.
>  ack IMHO. Even though plague needs still a bit of work it seems. livna's 
>  plague installation only became stable as soon as I sent them a few 
>  patches, which dcbw handed me on irc after bugging him about a few 
>  problems. ;-D 

which is why plague gets worked on. good.



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

look at the caching patch jochen submitted some time back. Clean it up
and write up what it is it does and we'll put it in.


>  > Patches which I am ambivalent about:
>  > - the fake buildreqs/sneaky buildreqs patch for rebuilding items with
>  > BROKEN buildrequires:
>  >    - I hate the idea of enabling broken shit
>  >    - I realize that there are lots of broken things that people need to
>  > work around and I'm sympathetic to that, to some extent. Doesn't mean I
>  > can't hate it.
>  Well, nobody expects you to like it, it just has to be in mock. ;-D  
which is why  i put it under ambivalence.

-sv

[Hans Ulrich Niedermann]

seth vidal <skvidal(a)linux.duke.edu&gt; writes:

>  Patches which I am ambivalent about:
>  - the fake buildreqs/sneaky buildreqs patch for rebuilding items with
>  BROKEN buildrequires:
>     - I hate the idea of enabling broken shit
>     - I realize that there are lots of broken things that people need to
>  work around and I'm sympathetic to that, to some extent. Doesn't mean I
>  can't hate it. 
Would it help if I tried to sell you that feature as a "build
dependency problem debugging tool"?

These are the arguments:

 1. Allowing an easy way add fake buildreqs allows one to easily add,
    remove again and thus test build dependencies in a reproducible
    way. This helps greatly to determine the exact set of missing
    builddeps.

 2. The additional builddeps determined in step 1. are in a simple and
    convenient data format for conversion into a bug reports to the
    respective package maintainers.

Documenting the feature using this line of reasoning might also help
people get the right idea and do the right thing.

Uli