Bug 1333169

The tracer RPM requires both Python 2 and Python 3.

Except in very special circumstances, there is no need for one package
to drag in both Python stacks. Usually, this is a packaging error: for
example, a stray "/usr/bin/python" shebang in a Python 3 package can
introduce a Python 2 dependency.

Please split your package, or remove the stray dependencies.
There is a section on shebangs in the Python RPM Porting Guide [0]
which covers this issue.

It's ok to do this in Rawhide only, however, it would be greatly
appreciated if you could push it to Fedora 24 as well.


If anything is unclear, or if you need any kind of assistance, you can
ask on IRC (#fedora-python on Freenode), or reply here. We'll be happy
to help investigating or fixing this issue!


[0] http://python-rpm-porting.readthedocs.io/en/latest/application-modules.html#are-shebangs-dragging-you-down-to-python-2

Created attachment 1180035 [details]
Use %{python_sitelib}

Will this changes in tracer.spec be good enough?

Hi Jakub!

I believe that is not sufficient. The main problem is that your package should be split into 2 subpackages: one for Python 2 and one for Python 3.

There is a guide on how to do this, step by step, I highly recommend it:

http://python-rpm-porting.readthedocs.io

Created attachment 1182669 [details]
Split package into separate python2 and python3 subpackages

Thank you Tomas for that tip.

I've tried to rewrite the .spec file according to documentation that you posted, but there are few things that differs.

First, naming. The guide describes how to port python-foo into python2-foo and python3-foo packages. But in this case we even want to have foo package.

Second, that guide assumes that package is installed by `%{__python} setup.py install` while tracer is not.

I gave it my best and tried to improvise. Does this patch looks better for you?

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Hi Jakub!

There are some problems with the spec file:

- Use this line underneath the definition of the Python 2 subpackage: `Provides: %{name} = %{version}-%{release}`
That will make the package available also under the name 'tracer'.
And get rid of this line in your spec: `Requires:	python3-%{name} = %{version}-%{release}`

- For the two descriptions of the subpackages, copy the entire description there.

- You can use a different installation method, that's fine. However, I suggest not to just copy the executable to the /usr/bin/tracer position. I suggest you use a symlink to /usr/bin/tracer-2 instead. If there are both Python versions of the executable available, guidelines say that the binary without the number should launch the python 2 version.

> Use this line [...] And get rid of this line ...

Yeah, much better. Thank you
However now there is a problem, because when I install tracer package, it will not drag python?-tracer as a dependency, so it will not install any files.

> For the two descriptions of the subpackages, copy the entire description there

Well, ok. But it is kind of inconvenient

> I suggest you use a symlink to /usr/bin/tracer-2 instead

Sure, no problem

> guidelines say that the binary without the number should launch the python 2 version.

I saw binary file in python3 subpackage here http://python-rpm-porting.readthedocs.io/en/latest/application-modules.html#ported-rpm-spec-file , so I thought that should be there. But no problem I changed it.

Created attachment 1185063 [details]
Suggested changes

(In reply to Jakub Kadlčík from comment #7)
> > Use this line [...] And get rid of this line ...
> 
> Yeah, much better. Thank you
> However now there is a problem, because when I install tracer package, it
> will not drag python?-tracer as a dependency, so it will not install any
> files.

That is slightly incorrect. The 'Provides' tag works kind of like a symlink, or an icon. If you do 'dnf install tracer', it will actually install the 'python2-tracer' package. So no problems should arise.

> 
> > For the two descriptions of the subpackages, copy the entire description there
> 
> Well, ok. But it is kind of inconvenient
> 
> > I suggest you use a symlink to /usr/bin/tracer-2 instead
> 
> Sure, no problem
> 
> > guidelines say that the binary without the number should launch the python 2 version.
> 
> I saw binary file in python3 subpackage here
> http://python-rpm-porting.readthedocs.io/en/latest/application-modules.
> html#ported-rpm-spec-file , so I thought that should be there. But no
> problem I changed it.

That is a slightly different case: If you want to package only 1 version of the executable, it should be the Python 3 version. But because you want to package both Python 2 and Python 3 versions of the executable, the unversioned executable should be in the Python 2 subpackage. See this section: 

http://python-rpm-porting.readthedocs.io/en/latest/tools.html#ported-rpm-spec-file

I think the patch looks good, though I suggest you test it first, for example in mock).

> If you do 'dnf install tracer', it will actually install the 'python2-tracer' package. So no problems should arise.

Well my experience is different.

I just built tracer in Copr [1], enabled the repository on my machine and did `dnf install tracer`. It installed only tracer package without python2-tracer, so

[vagrant@localhost ~]$ rpm -ql tracer
(contains no files)

[vagrant@localhost ~]$ rpm -ql python2-tracer
package python2-tracer is not installed

[vagrant@localhost ~]$ rpm -ql python3-tracer
package python3-tracer is not installed

[vagrant@localhost ~]$ ls /usr/bin/tracer*
ls: cannot access /usr/bin/tracer*: No such file or directory



[1] https://copr.fedorainfracloud.org/coprs/frostyx/tracer/build/428836/

The problem is that there is an empty "%files" section:

...
-%files -f %{name}.lang
-%doc LICENSE README.md
+%files
+%files -n python2-%{name} -f %{name}.lang
+%license LICENSE
+%doc README.md
...

You want only "%files -n python2-%{name}" and "%files -n python3-%{name}", not "%files". That way the empty "tracer" binary package won't be built.

tracer-0.6.10-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5ddfc70876

tracer-0.6.10-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-86aee67549

tracer-0.6.10-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5ddfc70876

tracer-0.6.10-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-86aee67549

Well, I don't know.

sudo dnf --enablerepo=updates-testing --refresh --best install tracer

still gets 0.6.9-1.fc23 from @updates. However when I try

sudo dnf --enablerepo=updates-testing --refresh --best install python2-tracer

I get 0.6.10-1.fc23 from @updates-testing

Am I missing something? Is it supposed to work this way or the spec file is still wrong?


Thank you guys for helping.

Hi Jakub!

When I try this command, it looks correct:

$ dnf --enablerepo=updates-testing --refresh repoquery --provides python2-tracer
...
python-tracer = 0.6.10-1.fc23
python2-tracer = 0.6.10-1.fc23
tracer = 0.6.10-1.fc23

Therefore I think this may be just an issue of the testing repos.

You can add also a `Obsoletes:      %{name} <= %{version}-%{release}` tag underneath the `Provides` tag to be absolutely sure.

Alternatively, try pushing to stable. If the problem persists, the only harm will be that people using `tracer` won't get the update just yet, and you can add the Obsoletes tag.

P.S. I believe you forgot to push your update to the newly created `f25` branch.

tracer-0.6.11-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-2d83b8297f

tracer-0.6.11-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-286047f96a

tracer-0.6.11-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2d83b8297f

tracer-0.6.11-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-286047f96a

tracer-0.6.11-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

tracer-0.6.11-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.