-----BEGIN PGP SIGNED MESSAGE-----
Thomas Vander Stichele wrote:
On Tue, 2006-03-28 at 10:05 -0500, seth vidal wrote:
> So it was brought up a while ago that due to the changing nature of the
>comps.xml format that we should not rely on it for the buildroot
>installations in mock. The idea a while back was to just have a
>'buildroot' rpm that required all the stuff that would normally be in
>the comps.xml group. Then we could just install that rpm and it pulls in
>the rest of the buildroot components.
I think it's wrong to pollute the rpm collection with an rpm that only
ever is useful for one specific program. In the past people have
already objected to more generally useful umbrella packages, and those
at least served an end user purpose.
I'm not sure I understand your objection. I don't believe you'd see
these rpms in general circulation (I would guess they would be
delivered as a component of the mock package, right Seth?). The only
place they'd be installed is a chroot that is being managed by mock.
The only purpose behind them would be to provide BuildDeps to tell rpm
what needs to be installed in the chroot. If I understand the basic
idea, the RPM would be the only thing mock/yum/rpm would be told to
install, then the builddeps from the rpm would cause the chroot to be
This probably won't come as a surprise, but I think that a build tool's
idea of what it needs to pull in should be maintained in the build tool,
and not outside of it. It's not like it's hard work :)
Why not just use a spec file as the format? While I know it's not a
nicely formed, easily parsed format, it's well known and familiar to
most of us. Yeah, I know that mock's "unit of operation" is a chroot
configuration (as opposed to yum's unit of operation: rpms), but I'd
rather not invent a new configuration file. I like the idea of
centralizing the contents of a chroot configuration and a spec file
seems as easy as anything else.
One thing I like about the idea is that I could customize my chroot's
by modifying one of the supplied specfiles. The mock package could
manage two or three packages (buildsys-base, buildsys-max,
buildsys-min) and if I wanted something in between I could grab one,
change the name and modify the builddeps to my hearts content.
Just my $0.02 worth.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v220.127.116.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----