From Fedora Project Wiki
(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 BuildRoot Override =
== What is a Buildroot Override ==


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, successful builds become available fairly soon after they complete. These packages can then be used to build other packages against.
{{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.}}


However, when building for any of the release branches below rawhide, builds are usually only available once they are pushed to "stable". You can work around this problem by submitting a BuildRoot Override for this particular build. This will place it into the BuildRoot for the branch that you specify, until the date that you specify. During this time, the package is available to be built against.
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.


= Using Bodhi to manage Koji Buildroot Overrides =
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.


This document describes how to manage your Koji BuildRoot Overrides using
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.
Bodhi. Each section contains URLs for performing actions via the web and
commands for doing it from the console.


{{admon/tip|Legacy method|Legacy method/backup plan: submit releng ticket: https://fedorahosted.org/rel-eng/newticket}}
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.


== Submitting a new override ==
To submit a buildroot override for a package, you need to be a member of the packager group.


https://admin.fedoraproject.org/updates/override/new
It usually takes about 15 to 30 minutes for a new buildroot override to take effect.


<pre>
= Using fedpkg to manage buildroot overrides =
    bodhi --buildroot-override=<name-version-release> --duration=5 --notes="Useful details."
</pre>


== Viewing your own overrides ==
You can make and manage overrides via {{command|fedpkg override}}. Run {{command|fedpkg override --help}} for full information.


https://admin.fedoraproject.org/updates/override/list?mine=True
= Using Bodhi to manage buildroot overrides =


<pre>
See [https://bodhi.fedoraproject.org/docs/user/buildroot_overrides.html bodhi's online docs] or {{command|man bodhi}} and look for the OVERRIDES section.
    bodhi --my-overrides [--show-expired]
</pre>
 
== Viewing all overrides ==
 
https://admin.fedoraproject.org/updates/override/list
 
<pre>
    bodhi --list-overrides [--show-expired]
</pre>
 
== Manually expiring your buildroot override ==
 
https://admin.fedoraproject.org/updates/override/expire/<name-version-release>
 
<pre>
    bodhi --expire-override=<name-version-release>
</pre>
 
== Extending your duration or editing override notes ==
 
https://admin.fedoraproject.org/updates/override/edit/<name-version-release>
 
<pre>
    bodhi --edit-override=<name-version-release> --duration=10 --notes="Oh hai"
</pre>

Latest revision as of 18:53, 29 February 2024

What is a Buildroot Override

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