Jamielinux (talk | contribs) (Add information about what buildroot overrides actually are and why you would need it) |
(update for how things work currently and include a lot of loud advertising for using side tags instead of overrides) |
||
| (21 intermediate revisions by 11 users not shown) | |||
| Line 1: | Line 1: | ||
= What is a | == What is a Buildroot Override == | ||
{{Admon/warning|Use on-demand side tags instead|Buildroot overrides should now be used only rarely. The normal method for creating multi-package updates, both for Rawhide and other branches, is to use on-demand side tags. See [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages the Package Update Guide] for more details.}} | |||
Sometimes a package you are trying to build can't be done until another package that it depends on is updated. [[Releases/Rawhide#Producing_Rawhide|When building packages for Rawhide]] and Branched before updates-testing activation, updates are automatically created for successful builds. As long as all gating tests pass, the update will be immediately pushed "stable" and shortly thereafter the package will be available in the Rawhide buildroot to build other packages against. However, if the update breaks the dependencies of downstream packages it may fail gating tests and be blocked from stable push, so when trying to update packages with dependency implications like this, you should [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages follow the instructions to use an on-demand side tag] to create a multi-package update. | |||
When building for Branched after updates-testing is activated or for any stable release, builds are usually only available to be built against once they are pushed to "stable". Often it isn't practical or convenient to wait for this to happen. | |||
The normal way to handle this now is to use an on-demand side tag, as explained in [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages the Package Update Guide]. You can create a side tag, do your initial build there, and it will immediately be included in the buildroot for that side tag, so you can build other packages against it in the same side tag. Once all related packages have been built, you can create an update from the side tag, which will contain all the packages. | |||
The older way to work around this problem was by submitting a buildroot override for any package builds you need that haven't yet made it to "stable". This will place the package into the buildroot for the branch that you specify until the expiry date that you specify. During this time, the package is available to be built against. A drawback of this method is that '''all''' builds run by anybody during the time the override is active will build against the overridden package, so it is strongly recommended to specify an expiry date that is only as long as you need (e.g. a few hours). It can easily be extended if needed. You can and should also manually expire the override before the expiry date, once you have completed all the builds you wish to run. | |||
To submit a buildroot override for a package, you need to be a member of the packager group. | |||
It usually takes about 15 to 30 minutes for a new buildroot override to take effect. | |||
= Using fedpkg to manage buildroot overrides = | |||
You can make and manage overrides via {{command|fedpkg override}}. Run {{command|fedpkg override --help}} for full information. | |||
= Using Bodhi to manage buildroot overrides = | |||
See [https://bodhi.fedoraproject.org/docs/user/buildroot_overrides.html bodhi's online docs] or {{command|man bodhi}} and look for the OVERRIDES section. | |||
https:// | |||
Latest revision as of 18:53, 29 February 2024
What is a Buildroot Override
Buildroot overrides should now be used only rarely. The normal method for creating multi-package updates, both for Rawhide and other branches, is to use on-demand side tags. See the Package Update Guide for more details.
Sometimes a package you are trying to build can't be done until another package that it depends on is updated. When building packages for Rawhide and Branched before updates-testing activation, updates are automatically created for successful builds. As long as all gating tests pass, the update will be immediately pushed "stable" and shortly thereafter the package will be available in the Rawhide buildroot to build other packages against. However, if the update breaks the dependencies of downstream packages it may fail gating tests and be blocked from stable push, so when trying to update packages with dependency implications like this, you should follow the instructions to use an on-demand side tag to create a multi-package update.
When building for Branched after updates-testing is activated or for any stable release, builds are usually only available to be built against once they are pushed to "stable". Often it isn't practical or convenient to wait for this to happen.
The normal way to handle this now is to use an on-demand side tag, as explained in the Package Update Guide. You can create a side tag, do your initial build there, and it will immediately be included in the buildroot for that side tag, so you can build other packages against it in the same side tag. Once all related packages have been built, you can create an update from the side tag, which will contain all the packages.
The older way to work around this problem was by submitting a buildroot override for any package builds you need that haven't yet made it to "stable". This will place the package into the buildroot for the branch that you specify until the expiry date that you specify. During this time, the package is available to be built against. A drawback of this method is that all builds run by anybody during the time the override is active will build against the overridden package, so it is strongly recommended to specify an expiry date that is only as long as you need (e.g. a few hours). It can easily be extended if needed. You can and should also manually expire the override before the expiry date, once you have completed all the builds you wish to run.
To submit a buildroot override for a package, you need to be a member of the packager group.
It usually takes about 15 to 30 minutes for a new buildroot override to take effect.
Using fedpkg to manage buildroot overrides
You can make and manage overrides via fedpkg override. Run fedpkg override --help for full information.
Using Bodhi to manage buildroot overrides
See bodhi's online docs or man bodhi and look for the OVERRIDES section.