Re: "python3" vs "python%{python3_pkgversion}"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03. 12. 19 0:54, Kevin Fenzi wrote:
On Tue, Dec 03, 2019 at 12:38:01AM +0100, Miro Hrončok wrote:
On 02. 12. 19 23:09, Ken Dreyer wrote:
On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:

On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer <ktdreyer@xxxxxxxxxxxx> 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

I think we should encourage people to just use python3-foo now, but I
agree it would be a lot of work to try and convert everything to do
that.

The orig reason was so we could move python stacks forward since we were
maintaining them in epel. Since python 3.6 is in rhel and rhel7 is past
the point where I would expect many changes, I think 3.6 is here to
stay, so we dont really need it anymore. It's just extra noise that
makes spec files less readable now.

If we want to get rid of it, we might just:

Fix the cases where srpm is called python3-foo and subpackage python36-foo.
Switch the %{python3_pkgversion} to 3 (= remove the redefinition from EPEL).

Rebuild everything. Profit.

The problem of course, is bootstrapping.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux