This bumps the soname from libfuse3.so.3 to libfuse3.so.4, so it needs rebuilds of all dependent packages. This is the list of source packages I worked out that need rebuilding:
To do this, you will need to set up a side tag, do a new build of fuse3 in it, do a koji wait-repo --request to make it show up in the side tag repo, then rebuild all dependent packages in the side tag (or get a maintainer to do it, if you don't have the privileges to do it yourself). See https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages .
Thanks for your feedback. Just to confirm — am I understanding it correctly that for each of the 25 dependent packages, I need to:
Bump the release
Open a pull request
Ask the maintainer to merge the PR
Ask the maintainer to build it using the side tag
If that's the case, would you agree that, for the sake of efficiency, this would be better handled by someone who is a member of the provenpackager group — someone who can manage all of this independently, without being blocked by each individual maintainer?
More or less, yes. I think once the PR is merged you may be able to build it in the side tag, but not 100% sure. If you are going to be handling fuse3 long term, you might want to ask the maintainers of each dependent package if they can add you as a co-maintainer for the purpose of doing these kinds of dependency rebuilds.
Yeah, a provenpackager can do a whole soname bump/rebuild without asking anyone, but we're not really supposed to, at least per my reading of https://docs.fedoraproject.org/en-US/fesco/Who_is_allowed_to_modify_which_packages/ . That seems to indicate that things should go through the package maintainers at least initially. A proven packager could merge/build packages where the maintainer doesn't respond to a PR.
"For updates to Rawhide packages, maintainers MUST: ... When a proposed update contains an ABI or API change: notify a week in advance both the devel list and maintainers directly (using the packagename-maintainers@fedoraproject.org alias) whose packages depend on yours to rebuild or offer to do these rebuilds for them."
For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora CI team.
For help debugging failed Fedora CoreOS tests (coreos.*), contact the Fedora CoreOS team.
For help debugging failed openQA tests (update.*), contact the Fedora Quality team, who will usually investigate and diagnose all failures within 24 hours.
This update was automatically created
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This bumps the soname from
libfuse3.so.3tolibfuse3.so.4, so it needs rebuilds of all dependent packages. This is the list of source packages I worked out that need rebuilding:To do this, you will need to set up a side tag, do a new build of fuse3 in it, do a
koji wait-repo --requestto make it show up in the side tag repo, then rebuild all dependent packages in the side tag (or get a maintainer to do it, if you don't have the privileges to do it yourself). See https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages .Hello Adam,
Thanks for your feedback. Just to confirm — am I understanding it correctly that for each of the 25 dependent packages, I need to:
Bump the release
Open a pull request
Ask the maintainer to merge the PR
Ask the maintainer to build it using the side tag
If that's the case, would you agree that, for the sake of efficiency, this would be better handled by someone who is a member of the provenpackager group — someone who can manage all of this independently, without being blocked by each individual maintainer?
More or less, yes. I think once the PR is merged you may be able to build it in the side tag, but not 100% sure. If you are going to be handling fuse3 long term, you might want to ask the maintainers of each dependent package if they can add you as a co-maintainer for the purpose of doing these kinds of dependency rebuilds.
Yeah, a provenpackager can do a whole soname bump/rebuild without asking anyone, but we're not really supposed to, at least per my reading of https://docs.fedoraproject.org/en-US/fesco/Who_is_allowed_to_modify_which_packages/ . That seems to indicate that things should go through the package maintainers at least initially. A proven packager could merge/build packages where the maintainer doesn't respond to a PR.
Oh, there is also a requirement in the update policy which applies here: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide
"For updates to Rawhide packages, maintainers MUST: ... When a proposed update contains an ABI or API change: notify a week in advance both the devel list and maintainers directly (using the packagename-maintainers@fedoraproject.org alias) whose packages depend on yours to rebuild or offer to do these rebuilds for them."
Thank you Adam for the information, I'll try to reach Peter (the owner of this package) and decide on next steps. Thanks!
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update has been obsoleted by fuse3-3.17.1-2.fc43.