python3-augeas and python3-ansible-runner file conflict?

[Matthew Miller]

Got a report on Ask Fedora(*) about an upgrade conflict, and, yep, these two have a problem:

file /usr/lib/python3.10/site-packages/test/__pycache__/__init__.cpython-310.opt-1.pyc from install of python3-ansible-runner-2.0.0a1-3.fc35.noarch conflicts with file from package python3-augeas-1.1.0-2.fc35.noarch
    file /usr/lib/python3.10/site-packages/test/__pycache__/__init__.cpython-310.pyc from install of python3-ansible-runner-2.0.0a1-3.fc35.noarch conflicts with file from package python3-augeas-1.1.0-2.fc35.noarch

... but, also, the particular thing being installed under "test" and particularly "test/__pycache" seems dodgy to me. Are these things even supposed to be in either package?

* https://ask.fedoraproject.org/t/dnf-upgrade-to-f35-transaction-error/18570

[Miro Hrončok]

On 23. 11. 21 18:53, Matthew Miller wrote:
> Got a report on Ask Fedora(*) about an upgrade conflict, and, yep, these two have a problem:
>  file /usr/lib/python3.10/site-packages/test/__pycache__/__init__.cpython-310.opt-1.pyc from install of python3-ansible-runner-2.0.0a1-3.fc35.noarch conflicts with file from package python3-augeas-1.1.0-2.fc35.noarch
>  file /usr/lib/python3.10/site-packages/test/__pycache__/__init__.cpython-310.pyc from install of python3-ansible-runner-2.0.0a1-3.fc35.noarch conflicts with file from package python3-augeas-1.1.0-2.fc35.noarch
>
> ... but, also, the particular thing being installed under "test" and particularly "test/__pycache" seems dodgy to me. Are these things even supposed to be in either package?
> https://ask.fedoraproject.org/t/dnf-upgrade-to-f35-transaction-error/18570

The files are not supposed to be in the package. It could lead to conflicts, as 
you can see.

There are the following 2 bugzillas:

python-ansible-runner: https://bugzilla.redhat.com/2008718
python-augeas: https://bugzilla.redhat.com/2008764

Both are marked as high severity and both seem equally ignored by the package 
maintainers.

There is also:

flatpak-module-tools: https://bugzilla.redhat.com/2008808
python-ipmi: https://bugzilla.redhat.com/2008810
python-netssh2: https://bugzilla.redhat.com/2008811
python-simpleparse: https://bugzilla.redhat.com/2008807

I should step in as a provenpacakger it seems.

[Miro Hrončok]

On 23. 11. 21 19:13, Miro Hrončok wrote:
> On 23. 11. 21 18:53, Matthew Miller wrote:
> > Got a report on Ask Fedora(*) about an upgrade conflict, and, yep, these two 
> > have a problem:
> >
> > file 
> > /usr/lib/python3.10/site-packages/test/__pycache__/__init__.cpython-310.opt-1.pyc 
> > from install of python3-ansible-runner-2.0.0a1-3.fc35.noarch conflicts with 
> > file from package python3-augeas-1.1.0-2.fc35.noarch
> >      file 
> > /usr/lib/python3.10/site-packages/test/__pycache__/__init__.cpython-310.pyc 
> > from install of python3-ansible-runner-2.0.0a1-3.fc35.noarch conflicts with 
> > file from package python3-augeas-1.1.0-2.fc35.noarch
> >
> > ... but, also, the particular thing being installed under "test" and 
> > particularly "test/__pycache" seems dodgy to me. Are these things even 
> > supposed to be in either package?
> > https://ask.fedoraproject.org/t/dnf-upgrade-to-f35-transaction-error/18570
>
> The files are not supposed to be in the package. It could lead to conflicts, as 
> you can see.
>
> There are the following 2 bugzillas:
>
> python-ansible-runner: https://bugzilla.redhat.com/2008718
> python-augeas: https://bugzilla.redhat.com/2008764
>
> Both are marked as high severity and both seem equally ignored by the package 
> maintainers.
>
> There is also:
>
> flatpak-module-tools: https://bugzilla.redhat.com/2008808
> python-ipmi: https://bugzilla.redhat.com/2008810
> python-netssh2: https://bugzilla.redhat.com/2008811
> python-simpleparse: https://bugzilla.redhat.com/2008807
>
> I should step in as a provenpacakger it seems.

Here is one update that should fix the failures the users see:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-fbb19120f8

The rest of the bugzillas need to be solved as well.

[Matthew Miller]

On Tue, Nov 23, 2021 at 07:13:19PM +0100, Miro Hrončok wrote:
> The files are not supposed to be in the package. It could lead to
> conflicts, as you can see.

Thanks. Is this is a common test artifact which could "leak" in other
pacages, and there maybe a standard CI check (or gate?) we could put in
place? Or is it just a coincidence that both packages made a similarly-named
mistake?
> I should step in as a provenpacakger it seems.

Thank you!

[Miro Hrončok]

On 23. 11. 21 20:26, Matthew Miller wrote:
> On Tue, Nov 23, 2021 at 07:13:19PM +0100, Miro Hrončok wrote:
> > The files are not supposed to be in the package. It could lead to
> > conflicts, as you can see.
>
> Thanks. Is this is a common test artifact which could "leak" in other
> pacages, and there maybe a standard CI check (or gate?) we could put in
> place? Or is it just a coincidence that both packages made a similarly-named
> mistake?

It is a mistake that I'Ve seen again and again over the years. Upstream Python 
packaging is somewhat immune to this problem (pip will happily override files 
like this), so it usually only turns into a problem when packaged as RPM.

Yes, it is possible to check this automatically. For instance, I believe 
rpmlint >= 2 does it.