On Mon, Dec 2, 2019 at 7:04 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> 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.
>
We should probably consider rebuilding all the Python 3 packages in
EPEL7 no matter what so that the python3.6dist() Provides get
generated, though. The dependency generator was backported to EL7 and
is used with the Python 3 stack. It just isn't very useful yet because
not all the packages were rebuilt after python3 was introduced in RHEL
7. Though why the --majorver-provides switch was removed from the
attr, I don't know.
After that, we can backport the %python_enable_dependency_generator
macro to EPEL7...
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
