On Thu, Jul 22, 2021 at 7:21 AM Neal Gompa <ngomp...@gmail.com> wrote: > > On Thu, Jul 22, 2021 at 1:56 AM Nico Kadel-Garcia <nka...@gmail.com> wrote: > > > > On Mon, Jul 19, 2021 at 7:04 AM Fabio Valentini <decatho...@gmail.com> > > wrote: > > > > > > On Mon, Jul 19, 2021 at 12:06 PM Jiri Vanek <jva...@redhat.com> wrote: > > > > > > > > On 7/17/21 11:15 PM, Ron Olson wrote: > > > > > Hey all- > > > > > > > > > > I’m curious as to why submitting a new build to Bodhi takes a week to > > > > > be pushed to stable, but two weeks for EPEL-8. Is the presumption > > > > > that it’s just that much more time for folks to test and verify? > > > > > > > > lack of reviewers, so longer in buildroot is kinda test... > > > > > > Surely not? The user base of EPEL is, by some measures, considerably > > > bigger than the user base of Fedora. > > > Those users might not participate in testing as much, because they > > > rely on the stability of their systems more, but this is certainly not > > > a *lack of reviewers*. > > > > There are odd trade-offs. Many EPEL users do so as a matter of course, > > treating EPEL as an adjunct to RHEL, and would find RHEL or CentOS > > quite useless without EPEL. The availability of python36 for RHEL 7, > > for example, was an excellent step towards python3 for RHEL 7 and > > CentOS 7 users, and I'd have had to consider migrating from RHEL > > without the stable python36 tools from EPEL, which avoided having to > > build up a python suite myself. I do wish our colleagues at RHEL, or > > that Fedora itself, had kept the "python34", "python36", etc. > > numbering from EPEL. It would have eased demands I'm seeing for > > people to build and ihstalll and manage python in their home > > directories with "linuxbrew", which does not work, or "pyenv", which > > is vulnerable to dependency skew adventures. > > > > I consider it a crying shame that the numbered versions, like python36 > > and python38, were abandoned. Unfortunately, it can't always be that > > stable because it's driven by things people want and are willing to do > > the work to put in. Don't get me started on the chromium and ansible > > regressions I've encountered in the last few years. tools like those > > which are used as part of automated testing suites are very vulnerable > > to quite small changes in their features or API's leading to quite > > adventuresome breakdowns. > > What are you talking about? The Python interpreter *is* versioned in > Fedora now. We use python3.Y for the package name of the interpreter, > and only the *default* interpreter package produces the python3 > package. It *started* in Fedora and made its way to RHEL.
Sadly, the "python3dist" options used by Fedora .spec files are not working in RHEL 7, or at least not working for me, and it creates a lot of extra work dealing with "python3_pkgversion" for backporting software to RHEL 7. It creates issues in EPEL for RHEL 7, where "python36" packages had to be renamed as "python3" to be consistent with Red Hat's practices, even though EPEL had it first. it fosters very serious issues for forks like Amazon Linux 2 where "python3" is python 3.7 and the "python3" from RHEL and EPEL are python 3.6. I agree that naming the packages in Fedora with "python3.6", "python3.8", "python3.10" or other consistent names is good. I'm suggesting that making an exception for the "default python 3" was a bad idea. I really wish that the "python3-" names did not exist, and we'd stuck with naming all the packages based on the more specific python release. See the above issues with Amazon Linux 2 and "python3" EPEL packages to understand my current pain. It was especially an adventure for me recently helping with a port of recent Samba releases to Amazon Linux 2, and it's not helping the backports to RHEL 7. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
