#3088 Updates policy exception request for Macaulay2 stack in Fedora 39
Closed: Accepted a year ago by tstellar. Opened a year ago by music.

@jjames and I just updated Macaulay2 to 1.22 in Rawhide/F40. We would like to do the same update in Fedora 39 because this is the only way to fix the current FTBFS in that release so that the package can be maintained over the lifecycle of Fedora 39.

According to the release notes, there are some small incompatible changes in version 1.22 (search for “functionality changed in a way that could break code”).

Additionally, although upstream did not bump the SONAME versions, fedabipkgdiff reports some ABI changes that could be potentially breaking in givaro and in linbox. I did not analyze memtailor, mathic, and mathicgb for ABI compatibility because they are explicitly and exclusively Macaulay2 support packages.

Any ABI changes are mitigated by the fact that nothing other than Macaulay2 depends on any of these packages in F39 and later, so everything is contained to the Macaulay2 stack: anything that could be affected by ABI changes is rebuilt in the update anyway.


(Please try to get a freeze exception, so it won't change on our users as a zero-day upgrade. The release is delayed again, so you probably have time.)

(Please try to get a freeze exception, so it won't change on our users as a zero-day upgrade. The release is delayed again, so you probably have time.)

Just in case it helps, I nominated this issue for fast-track.

Metadata Update from @music:
- Issue tagged with: fast track

a year ago

+1

(Please try to get a freeze exception, so it won't change on our users as a zero-day upgrade. The release is delayed again, so you probably have time.)

Is this on any of the installation media? If not, there's really no advantage to a Freeze Exception.

I realized that the new ticket voting policy no longer says that the submitter can request the fast-track policy; it now only says that “any FESCo member” may do that. Looking at the discussion in https://pagure.io/fesco/issue/3038, perhaps that was not intentional?

Removing the fast track tag based on the current voting policy, but any current FESCo member may feel free to restore it.

Metadata Update from @music:
- Issue untagged with: fast track

a year ago

Is this on any of the installation media? If not, there's really no advantage to a Freeze Exception.

The advantage is that there will not be an older version of this forever available for dnf to consider for resolving dependencies.

Removing the fast track tag based on the current voting policy, but any current FESCo member may feel free to restore it.

Added.

Metadata Update from @churchyard:
- Issue tagged with: fast track

a year ago

(Please try to get a freeze exception, so it won't change on our users as a zero-day upgrade. The release is delayed again, so you probably have time.)

Is this on any of the installation media? If not, there's really no advantage to a Freeze Exception.

The advantage is that there will not be an older version of this forever available for dnf to consider for resolving dependencies.

I know that FTI bugs are automatic freeze exceptions, but I feel like I have seen cases like this (“simple FTBFS” bugs not affecting installation media) generally rejected for freeze exceptions. Am I misremembering that? It’s hard to search for rejected freeze exceptions.

FESCo can always make it a FESCo blocker if needed.

+1

This is now approved via the Fast Track:
APPROVED (+7, 0, 0)

Metadata Update from @zbyszek:
- Issue tagged with: pending announcement

a year ago

Thank you!

The Freeze Exception was accepted procedurally, but @adamwill commented that “unfortunately we aren't going to have time to include this.” This will therefore be a zero-day update, which I have started preparing in f39-build-side-76748.

Metadata Update from @tstellar:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

a year ago

Log in to comment on this ticket.

Metadata