On Thu, Apr 13, 2017 at 9:06 AM, jan matejek
On 12.4.2017 17:01, Todd Rme wrote:
Try here: https://build.opensuse.org/package/show/home:TheBlackCat:branches:devel:lang...
I get errors like this outside Tumbleweed: "nothing provides %{python_module, nothing provides testtools = %{version}}"
You're missing this line: %{?!python_module:%define python_module() python-%{**} python3-%{**}} Because it's used in BuildRequires, it must be either in prjconf (in Factory) or in the spec file.
Next time I will wait until after my 101 degree fever is over before asking ;) Sorry.
Even in setuptools, you sometimes need to run %py_compile due to, for example, "inconsistent mtime" rpmlint warnings.
If you get "inconsistent mtime" from setup.py install, it's either the installer's or your packaging bug. Usually you're running tests that touch things they shouldn't.
(But yes, %py_compiling it again is often easier than fixing it properly.)
I have seen it in other situations as well, and it isn't necessarily easy to track down.
But more and more packages are shipping wheels only, so having support for %py_compile, and less importantly "pip install", is becoming important.
wouldn't "pip install" take care of it too?
Once pypi starts providing consistent URLs for wheels we can do that when they are provided. But even then there are packages with their own home-made build systems that still need to be byte-compiled manually.
In any case I'm not convinced that this should be a part of the "singlespec API". Basing decision on "major version of python", as opposed to "is this python2 or something newer", does not look like a good practice. (and if it's limited to one package, you can easily get, e.g. from %python_version_nodots) OTOH, maybe this distinction will be useful again with Python 4 somewhere down the road, so perhaps?
I agree with you, but this is an upstream decision.
And also easily resolvable inside the spec file. The question here is whether this should be directly supported by a singlespec macro.
One more point against it that it's not general: for instance, in LXML, you run "make test" for python2 tests and "make test3" for python3. Here you would need a variable that is "" for python2 and "3" for python3. In other cases, you need "2" for python2 and "3" for python3. Next time it might be "2" for python2, "pp" for PyPy and "" for python3?
...and as long as you're if'ing it anyway, you can do this: if [ %{$python_version_nodots} -ge 30 ]; then mysuffix=3 else mysuffix=2 fi
or even: mysuffix=`expr %{$python_version_nodots} / 10`
I agree that it isn't a desirable situation, but if we want our users to be able to use upstream documentation then we need to support upstream naming conventions. We can create links with our own naming patterns, but if upstream provides executable with certain names we need to have those executables as well. And I think this is a common enough upstream naming pattern that there should be support for it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org