Missing definition for %{python3_sitelib} in SLE15-SP2
VirtualBox uses this macro as the destination for some files, but it does not exist in SLE15-SP2. What would be a good workaround? Thanks, Larry
Am 13.12.21 um 23:09 schrieb Larry Finger:
VirtualBox uses this macro as the destination for some files, but it does not exist in SLE15-SP2. What would be a good workaround?
The workaround (=fix) is `BuildRequires: python-rpm-macros`, which provides the definition. You don't have to use anything else from the package (singlespec and more), although the redefinition of %py_compile and %__python seems a bit convoluted. As well as the definition of the python3-%{name} subpackage. - Ben
Dne 14. 12. 21 v 1:49 Ben Greiner napsal(a):
The workaround (=fix) is `BuildRequires: python-rpm-macros`, which
Just for the record: it is not a workaround, it is What Is Supposed To Happen™: if your package needs macros from python-rpm-macro for its building than it should just require it. We don't believe that normal user (i.e., the one not building new Python RPM packages) should have to have it installed on her system. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 To bear a grudge and pray, means to sow seed on the sea and expect a harvest. -- Saint Isaac of Nineveh
On Tue, 2021-12-14 at 18:22 +0100, Matěj Cepl wrote:
Dne 14. 12. 21 v 1:49 Ben Greiner napsal(a):
The workaround (=fix) is `BuildRequires: python-rpm-macros`, which
Just for the record: it is not a workaround, it is What Is Supposed To Happen™: if your package needs macros from python-rpm-macro for its building than it should just require it. We don't believe that normal user (i.e., the one not building new Python RPM packages) should have to have it installed on her system.
There's nothing wrong with this, except that you are introducing this requirement in SLE15 in a maintenance update after >3y of product life time. Martin
On 14.12.21 21:50, Martin Wilck <martin.wilck@suse.com> wrote:
There's nothing wrong with this, except that you are introducing this requirement in SLE15 in a maintenance update after >3y of product life time.
https://build.suse.de/request/show/260408 And yes, that's because we have started to synchronize all Python 3.6 packages on all platforms. Matj
On 12/13/21 18:49, Ben Greiner wrote:
Am 13.12.21 um 23:09 schrieb Larry Finger:
VirtualBox uses this macro as the destination for some files, but it does not exist in SLE15-SP2. What would be a good workaround?
The workaround (=fix) is `BuildRequires: python-rpm-macros`, which provides the definition. You don't have to use anything else from the package (singlespec and more), although the redefinition of %py_compile and %__python seems a bit convoluted. As well as the definition of the python3-%{name} subpackage.
Ben, Thanks. That fixed the problem. Larry
On Tue, Dec 14, 2021 at 6:05 AM Larry Finger <Larry.Finger@lwfinger.net> wrote:
VirtualBox uses this macro as the destination for some files, but it does not exist in SLE15-SP2. What would be a good workaround?
It exists as part of the python-rpm-macros package. Make sure that's pulled in as a build dependency. -- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, Dec 14, 2021 at 06:42:11AM -0500, Neal Gompa wrote:
On Tue, Dec 14, 2021 at 6:05 AM Larry Finger <Larry.Finger@lwfinger.net> wrote:
VirtualBox uses this macro as the destination for some files, but it does not exist in SLE15-SP2. What would be a good workaround?
It exists as part of the python-rpm-macros package. Make sure that's pulled in as a build dependency.
Looks like this used to be pulled in by something but not anymore for multiple packages. I maintain a python package which started failing on 15.2 and 15.3 due to lack of this macro. Thanks Michal
Am 14.12.21 um 15:47 schrieb Michal Suchánek:
On Tue, Dec 14, 2021 at 06:42:11AM -0500, Neal Gompa wrote:
On Tue, Dec 14, 2021 at 6:05 AM Larry Finger <Larry.Finger@lwfinger.net> wrote:
VirtualBox uses this macro as the destination for some files, but it does not exist in SLE15-SP2. What would be a good workaround?
It exists as part of the python-rpm-macros package. Make sure that's pulled in as a build dependency. Looks like this used to be pulled in by something but not anymore for multiple packages.
I maintain a python package which started failing on 15.2 and 15.3 due to lack of this macro.
Thanks
Michal
AFAIR it was intentional but reverted for Tumbleweed, apparently the reversal didn't make it into SLE15-SP2: https://build.opensuse.org/request/show/864328 talks about bsc#1180125, but that one is not available for us non-SUSErs. IMHO you should explicitly require it if you are using definitions from it. - Ben
On Tue, 2021-12-14 at 16:36 +0100, Ben Greiner wrote:
Am 14.12.21 um 15:47 schrieb Michal Suchánek:
On Tue, Dec 14, 2021 at 06:42:11AM -0500, Neal Gompa wrote:
On Tue, Dec 14, 2021 at 6:05 AM Larry Finger <Larry.Finger@lwfinger.net> wrote:
VirtualBox uses this macro as the destination for some files, but it does not exist in SLE15-SP2. What would be a good workaround?
It exists as part of the python-rpm-macros package. Make sure that's pulled in as a build dependency. Looks like this used to be pulled in by something but not anymore for multiple packages.
I maintain a python package which started failing on 15.2 and 15.3 due to lack of this macro.
Thanks
Michal
AFAIR it was intentional but reverted for Tumbleweed, apparently the reversal didn't make it into SLE15-SP2: https://build.opensuse.org/request/show/864328 talks about bsc#1180125, but that one is not available for us non-SUSErs.
IMHO you should explicitly require it if you are using definitions from it.
1180125 was a complaint that python3-base pulls in python-rpm-macros. Some people seem seriously concerned about 50kB worth of rpm macro code. The solution was to remove the dependency. I believe this was ill- advised. If python is installed, I expect 'rpm --eval %{python_version}' to work. The fact that the dependency has now been added to the rpm package instead makes no sense to me. What did we gain in the end by moving this dependency from python3-base to rpm? Martin
Am 14.12.21 um 17:08 schrieb Martin Wilck:
Looks like this used to be pulled in by something but not anymore for multiple packages.
I maintain a python package which started failing on 15.2 and 15.3 due to lack of this macro. Thanks
Michal AFAIR it was intentional but reverted for Tumbleweed, apparently the reversal didn't make it into SLE15-SP2: https://build.opensuse.org/request/show/864328 talks about bsc#1180125, but that one is not available for us non-SUSErs.
IMHO you should explicitly require it if you are using definitions from it. 1180125 was a complaint that python3-base pulls in python-rpm-macros. Some people seem seriously concerned about 50kB worth of rpm macro code.
The solution was to remove the dependency. I believe this was ill- advised. If python is installed, I expect 'rpm --eval %{python_version}' to work.
That's the worst example. Considering the singlespec system, which version should this command return? If you want to get the python version of the command currently in your path, use the python interpreter directly. If you want to know which python package is installed with the system packages use `zypper search --provides python(abi)` or `rpm -qf /usr/bin/python*`
The fact that the dependency has now been added to the rpm package instead makes no sense to me. What did we gain in the end by moving this dependency from python3-base to rpm?
python-rpm-macros is a package used during building. Why should python3-base pull it in for user installations?
On Tue, 2021-12-14 at 18:10 +0100, Ben Greiner wrote:
The solution was to remove the dependency. I believe this was ill- advised. If python is installed, I expect 'rpm --eval %{python_version}' to work.
That's the worst example. Considering the singlespec system, which version should this command return?
Outside the build environment: the system's primary version. And that's what it does, AFAICT. Granted, it's not important. But it was my expectation.
The fact that the dependency has now been added to the rpm package instead makes no sense to me. What did we gain in the end by moving this dependency from python3-base to rpm?
python-rpm-macros is a package used during building. Why should python3-base pull it in for user installations?
The discussion here was about SLE15/Leap15. python3-base has pulled in python-rpm-macros for >3y on this "stable" code base. It's no surprise that packages rely on that, and it should be no surprise that people are annoyed that their package builds suddenly break because the dependency was silently dropped in a maintenance update. So far there was no requirement to use explicit BuildRequires on python-rpm-macros (I'm not talking about python modules / singlespec, just about an application that happens to be written in python). On TW it's implicitly pulled in via rpm-build -> rpm-build-python, but no such chain exists for Code 15. Martin
On 12/15/21 02:38, Martin Wilck wrote:
On Tue, 2021-12-14 at 16:36 +0100, Ben Greiner wrote:
Am 14.12.21 um 15:47 schrieb Michal Suchánek:
On Tue, Dec 14, 2021 at 06:42:11AM -0500, Neal Gompa wrote:
On Tue, Dec 14, 2021 at 6:05 AM Larry Finger <Larry.Finger@lwfinger.net> wrote:
VirtualBox uses this macro as the destination for some files, but it does not exist in SLE15-SP2. What would be a good workaround?
It exists as part of the python-rpm-macros package. Make sure that's pulled in as a build dependency. Looks like this used to be pulled in by something but not anymore for multiple packages.
I maintain a python package which started failing on 15.2 and 15.3 due to lack of this macro.
Thanks
Michal
AFAIR it was intentional but reverted for Tumbleweed, apparently the reversal didn't make it into SLE15-SP2: https://build.opensuse.org/request/show/864328 talks about bsc#1180125, but that one is not available for us non-SUSErs.
IMHO you should explicitly require it if you are using definitions from it.
1180125 was a complaint that python3-base pulls in python-rpm-macros. Some people seem seriously concerned about 50kB worth of rpm macro code.
People looking at this are concerned about 50Kb of code because they aren't thinking in terms of 1 machine in the way we do but because they are thinking in terms of a system running 10's of thousands of container or VM images at the same time. At this scale an extra few packages with an 50k starts to be noticeable in memory usage and loading times across the greater system. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Wed, 2021-12-15 at 13:58 +1030, Simon Lees wrote:
People looking at this are concerned about 50Kb of code because they aren't thinking in terms of 1 machine in the way we do but because they are thinking in terms of a system running 10's of thousands of container or VM images at the same time. At this scale an extra few packages with an 50k starts to be noticeable in memory usage and loading times across the greater system.
I understand that. Yet we have many more worthwhile opportunities for saving space than this. Just one example, the changelog of the kernel- default package alone is 6MiB, more than 100x the size of python-rpm- macros (and that changelog is present multiple times on average (open)SUSE installations). I know that this doesn't imply saving 50k here is wrong, bit it's clearly not the primary knob to press if we want to decrease disk usage. Martin
participants (9)
-
Ben Greiner -
Larry Finger -
Martin Wilck -
Martin Wilck -
Matěj Cepl -
mcepl＠cepl.eu
-
Michal Suchánek -
Neal Gompa -
Simon Lees