[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Doing away with 'groups' repo in mock



Jesse Keating schrieb:
> Currently mock configs make use of a 'groups' repo to provide 
> a 'buildsys-build' meta-package.  This meta-package has a set of Requires: 
> that are used to create the 'minimal buildroot' mock uses to start builds.  
> This repo also provides a 'buildsys-macros' package.  Historically this 
> package would define things like the %dist tag and post-build actions.
> 
> Today, in rawhide, fedora-release provides the %dist like macro definitions.  
> The post-build definition can be moved to redhat-rpm-config as well.  This 
> would obviate the need for buildsys-macros.  That would just leave the 
> meta-package to populate the buildroot.
> 
> Since mock supports installing a group rather than a (meta)package, I propose 
> we define the buildsys-build group in the comps group directly.  This would 
> obviate the need for a single point of failure within mock building, 
> the 'groups' repo.
> 
> Here is the change I would make to comps:
> 
> diff -u -r1.28 comps-f8.xml.in
> --- comps-f8.xml.in     27 Jun 2007 20:47:51 -0000      1.28
> +++ comps-f8.xml.in     28 Jun 2007 17:27:19 -0000
> @@ -486,6 +486,33 @@
>      </packagelist>
>    </group>
>    <group>
> +    <id>buildsys-build</id>
> +    <_name>Buildsystem building group</_name>
> +    <_description/>
> +    <default>false</default>
> +    <uservisible>false</uservisible>
> +    <packagelist>
> +      <packagereq type="mandatory">bash</packagereq>
> +      <packagereq type="mandatory">bzip2</packagereq>
> +      <packagereq type="mandatory">coreutils</packagereq>
> +      <packagereq type="mandatory">cpio</packagereq>
> +      <packagereq type="mandatory">diffutils</packagereq>
> +      <packagereq type="mandatory">fedora-release</packagereq>
> +      <packagereq type="mandatory">gcc</packagereq>
> +      <packagereq type="mandatory">gcc-c++</packagereq>
> +      <packagereq type="mandatory">gzip</packagereq>
> +      <packagereq type="mandatory">make</packagereq>
> +      <packagereq type="mandatory">patch</packagereq>
> +      <packagereq type="mandatory">perl</packagereq>
> +      <packagereq type="mandatory">redhat-rpm-config</packagereq>
> +      <packagereq type="mandatory">rpm-build</packagereq>
> +      <packagereq type="mandatory">sed</packagereq>
> +      <packagereq type="mandatory">tar</packagereq>
> +      <packagereq type="mandatory">unzip</packagereq>
> +      <packagereq type="mandatory">which</packagereq>
> +    </packagelist>
> +  </group>
> +  <group>
>      <id>bulgarian-support</id>
>      <_name>Bulgarian Support</_name>
>      <_description/>
> 
> The comps change can be made at any time, however changes to mock need to be 
> coordinated with the maintainer for redhat-rpm-config.  I'd also like to 
> move /usr/lib/rpm/check-buildroot out of rpmdevtools and into one of the 
> packages already being pulled into the buildroot (redhat-rpm-config perhaps, 
> since it will be referencing it?), and thus we'll need to coordinate with the 
> rpmdevtools maintainer.
> 
> We wouldn't be doing away with mock's ability to just use a meta-package to 
> populate the root, so those that want to alter what goes into the buildroot 
> can (just like before) build your own buildsys-build package and host it for 
> your mock, or define your own comps grouping, etc...  
> 
> Comments?

+1

For default mocks this makes sense.

-of


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]