[EPEL-devel] Re: Proposal: gate all stable release updates on rmdepcheck

--===============4687415211072291378==
Content-Type: multipart/alternative; boundary="00000000000026030b0655f80bd5"

--00000000000026030b0655f80bd5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 6, 2026 at 2:05=E2=80=AFPM Adam Williamson <adamwill@fedoraproj=
ect.org>
wrote:

> Hi folks!
>
> I want to formally propose an idea that has been kicked around a bit
> informally lately: gating all stable release updates on the relatively
> new rmdepcheck reverse dependency static checker. This would include
> Fedora and EPEL updates.
>
> rmdepcheck: https://forge.fedoraproject.org/quality/rmdepcheck
>
> rmdepcheck fails if the update under test, when compared against the
> current buildroot repository, contains unsatisfiable dependencies, or
> causes new unsatisfiable dependencies to appear in other packages. So
> if your update makes some other package uninstallable...that's a fail.
>
> This check has been running on all updates for some time now. We've
> dealt with various sources of false failures and I'm fairly confident
> it's pretty reliable by now.
>
> Gating all updates for stable releases on it would mean you could no
> longer ship updates with detectable dependency issues, unless you waive
> the failure - which implies explicitly taking responsibility for
> shipping a broken package, or breaking another package.
>
> I don't want to gate Rawhide or Branched on rmdepcheck yet, because
> sometimes it's kinda realistically necessary to bump an soname without
> being able to fix every single dependency, or something. But I think
> (or rather, Carl George pointed out - thanks, Carl) it's more
> reasonable for stable releases. After all, the update policy
> specifically says:
>
> "Updates should be carefully considered with respect to their
> dependencies. An update that required (or provided) a new Python ABI,
> for example, would almost certainly not be allowed. ABI changes in
> general are very strongly discouraged, they force larger update sets on
> users and they make life difficult for third-party packagers."
>
> EPEL has similar stability expectations.
>
> Implementing this is technically trivial (it just requires adding a new
> rule to the greenwave policy), but it's obviously a pretty significant
> change, so I thought I'd propose it here and on Discourse for
> discussion first. I don't think it's a good fit for the Change process.
>
> You can browse existing rmdepcheck results in resultsdb, if you want to
> look for false failures. Go to
> https://resultsdb.fedoraproject.org/results , click the Search button,
> set the 'testcase' to 'fedora-ci.koji-build.rmdepcheck.functional' and
> hit Go! That'll give you the last month of results. You can tweak the
> date range, and also search only for failed results, if you like. It's
> slightly awkward because currently results are reported per package, so
> testing an update with 500 packages in it produces 500 results that
> link back to the same execution. I do want to change it to report per
> update rather than per package, but I don't think that needs to be done
> before we start gating.


While I'm not against this in Fedora, for EPEL I've had a fairly high false
negative rate.  About 25%.
What's really frustrating in it is when I have 100+ packages in an update
and they all get false negatives.

In short, please get this working consistently in EPEL, and I'll be very
happy to have it implemented.

Troy

