Avoiding file conflicts with multi-flavor builds
Hello! I have a Python package which installs into %{_bindir} and %{_mandir} which causes file conflicts for multi-flavor builds between Python 3.6 and 3.8. Is there a policy and mechanism how to deal with these file conflicts? Thanks, Adrian
Hi, does https://en.opensuse.org/openSUSE:Packaging_Python#Executables answer your question? Sebastian On 4/8/21 12:14 PM, John Paul Adrian Glaubitz wrote:
Hello!
I have a Python package which installs into %{_bindir} and %{_mandir} which causes file conflicts for multi-flavor builds between Python 3.6 and 3.8.
Is there a policy and mechanism how to deal with these file conflicts?
On 4/8/21 12:20 PM, Sebix wrote:
does https://en.opensuse.org/openSUSE:Packaging_Python#Executables answer your question?
Right, I was already looking at this wiki package before but I completely forgot about the update-alternatives mechanism, probably due to lack of coffee :-). Thanks, Adrian
On 4/8/21 12:24 PM, John Paul Adrian Glaubitz wrote:
On 4/8/21 12:20 PM, Sebix wrote:
does https://en.opensuse.org/openSUSE:Packaging_Python#Executables answer your question?
Right, I was already looking at this wiki package before but I completely forgot about the update-alternatives mechanism, probably due to lack of coffee :-).
Hmm, the %python_alternative script tries to be too clever and fails in finding the correct file pattern in the %files section [1]: [ 47s] RPM build errors: [ 47s] File not found: /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-2.1.x86_64/usr/share/man/man1/*-3.6 Any idea? Adrian
[1] https://build.opensuse.org/package/show/home:glaubitz:branches:Cloud:Tools/p...
Hmm, the %python_alternative script tries to be too clever and fails in finding the correct file pattern in the %files section [1]:
[ 47s] RPM build errors: [ 47s] File not found: /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-2.1.x86_64/usr/share/man/man1/*-3.6
Any idea?
The macro is actually not clever enough. You have to expand the filelist before the macro sees it. python_alternative must create several directives per file: foo, foo-3.6 and the ghost entry. And the results are different for manpages, so the lua cannot just mangle the still unexpanded shell glob pattern. The same is true for %python_install_alternative, which would just write the glob into the scriptlet. I suspect rpmlint will give you an error there, because it cannot expand the glob and compare with the filelist.
Hmm, the %python_alternative script tries to be too clever and fails in finding the correct file pattern in the %files section [1]:
[ 47s] RPM build errors: [ 47s] File not found: /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-2.1.x86_64/usr/share/man/man1/*-3.6
Any idea?
The macro is actually not clever enough. You have to expand the filelist before the macro sees it. python_alternative must create several directives per file: foo, foo-3.6 and the ghost entry. And the results are different for manpages, so the lua cannot just mangle the still unexpanded shell glob pattern. The same is true for %python_install_alternative, which would just write the glob into the scriptlet. I suspect rpmlint will give you an error there, because it cannot expand the glob and compare with the filelist.
On 4/8/21 3:15 PM, Ben Greiner wrote:
Hmm, the %python_alternative script tries to be too clever and fails in finding the correct file pattern in the %files section [1]:
[ 47s] RPM build errors: [ 47s] File not found: /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-2.1.x86_64/usr/share/man/man1/*-3.6
Any idea?
The macro is actually not clever enough. You have to expand the filelist before the macro sees it. python_alternative must create several directives per file: foo, foo-3.6 and the ghost entry. And the results are different for manpages, so the lua cannot just mangle the still unexpanded shell glob pattern.
The same is true for %python_install_alternative, which would just write the glob into the scriptlet. I suspect rpmlint will give you an error there, because it cannot expand the glob and compare with the filelist.
So, it works without using globs but I'm getting warnings on the use of absolute symlinks that I don't know how to fix [1]. I used the Python alternative mechanism as described in the documentation but it seems I'm missing something. Adrian
[1] https://build.opensuse.org/package/live_build_log/home:glaubitz:branches:Clo...
Am 12.04.21 um 12:17 schrieb John Paul Adrian Glaubitz:
On 4/8/21 3:15 PM, Ben Greiner wrote:
Hmm, the %python_alternative script tries to be too clever and fails in finding the correct file pattern in the %files section [1]:
[ 47s] RPM build errors: [ 47s] File not found: /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-2.1.x86_64/usr/share/man/man1/*-3.6
Any idea? The macro is actually not clever enough. You have to expand the filelist before the macro sees it. python_alternative must create several directives per file: foo, foo-3.6 and the ghost entry. And the results are different for manpages, so the lua cannot just mangle the still unexpanded shell glob pattern.
The same is true for %python_install_alternative, which would just write the glob into the scriptlet. I suspect rpmlint will give you an error there, because it cannot expand the glob and compare with the filelist. So, it works without using globs but I'm getting warnings on the use of absolute symlinks that I don't know how to fix [1]. I used the Python alternative mechanism as described in the documentation but it seems I'm missing something. Adrian
[1]https://build.opensuse.org/package/live_build_log/home:glaubitz:branches:Clo...
rpm -q --scripts binaries/python36-aliyun-img-utils-1.1.0-4.1.x86_64.rpm warning: binaries/python36-aliyun-img-utils-1.1.0-4.1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 3db1b31d: NOKEY
The filenames for aliyun-img-utils-image-{activate,create,delete}.1 do not match the entries in %python_install_alternative. The -image- infix is missing there. postinstall scriptlet (using /bin/sh): update-alternatives --quiet --install /usr/bin/aliyun-img-utils aliyun-img-utils /usr/bin/aliyun-img-utils-3.6 36 \ --slave /usr/share/man/man1/aliyun-img-utils-activate.1.gz aliyun-img-utils-activate.1.gz /usr/share/man/man1/aliyun-img-utils-activate-3.6.1.gz \ --slave /usr/share/man/man1/aliyun-img-utils-create.1.gz aliyun-img-utils-create.1.gz /usr/share/man/man1/aliyun-img-utils-create-3.6.1.gz \ --slave /usr/share/man/man1/aliyun-img-utils-delete.1.gz aliyun-img-utils-delete.1.gz /usr/share/man/man1/aliyun-img-utils-delete-3.6.1.gz \ --slave /usr/share/man/man1/aliyun-img-utils-image-deprecate.1.gz aliyun-img-utils-image-deprecate.1.gz /usr/share/man/man1/aliyun-img-utils-image-deprecate-3.6.1.gz \ --slave /usr/share/man/man1/aliyun-img-utils-image-info.1.gz aliyun-img-utils-image-info.1.gz /usr/share/man/man1/aliyun-img-utils-image-info-3.6.1.gz \ --slave /usr/share/man/man1/aliyun-img-utils-image-publish.1.gz aliyun-img-utils-image-publish.1.gz /usr/share/man/man1/aliyun-img-utils-image-publish-3.6.1.gz \ --slave /usr/share/man/man1/aliyun-img-utils-image-replicate.1.gz aliyun-img-utils-image-replicate.1.gz /usr/share/man/man1/aliyun-img-utils-image-replicate-3.6.1.gz \ --slave /usr/share/man/man1/aliyun-img-utils-image-upload.1.gz aliyun-img-utils-image-upload.1.gz /usr/share/man/man1/aliyun-img-utils-image-upload-3.6.1.gz \ --slave /usr/share/man/man1/aliyun-img-utils-image.1.gz aliyun-img-utils-image.1.gz /usr/share/man/man1/aliyun-img-utils-image-3.6.1.gz \ --slave /usr/share/man/man1/aliyun-img-utils.1.gz aliyun-img-utils.1.gz /usr/share/man/man1/aliyun-img-utils-3.6.1.gz postuninstall scriptlet (using /bin/sh): if [ ! -e "/usr/bin/aliyun-img-utils-3.6" ]; then update-alternatives --quiet --remove "aliyun-img-utils" "/usr/bin/aliyun-img-utils-3.6" fi ---- But I agree that the error message is very misleading, because there is some hidden behavior involving %{man_ext}: [ 23s] + cp /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils.1 /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils-3.6.1 [ 23s] + sed -ri '1s@#!.*python.*@#!/usr/bin/python3.6@' /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils-3.6.1 [ 23s] + cp /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils.1 /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils-3.8.1 [ 23s] + sed -ri '1s@#!.*python.*@#!/usr/bin/python3.8@' /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils-3.8.1 [ 23s] + rm -f /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils.1.gz [ 23s] + alternative_target=/usr/share/man/man1/aliyun-img-utils.1.gz [ 23s] + [[ /usr/share/man/man1/aliyun-img-utils.1.gz == /usr/share/man* ]] [ 23s] + rm -f /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils.1 [ 23s] + rm -f /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils.1.gz.gz [ 23s] + mkdir -p /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/etc/alternatives [ 23s] + touch /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/etc/alternatives/aliyun-img-utils.1.gz [ 23s] + ln -sf /etc/alternatives/aliyun-img-utils.1.gz /home/abuild/rpmbuild/BUILDROOT/python-aliyun-img-utils-1.1.0-3.1.x86_64/usr/share/man/man1/aliyun-img-utils.1.gz There is some automatic compression happening in the post build hooks and apparently the macros take this into account without being too verbose about it:
rpm -ql binaries/python36-aliyun-img-utils-1.1.0-4.1.x86_64.rpm ... /usr/share/man/man1/aliyun-img-utils-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-activate-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-activate.1.gz /usr/share/man/man1/aliyun-img-utils-image-create-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-create.1.gz /usr/share/man/man1/aliyun-img-utils-image-delete-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-delete.1.gz /usr/share/man/man1/aliyun-img-utils-image-deprecate-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-deprecate.1.gz /usr/share/man/man1/aliyun-img-utils-image-info-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-info.1.gz /usr/share/man/man1/aliyun-img-utils-image-publish-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-publish.1.gz /usr/share/man/man1/aliyun-img-utils-image-replicate-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-replicate.1.gz /usr/share/man/man1/aliyun-img-utils-image-upload-3.6.1.gz /usr/share/man/man1/aliyun-img-utils-image-upload.1.gz /usr/share/man/man1/aliyun-img-utils-image.1.gz /usr/share/man/man1/aliyun-img-utils.1.gz
On 4/12/21 4:06 PM, Ben Greiner wrote:
[1]https://build.opensuse.org/package/live_build_log/home:glaubitz:branches:Clo...
The filenames for aliyun-img-utils-image-{activate,create,delete}.1 do not match the entries in %python_install_alternative. The -image- infix is missing there.
Argh, that explains the problem. Thanks, Adrian
Hi, On 08 Apr 12:14 2021, John Paul Adrian Glaubitz wrote:
Hello!
I have a Python package which installs into %{_bindir} and %{_mandir} which causes file conflicts for multi-flavor builds between Python 3.6 and 3.8.
Is there a policy and mechanism how to deal with these file conflicts?
You can use %python_clone, see https://en.opensuse.org/openSUSE:Packaging_Python#Executables Regards, ismail -- Half of everything you hear in a classroom is crap. Education is figuring out which half is which. — Larrabee's Law SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
participants (5)
-
Ben Greiner -
factory＠lists.opensuse.org -
İsmail Dönmez -
John Paul Adrian Glaubitz -
Sebix