[EPEL-devel] Re: Proposed "incompatible" (not really) update in EPEL 10.1: rust-foldhash v0.1 to v0.2
This all seems fine, +1 here. kevin -- ___ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Proposed "incompatible" (not really) update in EPEL 10.1: rust-foldhash v0.1 to v0.2
On Sat, Nov 8, 2025 at 6:00 AM Fabio Valentini wrote: > > On Sat, Nov 8, 2025 at 7:03 AM Carl George wrote: > > > > It's true that there isn't a config for this included in > > mock-core-configs. My recommendation would be to instead run `fedpkg > > scratch-build` from the epel10.1 branch. > > Yes, I know that I can run scratch builds, but that doesn't help me to > check whether the built packages are *installable*. There's no perfect answer for this due to the nature of RHEL's development and the non-public RHEL minor version branches. More often than not I hope this has no impact, assuming a package was installable on CentOS 10 at the time of mass branching and that is hasn't changed enough for installability to be adversely affected. Hopefully rebase cases like this are the rare exception. In RHEL, after the minor version branches it gets progressively harder (i.e. more red tape) to make changes to that branch, but we don't have the equivalent on the EPEL side. I would encourage EPEL maintainers to follow that approach whenever possible. > > > While RHEL 10.1 hasn't been released yet, EPEL 10.1 has. Please don't > > treat EPEL minor versions newer than the current RHEL minor version as > > pre-release, because they are already being consumed by CentOS users. > > Are they though? (Or *can* they?) I thought CentOS Stream already > tracks EPEL 10.2 now. CentOS tracked EPEL 10.1 for about six months. It tracks EPEL 10.2 now, but ideally we should still treat EPEL 10.1 with at least as much discretion as we do EPEL 10.2. It doesn't make sense to me to temporarily allow more disruptive updates as a rule during the short gap period where neither CentOS or RHEL is directly consuming an EPEL minor version. My concern is if we start referring to the branched minor version as pre-release, the next logical step is referring to the leading minor version as pre-release. That would be a mistake since people are already relying on it and expecting at least major version stability. > > Fabio > -- > ___ > epel-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- ___ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Proposed "incompatible" (not really) update in EPEL 10.1: rust-foldhash v0.1 to v0.2
On Sat, Nov 8, 2025 at 4:33 AM Neal Gompa wrote: > > On Sat, Nov 8, 2025 at 1:03 AM Carl George wrote: > > > > On Thu, Nov 6, 2025 at 4:42 PM Fabio Valentini wrote: > > > > > > Hi all, > > > > > > TL;DR: I want to update rust-foldhash from v0.1.* to v0.2.* (and > > > adding rust-foldhash0.1 as a compat package that continues to ship > > > v0.1.*) in EPEL 10.1 to un-break an accidentally introduced broken > > > dependency and to un-block other bug fixes, so this update might have > > > been necessary for EPEL 10.1 eventually anyway. > > > This would be a transparent update for dependent packages since RPM > > > dependencies between Rust crates are never based on actual package > > > names but only on virtual Provides that are package name independent. > > > > Seems reasonable to me. > > > > > Full version: > > > > > > I would like to update the rust-foldhash package in EPEL 10.1 from > > > version 0.1 to 0.2. In the short-term this would fix a broken > > > dependency that I accidentally introduced in a different package > > > (rust-toml, which bumped its dependency on rust-foldhash from v0.1 to > > > v0.2), and which in turn, now breaks build dependencies of uv (see > > > https://koschei.fedoraproject.org/package/uv?collection=epel10.1 ). > > > > > > I'm sorry for the breakage caused here, I'm usually better at catching > > > this issue before it's too late. I can only say "there is currently no > > > way to 'mock --postinstall' locally for epel10.1, which would have > > > caught this issue" in my defense. :) > > > > It's true that there isn't a config for this included in > > mock-core-configs. My recommendation would be to instead run `fedpkg > > scratch-build` from the epel10.1 branch. > > > > > The update for rust-foldhash v0.2 was previously handled for EPEL 10.2 > > > here: > > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-31bb34b75d > > > With this update we also introduced a "compat" package for v0.1, so > > > existing dependent packages that pin v0.1 were transparently switched > > > to the "compat" package. > > > > > > So, this would only be an "incompatible" update in the most strictest > > > reading of the EPEL Updates Policy - but it would be a transparent > > > update for all dependent packages that follow the Rust Packaging > > > guidelines (all of them do). > > > > > > Also note that the foldhash v0.2 update is one "prevented by policy" > > > update in EPEL 10.1 that is already blocking other non-breaking > > > package updates (because many projects have already bumped their > > > dependency to v0.2, most often even in *.*.z / bugfix releases) and > > > EPEL 10.1 is not even released yet. > > > > While RHEL 10.1 hasn't been released yet, EPEL 10.1 has. Please don't > > treat EPEL minor versions newer than the current RHEL minor version as > > pre-release, because they are already being consumed by CentOS users. > > > > While this is true, EPEL 10.1 can't really be consumed by any > significant people because it's not used by CentOS or RHEL users. Keep in mind that even though RHEL 10.1 isn't publicly released yet, it does exist and people are already using with EPEL enabled inside Red Hat. Like RHEL itself, they're not expecting EPEL to change significantly in between the branching point and the RHEL GA release. > There's no more RHEL betas, so that's not even an option. So I think > it's fine. And we do want the EPEL minor matching CentOS Stream to be > used for rebases as needed because that's where Red Hat also does > rebases. While the EPEL Steering Committee has discussed a general desire to adjust EPEL policy to be more permissive with package rebases in the epel10 branch, I want to clear to maintainers reading this list that this policy change *has not happened yet*, and incompatible change do still require case by case approval like Fabio is doing here. > > I think this proposed update is fine to me. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > -- > ___ > epel-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- ___ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply
[EPEL-devel] Re: Proposed "incompatible" (not really) update in EPEL 10.1: rust-foldhash v0.1 to v0.2
On Sat, Nov 8, 2025 at 7:03 AM Carl George wrote: > > It's true that there isn't a config for this included in > mock-core-configs. My recommendation would be to instead run `fedpkg > scratch-build` from the epel10.1 branch. Yes, I know that I can run scratch builds, but that doesn't help me to check whether the built packages are *installable*. > While RHEL 10.1 hasn't been released yet, EPEL 10.1 has. Please don't > treat EPEL minor versions newer than the current RHEL minor version as > pre-release, because they are already being consumed by CentOS users. Are they though? (Or *can* they?) I thought CentOS Stream already tracks EPEL 10.2 now. Fabio -- ___ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Proposed "incompatible" (not really) update in EPEL 10.1: rust-foldhash v0.1 to v0.2
On Sat, Nov 8, 2025 at 1:03 AM Carl George wrote: > > On Thu, Nov 6, 2025 at 4:42 PM Fabio Valentini wrote: > > > > Hi all, > > > > TL;DR: I want to update rust-foldhash from v0.1.* to v0.2.* (and > > adding rust-foldhash0.1 as a compat package that continues to ship > > v0.1.*) in EPEL 10.1 to un-break an accidentally introduced broken > > dependency and to un-block other bug fixes, so this update might have > > been necessary for EPEL 10.1 eventually anyway. > > This would be a transparent update for dependent packages since RPM > > dependencies between Rust crates are never based on actual package > > names but only on virtual Provides that are package name independent. > > Seems reasonable to me. > > > Full version: > > > > I would like to update the rust-foldhash package in EPEL 10.1 from > > version 0.1 to 0.2. In the short-term this would fix a broken > > dependency that I accidentally introduced in a different package > > (rust-toml, which bumped its dependency on rust-foldhash from v0.1 to > > v0.2), and which in turn, now breaks build dependencies of uv (see > > https://koschei.fedoraproject.org/package/uv?collection=epel10.1 ). > > > > I'm sorry for the breakage caused here, I'm usually better at catching > > this issue before it's too late. I can only say "there is currently no > > way to 'mock --postinstall' locally for epel10.1, which would have > > caught this issue" in my defense. :) > > It's true that there isn't a config for this included in > mock-core-configs. My recommendation would be to instead run `fedpkg > scratch-build` from the epel10.1 branch. > > > The update for rust-foldhash v0.2 was previously handled for EPEL 10.2 here: > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-31bb34b75d > > With this update we also introduced a "compat" package for v0.1, so > > existing dependent packages that pin v0.1 were transparently switched > > to the "compat" package. > > > > So, this would only be an "incompatible" update in the most strictest > > reading of the EPEL Updates Policy - but it would be a transparent > > update for all dependent packages that follow the Rust Packaging > > guidelines (all of them do). > > > > Also note that the foldhash v0.2 update is one "prevented by policy" > > update in EPEL 10.1 that is already blocking other non-breaking > > package updates (because many projects have already bumped their > > dependency to v0.2, most often even in *.*.z / bugfix releases) and > > EPEL 10.1 is not even released yet. > > While RHEL 10.1 hasn't been released yet, EPEL 10.1 has. Please don't > treat EPEL minor versions newer than the current RHEL minor version as > pre-release, because they are already being consumed by CentOS users. > While this is true, EPEL 10.1 can't really be consumed by any significant people because it's not used by CentOS or RHEL users. There's no more RHEL betas, so that's not even an option. So I think it's fine. And we do want the EPEL minor matching CentOS Stream to be used for rebases as needed because that's where Red Hat also does rebases. I think this proposed update is fine to me. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Proposed "incompatible" (not really) update in EPEL 10.1: rust-foldhash v0.1 to v0.2
On Thu, Nov 6, 2025 at 4:42 PM Fabio Valentini wrote: > > Hi all, > > TL;DR: I want to update rust-foldhash from v0.1.* to v0.2.* (and > adding rust-foldhash0.1 as a compat package that continues to ship > v0.1.*) in EPEL 10.1 to un-break an accidentally introduced broken > dependency and to un-block other bug fixes, so this update might have > been necessary for EPEL 10.1 eventually anyway. > This would be a transparent update for dependent packages since RPM > dependencies between Rust crates are never based on actual package > names but only on virtual Provides that are package name independent. Seems reasonable to me. > Full version: > > I would like to update the rust-foldhash package in EPEL 10.1 from > version 0.1 to 0.2. In the short-term this would fix a broken > dependency that I accidentally introduced in a different package > (rust-toml, which bumped its dependency on rust-foldhash from v0.1 to > v0.2), and which in turn, now breaks build dependencies of uv (see > https://koschei.fedoraproject.org/package/uv?collection=epel10.1 ). > > I'm sorry for the breakage caused here, I'm usually better at catching > this issue before it's too late. I can only say "there is currently no > way to 'mock --postinstall' locally for epel10.1, which would have > caught this issue" in my defense. :) It's true that there isn't a config for this included in mock-core-configs. My recommendation would be to instead run `fedpkg scratch-build` from the epel10.1 branch. > The update for rust-foldhash v0.2 was previously handled for EPEL 10.2 here: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-31bb34b75d > With this update we also introduced a "compat" package for v0.1, so > existing dependent packages that pin v0.1 were transparently switched > to the "compat" package. > > So, this would only be an "incompatible" update in the most strictest > reading of the EPEL Updates Policy - but it would be a transparent > update for all dependent packages that follow the Rust Packaging > guidelines (all of them do). > > Also note that the foldhash v0.2 update is one "prevented by policy" > update in EPEL 10.1 that is already blocking other non-breaking > package updates (because many projects have already bumped their > dependency to v0.2, most often even in *.*.z / bugfix releases) and > EPEL 10.1 is not even released yet. While RHEL 10.1 hasn't been released yet, EPEL 10.1 has. Please don't treat EPEL minor versions newer than the current RHEL minor version as pre-release, because they are already being consumed by CentOS users. > I suspect that we might have needed to initiate this process for this > update eventually anyway just to unblock other bug fixes in packages > that depend on foldhash - which is why I think this is a reasonable > "incompatible, but ... not actually" abstract epel update policy > exception request proposal factory singleton. > > Fabio > -- > ___ > epel-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- ___ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
