You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ICU major version migrations are handled differently than other SONAME bumps. The icu package is bumped, and libicuNN compat package (where NN is the previous major version) is created, but no dependents are rebuilt; the latter is left to individual maintainers. The problem with that in respect to ELN is that there is no chance for EBS to trigger a build of libicuNN when icu is bumped, and the result is failed composes (with unresolved dependencies on the old SONAMEs). This has been a consistent issue in ELN, and just happened again today with the icu 74->76 migration; we should try to find a way to solve it.
Some ideas that have come to mind:
Add libicu76 (not a typo) to CR in advance. It would cause a warning due to it not existing until icu is bumped to 77+, but as soon as it does appear, it should then be rebuilt right away. Once that has happened, that would need to be updated to the then-new major version (77+) and so on (once it exists having been built once, then it need not be explicitly listed anymore, as it would be pulled in as a dependency until everything had been rebuilt).
Add a version-specific provides to CR instead, e.g. libicudata.so.76()(64bit), which now would be libicu (subpackage of icu) but would automatically trigger a libicu76 build when icu is next bumped. I'm not sure if CR would accept that though (it technically should, since it is installable by that name). Here again, it would need to be updated following a major version bump.
Add libicu* to CR; wildcards are handled as expected, but it would mean that the compat build would continue to be pulled in even after everything in ELN is rebuilt for the new version until the compat version is fully retired from rawhide.
Get the icu maintainer(s) to manually build (the first time) libicuNN for ELN in tandem with the rawhide build. This would rely on them remembering to do so though.
The text was updated successfully, but these errors were encountered:
What does the ELN SIG need to do?
ICU major version migrations are handled differently than other SONAME bumps. The
icu
package is bumped, andlibicuNN
compat package (whereNN
is the previous major version) is created, but no dependents are rebuilt; the latter is left to individual maintainers. The problem with that in respect to ELN is that there is no chance for EBS to trigger a build oflibicuNN
whenicu
is bumped, and the result is failed composes (with unresolved dependencies on the old SONAMEs). This has been a consistent issue in ELN, and just happened again today with the icu 74->76 migration; we should try to find a way to solve it.Some ideas that have come to mind:
libicu76
(not a typo) to CR in advance. It would cause a warning due to it not existing untilicu
is bumped to 77+, but as soon as it does appear, it should then be rebuilt right away. Once that has happened, that would need to be updated to the then-new major version (77+) and so on (once it exists having been built once, then it need not be explicitly listed anymore, as it would be pulled in as a dependency until everything had been rebuilt).libicudata.so.76()(64bit)
, which now would belibicu
(subpackage oficu
) but would automatically trigger alibicu76
build whenicu
is next bumped. I'm not sure if CR would accept that though (it technically should, since it is installable by that name). Here again, it would need to be updated following a major version bump.libicu*
to CR; wildcards are handled as expected, but it would mean that the compat build would continue to be pulled in even after everything in ELN is rebuilt for the new version until the compat version is fully retired from rawhide.libicuNN
for ELN in tandem with the rawhide build. This would rely on them remembering to do so though.The text was updated successfully, but these errors were encountered: