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?
On Thursday 28 June 2007, Jesse Keating wrote:
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.
I'm very much fine with that. In fact, I filed a RFE about it a couple of days ago: https://bugzilla.redhat.com/245639
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jesse Keating wrote:
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?
Works for me. I still use the buildsys-build RPM locally, but as long as we keep that ability around I'm fine.
+1
Clark
On Thu, Jun 28, 2007 at 02:15:26PM -0500, Clark Williams wrote:
Jesse Keating wrote:
Comments?
Works for me. I still use the buildsys-build RPM locally, but as long as we keep that ability around I'm fine.
Since this is set up in: config_opts['chroot_setup_cmd'] = 'install buildsys-build'
I don't see the ability to Have It Your Way(TM) going away any time soon.
In the new mock configs using the new comps file, we just change that to 'groupinstall buildsys-build' and be done with it.
SQOTD(*) for Jesse: How does yum find the comps file? I dont see where in yum it initializes the comps file, and I need to know this for my local yum setup. I see that comps-f7.xml is in repodata, but I dont see how it is found/initialized.
-- Michael
(*) Stupid Question Of The Day
On Do Juni 28 2007, Michael E Brown wrote:
SQOTD(*) for Jesse: How does yum find the comps file? I dont see where in yum it initializes the comps file, and I need to know this for my local yum setup. I see that comps-f7.xml is in repodata, but I dont see how it is found/initialized.
It is referenced in repomd.xml
Regards, Till
On Thu, Jun 28, 2007 at 10:07:05PM +0200, Till Maas wrote:
On Do Juni 28 2007, Michael E Brown wrote:
SQOTD(*) for Jesse: How does yum find the comps file? I dont see where in yum it initializes the comps file, and I need to know this for my local yum setup. I see that comps-f7.xml is in repodata, but I dont see how it is found/initialized.
It is referenced in repomd.xml
Cool. Thanks. I tried grep, but the output was... unhelpful. -- Michael
On Thu, 2007-06-28 at 13:52 -0400, Jesse Keating wrote:
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.
ISTR that we were populating the mock buildroot by installing a comps.xml group before, and then we switched to a meta-package[1]. In fact, you (Jesse) were in favor of the idea[2]. What's changed in the last year that you'd like to go *back* to using comps.xml and groupinstall?
I'm in favor of eliminating the groups repo and hosting the buildsys-build RPM in the regular package CVS & mirrors but I'm not in favor of going back to using comps.xml groups unless there's a good explanation of why we should switch back...
[1] http://www.redhat.com/archives/fedora-buildsys-list/2006-March/msg00016.html [2] http://www.redhat.com/archives/fedora-buildsys-list/2006-March/msg00022.html
Jeff
Hi Jeff!
Jeffrey C. Ollie schrieb:
On Thu, 2007-06-28 at 13:52 -0400, Jesse Keating wrote:
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.
ISTR that we were populating the mock buildroot by installing a comps.xml group before, and then we switched to a meta-package[1]. In fact, you (Jesse) were in favor of the idea[2]. What's changed in the last year that you'd like to go *back* to using comps.xml and groupinstall?
I'm in favor of eliminating the groups repo and hosting the buildsys-build RPM in the regular package CVS & mirrors but I'm not in favor of going back to using comps.xml groups unless there's a good explanation of why we should switch back...
[1] http://www.redhat.com/archives/fedora-buildsys-list/2006-March/msg00016.html [2] http://www.redhat.com/archives/fedora-buildsys-list/2006-March/msg00022.html
I think Jesse wasn't talking about changing anything in the buildsys, only add default buildsys-build group to default comps.xml, for default mocks. And fp.o does no longer need to host the groups repo somewhere. Something that isn't needed for koji.
koji does provide it's own buildsys-build pkg, which is recreated every time a new repo is created; Also a new comps.xml is created every time... And it's maintained via koji group stuff... So for the buildsys, it doesn't matter....
Correct me Jesse, if Jeff interpreted it correctly and I did not :-)
-of
On Thursday 28 June 2007 15:28:16 Oliver Falk wrote:
koji does provide it's own buildsys-build pkg, which is recreated every time a new repo is created; Also a new comps.xml is created every time... And it's maintained via koji group stuff... So for the buildsys, it doesn't matter....
Correct me Jesse, if Jeff interpreted it correctly and I did not :-)
Well, koji doesn't create a buildsys-build package, instead each tag can have group information, and that group information is used at repo creation time for said tag and defines a build group that is installed into the chroot. But it is all managed within Koji itself.
On 06/28/2007 11:16 PM, Jesse Keating wrote:
On Thursday 28 June 2007 15:28:16 Oliver Falk wrote:
koji does provide it's own buildsys-build pkg, which is recreated every time a new repo is created; Also a new comps.xml is created every time... And it's maintained via koji group stuff... So for the buildsys, it doesn't matter....
Correct me Jesse, if Jeff interpreted it correctly and I did not :-)
Well, koji doesn't create a buildsys-build package,
fyi.
[oliver@tuborg ~]$ for i in /mnt/koji/repos/dist-f8-build/47?; do ls -ld $i $i/alpha/RPMS/buildsys-build*; done drwxr-xr-x 4 apache apache 4096 2007-06-29 02:44 /mnt/koji/repos/dist-f8-build/470 -rw-r--r-- 2 apache apache 1612 2007-06-29 02:44 /mnt/koji/repos/dist-f8-build/470/alpha/RPMS/buildsys-build-1-1.noarch.rpm drwxr-xr-x 4 apache apache 4096 2007-06-29 02:48 /mnt/koji/repos/dist-f8-build/471 -rw-r--r-- 2 apache apache 1612 2007-06-29 02:48 /mnt/koji/repos/dist-f8-build/471/alpha/RPMS/buildsys-build-1-1.noarch.rpm drwxr-xr-x 4 apache apache 4096 2007-06-29 08:43 /mnt/koji/repos/dist-f8-build/472 -rw-r--r-- 2 apache apache 1612 2007-06-29 08:43 /mnt/koji/repos/dist-f8-build/472/alpha/RPMS/buildsys-build-1-1.noarch.rpm drwxr-xr-x 4 apache apache 4096 2007-06-29 09:00 /mnt/koji/repos/dist-f8-build/473 -rw-r--r-- 2 apache apache 1612 2007-06-29 09:01 /mnt/koji/repos/dist-f8-build/473/alpha/RPMS/buildsys-build-1-1.noarch.rpm
instead each tag can have group information, and that group information is used at repo creation time for said tag and defines a build group that is installed into the chroot. But it is all managed within Koji itself.
-of
On Friday 29 June 2007 03:08:43 Oliver Falk wrote:
fyi.
[oliver@tuborg ~]$ for i in /mnt/koji/repos/dist-f8-build/47?; do ls -ld $i $i/alpha/RPMS/buildsys-build*; done drwxr-xr-x 4 apache apache 4096 2007-06-29 02:44 /mnt/koji/repos/dist-f8-build/470 -rw-r--r-- 2 apache apache 1612 2007-06-29 02:44 /mnt/koji/repos/dist-f8-build/470/alpha/RPMS/buildsys-build-1-1.noarch.rpm
Hrm, Perhaps I slightly misunderstood what koji was doing with the group info, but this still happens behind the scenes and is managed by koji itself. The repodata that koji creates has the buildsys-build group information as well, so perhaps the creation of the buildsys-build package is a carryover from early iterations of koji.
On Friday 29 June 2007 08:22:38 Jesse Keating wrote:
The repodata that koji creates has the buildsys-build group information
Erm, make that 'build' group information.
$ cat /mnt/koji/static-repos/dist-f8-build-current/i386/repodata/comps.xml <?xml version="1.0"?> <!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd">
<!-- Auto-generated by the build system --> <comps> <group> <id>build</id> <name>build</name> <description>None</description> <default>false</default> <uservisible>true</uservisible> <packagelist> <packagereq type="default">bash</packagereq> <packagereq type="default">bzip2</packagereq> <packagereq type="default">coreutils</packagereq> <packagereq type="default">cpio</packagereq> <packagereq type="default">diffutils</packagereq> <packagereq type="default">fedora-release</packagereq> <packagereq type="default">gcc</packagereq> <packagereq type="default">gcc-c++</packagereq> <packagereq type="default">gzip</packagereq> <packagereq type="default">make</packagereq> <packagereq type="default">patch</packagereq> <packagereq type="default">perl</packagereq> <packagereq type="default">perl-devel</packagereq> <packagereq type="default">redhat-rpm-config</packagereq> <packagereq type="default">rpm-build</packagereq> <packagereq type="default">sed</packagereq> <packagereq type="default">tar</packagereq> <packagereq type="default">unzip</packagereq> <packagereq type="default">which</packagereq> </packagelist> </group> </comps>
Jesse Keating schrieb:
On Friday 29 June 2007 03:08:43 Oliver Falk wrote:
fyi.
[oliver@tuborg ~]$ for i in /mnt/koji/repos/dist-f8-build/47?; do ls -ld $i $i/alpha/RPMS/buildsys-build*; done drwxr-xr-x 4 apache apache 4096 2007-06-29 02:44 /mnt/koji/repos/dist-f8-build/470 -rw-r--r-- 2 apache apache 1612 2007-06-29 02:44 /mnt/koji/repos/dist-f8-build/470/alpha/RPMS/buildsys-build-1-1.noarch.rpm
Hrm, Perhaps I slightly misunderstood what koji was doing with the group info, but this still happens behind the scenes and is managed by koji itself. The repodata that koji creates has the buildsys-build group information as well, so perhaps the creation of the buildsys-build package is a carryover from early iterations of koji.
Since I set up koji for AlphaCore, I know it very well now... :-) And you're totally correct, koji also creates a comps.xml in repodata where it provides the same information. Koji does both and I've never tried to find out which way is the faster one - I guess difference could only be measured in milliseconds and nobody should mind :-)
Best, Oliver
On Thursday 28 June 2007 15:15:27 Jeffrey C. Ollie wrote:
ISTR that we were populating the mock buildroot by installing a comps.xml group before, and then we switched to a meta-package[1]. In fact, you (Jesse) were in favor of the idea[2]. What's changed in the last year that you'd like to go *back* to using comps.xml and groupinstall?
I'm pretty sure that around this time comps format was changing, and it had to be managed outside the Fedora comps. Now I'm talking about doing it within Fedora comps so that most users don't have to mess with it at all, and things like yum are much more stable with comps. We can't introduce comps changes that yum can't cope with (which may mean bumping yum, but that's fine)
Le Jeu 28 juin 2007 23:19, Jesse Keating a écrit :
We can't introduce comps changes that yum can't cope with (which may mean bumping yum, but that's fine)
Can we have *one* package in the distro ship what a comps file is supposed to look like at any time (in DTD/xml-schema/relax-ng)? Pretty please? With comments about what each part does even?
Makes it so much easier to identify where's the problem when a comps makes apps fail.
On Friday 29 June 2007 03:34:47 Nicolas Mailhot wrote:
Can we have *one* package in the distro ship what a comps file is supposed to look like at any time (in DTD/xml-schema/relax-ng)? Pretty please? With comments about what each part does even?
Makes it so much easier to identify where's the problem when a comps makes apps fail.
Care to create one? We could drop it in as a %doc or example somewhere.
Le Ven 29 juin 2007 14:23, Jesse Keating a écrit :
On Friday 29 June 2007 03:34:47 Nicolas Mailhot wrote:
Can we have *one* package in the distro ship what a comps file is supposed to look like at any time (in DTD/xml-schema/relax-ng)? Pretty please? With comments about what each part does even?
Makes it so much easier to identify where's the problem when a comps makes apps fail.
Care to create one?
I wouldn't ask for one if I knew exactly what each comps tag is supposed to mean. notting stealthily dumped a comps dtd in our cvs so I suppose it's "official" and could be bundled with rpm/yum (or whatever package is supposed to own the comps format). It's not as nice as a modern annotated xml/relax-ng schema but it's a beginning.
We could drop it in as a %doc or example somewhere.
I'd rather it was registered properly in the system xml catalogs so xml tools (vim/emacs/libxml...) just know the comps structure.
On Friday 29 June 2007 08:47:56 Nicolas Mailhot wrote:
I wouldn't ask for one if I knew exactly what each comps tag is supposed to mean. notting stealthily dumped a comps dtd in our cvs so I suppose it's "official" and could be bundled with rpm/yum (or whatever package is supposed to own the comps format). It's not as nice as a modern annotated xml/relax-ng schema but it's a beginning.
We could drop it in as a %doc or example somewhere.
I'd rather it was registered properly in the system xml catalogs so xml tools (vim/emacs/libxml...) just know the comps structure.
Again, I'm XML ignorant so all these words... mean not much to me.
Le Ven 29 juin 2007 15:18, Jesse Keating a écrit :
On Friday 29 June 2007 08:47:56 Nicolas Mailhot wrote:
I wouldn't ask for one if I knew exactly what each comps tag is supposed to mean. notting stealthily dumped a comps dtd in our cvs so I suppose it's "official" and could be bundled with rpm/yum (or whatever package is supposed to own the comps format). It's not as nice as a modern annotated xml/relax-ng schema but it's a beginning.
We could drop it in as a %doc or example somewhere.
I'd rather it was registered properly in the system xml catalogs so xml tools (vim/emacs/libxml...) just know the comps structure.
Again, I'm XML ignorant so all these words... mean not much to me.
Just means you decide one package is the owner of the comps format, and have it drop a format definition in /usr/share/xml (in DTD/XML-schema/relax-ng format, probably DTD since notting put a dtd in cvs), and you use the xml tools to register this format definition file in /etc/xml/catalog.xml (like the docbook schema package does)
And then suddenly all the well-behaved XML distro tools know how a comps file is supposed to be structured and can flag errors.
(though you'd probably need one schema for comps.xml and another for comps.xml.in since they do not use the same tag names)
On Thu, Jun 28, 2007 at 01:52:56PM -0400, Jesse Keating wrote:
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.
+1 from the mock co-maintainer.
-- Michael
On Thursday 28 June 2007 13:52:56 Jesse Keating wrote:
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.
To date:
comps change made. 'yum groupinfo buildsys-build' on rawhide for details. buildroot check scripts now included in upstream rpm, also in rawhide. mock changes created in http://people.redhat.com/jkeating/git/mock-nogrouprepo.git , RFE filed. redhat-rpm-config changes created in http://people.redhat.com/jkeating/git/redhat-rpm-config.git , upstream maintainer notified.
Once the redhat-rpm-config and mock changes go through, we'll be done with this little change.
On Thursday 05 July 2007, Jesse Keating wrote:
redhat-rpm-config changes created in http://people.redhat.com/jkeating/git/redhat-rpm-config.git , upstream maintainer notified.
I see only /usr/lib/rpm/check-buildroot is enabled in %__arch_install_post. I'm fine with not enabling /usr/lib/rpm/check-rpaths in redhat-rpm-config, that's how it is in current Fedora build roots too AFAIU.
On the other hand, I wouldn't personally mind enabling check-rpaths too - but it will generate many build failures that didn't occur before, most of which will be /usr/lib64 rpaths on x86_64 which are a relatively minor concern (but should be fixed anyway). But the upside is that it could reveal some really harmful rpaths that are security issues (not only in Fedora proper, but also in 3rd party packages).
rpmdev-setuptree has traditionally written both the rpath check and the buildroot check in ~/.rpmmacros. If both aren't enabled in the new redhat-rpm-config, I'll probably leave it as is in rpmdevtools. OTOH if both are enabled in it, I could get rid of that stuff altogether.
On Thursday 05 July 2007 14:16:25 Ville Skyttä wrote:
I see only /usr/lib/rpm/check-buildroot is enabled in %__arch_install_post. I'm fine with not enabling /usr/lib/rpm/check-rpaths in redhat-rpm-config, that's how it is in current Fedora build roots too AFAIU.
Yeah, changing that will need more than just me making it happen, it'll need FESCo approval and all that stuff. Too late for this week, can discuss next week.
On Thu, Jul 05, 2007 at 12:57:39PM -0400, Jesse Keating wrote:
On Thursday 28 June 2007 13:52:56 Jesse Keating wrote:
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.
To date:
comps change made. 'yum groupinfo buildsys-build' on rawhide for details. buildroot check scripts now included in upstream rpm, also in rawhide. mock changes created in http://people.redhat.com/jkeating/git/mock-nogrouprepo.git , RFE filed. redhat-rpm-config changes created in http://people.redhat.com/jkeating/git/redhat-rpm-config.git , upstream maintainer notified.
Once the redhat-rpm-config and mock changes go through, we'll be done with this little change.
mock-0.7.3 built for rawhide with this one change. -- Michael