On Mon, Dec 2, 2019 at 7:04 PM Miro Hrončok <mhroncok(a)redhat.com> 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(a)gmail.com>
wrote:
>>>>
>>>> On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer <ktdreyer(a)ktdreyer.com>
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!