[EPEL-devel] Re: "python3" vs "python%{python3_pkgversion}"

On 02. 12. 19 23:09, Ken Dreyer wrote: > On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: > > > > On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer <ktdreyer(a)ktdreyer.com&gt; wrote: > > > > > > Hi folks, > > > > > > In EPEL 7 we have some packages with "python34" and "python36" > > > prefixes in their names. I guess this is a consequence of using the > > > %{python3_pkgversion} macro over time. > > > > > > Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in > > > EPEL 7, I'm wondering about this. > > > > > > If I'm introducing a Python 3 subpackage in a new build today, should > > > I name this sub-package "python3-foo" or > > > "python%{python3_pkgversion}-foo" ? > > > > > > > The subpackage should be "python%{python3_pkgversion}-foo" and you > > should also make sure you have "%{?python_provide:%python_provide > > python%{python3_pkgversion}-foo}" in the subpackage declaration too. > > This is confusing to me, and it diverges from what Fedora does. Can we > just reduce this down to "python3-" now that RHEL 7 has python3, and > we'll probably never put another Python version into EPEL 7? We **can** but we **haven't yet**. IMHO doing it in random packages is wrong. Currently, python36-foo is form EPEL (and if done right, provides python3-foo). OTOH python3-bar is from RHEL (and if done right, provides python36-bar). They both provide both names, but from first glance, the origin of the package is obvious. I kinda like that. If we decide to redo this, it will be a lot of boring work for no clear benefit. If we decide to only allow it for new packages, it would be a mess. That said, technically: - it works either way - there is no real EPEL packaging guideline forcing one way or the other