--00000000000026030b0655f80bd5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 6, 2026 at 2:05=E2=80=AFPM Ad=
am Williamson &lt;<a href=3D"mailto:adamwill-rxtnV0ftBwyoClj4AeEUq9i2O/[email protected]">adamwill@fe=
doraproject.org</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_c=
ontainer"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi folks!<br>
<br>
I want to formally propose an idea that has been kicked around a bit<br>
informally lately: gating all stable release updates on the relatively<br>
new rmdepcheck reverse dependency static checker. This would include<br>
Fedora and EPEL updates.<br>
<br>
rmdepcheck: <a href=3D"https://forge.fedoraproject.org/quality/rmdepcheck" =
rel=3D"noreferrer" target=3D"_blank">https://forge.fedoraproject.org/qualit=
y/rmdepcheck</a><br>
<br>
rmdepcheck fails if the update under test, when compared against the<br>
current buildroot repository, contains unsatisfiable dependencies, or<br>
causes new unsatisfiable dependencies to appear in other packages. So<br>
if your update makes some other package uninstallable...that&#39;s a fail.<=
br>
<br>
This check has been running on all updates for some time now. We&#39;ve<br>
dealt with various sources of false failures and I&#39;m fairly confident<b=
r>
it&#39;s pretty reliable by now.<br>
<br>
Gating all updates for stable releases on it would mean you could no<br>
longer ship updates with detectable dependency issues, unless you waive<br>
the failure - which implies explicitly taking responsibility for<br>
shipping a broken package, or breaking another package.<br>
<br>
I don&#39;t want to gate Rawhide or Branched on rmdepcheck yet, because<br>
sometimes it&#39;s kinda realistically necessary to bump an soname without<=
br>
being able to fix every single dependency, or something. But I think<br>
(or rather, Carl George pointed out - thanks, Carl) it&#39;s more<br>
reasonable for stable releases. After all, the update policy<br>
specifically says:<br>
<br>
&quot;Updates should be carefully considered with respect to their<br>
dependencies. An update that required (or provided) a new Python ABI,<br>
for example, would almost certainly not be allowed. ABI changes in<br>
general are very strongly discouraged, they force larger update sets on<br>
users and they make life difficult for third-party packagers.&quot;<br>
<br>
EPEL has similar stability expectations.<br>
<br>
Implementing this is technically trivial (it just requires adding a new<br>
rule to the greenwave policy), but it&#39;s obviously a pretty significant<=
br>
change, so I thought I&#39;d propose it here and on Discourse for<br>
discussion first. I don&#39;t think it&#39;s a good fit for the Change proc=
ess.<br>
<br>
You can browse existing rmdepcheck results in resultsdb, if you want to<br>
look for false failures. Go to<br>
<a href=3D"https://resultsdb.fedoraproject.org/results" rel=3D"noreferrer" =
target=3D"_blank">https://resultsdb.fedoraproject.org/results</a> , click t=
he Search button,<br>
set the &#39;testcase&#39; to &#39;fedora-ci.koji-build.rmdepcheck.function=
al&#39; and<br>
hit Go! That&#39;ll give you the last month of results. You can tweak the<b=
r>
date range, and also search only for failed results, if you like. It&#39;s<=
br>
slightly awkward because currently results are reported per package, so<br>
testing an update with 500 packages in it produces 500 results that<br>
link back to the same execution. I do want to change it to report per<br>
update rather than per package, but I don&#39;t think that needs to be done=
<br>
before we start gating.</blockquote><div><br></div><div>While I&#39;m not a=
gainst this in Fedora, for EPEL I&#39;ve had a fairly high false negative r=
ate.=C2=A0 About 25%.</div><div>What&#39;s really frustrating in it is when=
 I have 100+ packages in an update and they all get false negatives.</div><=
div><br></div><div>In short, please get this working consistently in EPEL, =
and I&#39;ll be very happy to have it implemented.</div><div><br></div><div=
>Troy</div><div><br></div></div></div>

--00000000000026030b0655f80bd5--


--===============4687415211072291378==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

LS0gCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmVwZWwt
ZGV2ZWwgbWFpbGluZyBsaXN0IC0tIGVwZWwtZGV2ZWxAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcK
VG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBlcGVsLWRldmVsLWxlYXZlQGxpc3RzLmZl
ZG9yYXByb2plY3Qub3JnCkZlZG9yYSBDb2RlIG9mIENvbmR1Y3Q6IGh0dHBzOi8vZG9jcy5mZWRv
cmFwcm9qZWN0Lm9yZy9lbi1VUy9wcm9qZWN0L2NvZGUtb2YtY29uZHVjdC8KTGlzdCBHdWlkZWxp
bmVzOiBodHRwczovL2ZlZG9yYXByb2plY3Qub3JnL3dpa2kvTWFpbGluZ19saXN0X2d1aWRlbGlu
ZXMKTGlzdCBBcmNoaXZlczogaHR0cHM6Ly9saXN0cy5mZWRvcmFwcm9qZWN0Lm9yZy9hcmNoaXZl
cy9saXN0L2VwZWwtZGV2ZWxAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKRG8gbm90IHJlcGx5IHRv
IHNwYW0sIHJlcG9ydCBpdDogaHR0cHM6Ly9mb3JnZS5mZWRvcmFwcm9qZWN0Lm9yZy9pbmZyYS90
aWNrZXRzL2lzc3Vlcy9uZXcK

--===============4687415211072291378==--