Puzzled by a line in a python spec file: Why does this work?

newer
Weekly report on updates for...

older
Weekly report on packages in...

Johannes Kastl

13 Jan 2023 13 Jan '23

07:17

Hi all, yesterday I came across a line in a python spec file that somehow works, but I have no clue why.

...

https://build.opensuse.org/package/show/devel:languages:python/python-pycode...

...

%install %python_install %python_clone %{buildroot}%{_bindir}/pycodestyle ln -sf pycodestyle-%{python3_bin_suffix} %{buildroot}%{_bindir}/pycodestyle %python_expand %fdupes %{buildroot}/%{$python_sitelib}

I am talking about the "ln" line. Apparently it creates a relative soft link in the %{buildroot}%{_bindir}/ directory pointing to the file pycodestyle in the same directory %{buildroot}%{_bindir}/. For me this command looks "the wrong way round", because I am used to have "ln -sf foo bar" create a new link "bar" pointing to "foo". So "foo" is the file already existing, and "bar" is the link that gets created. Not the other way round. In addition, in the current working directory there is no file "pycodestyle-%{python3_bin_suffix}". So all this should do is create a broken link by overwriting "%{buildroot}%{_bindir}/pycodestyle" with a link pointing to a non-existent file. But it does not. Apparently it changes the working directory before creating the link. And: If I change the working directory to "%{buildroot}%{_bindir}/" and rewrite the line to be "in the correct order" (at least according to the man page and how I am used to writing ln commands), I get an error that there is an unpackaged file called "/usr/bin/_current_flavor". Huh? If I remove the line, it fails as soon as there are multiple python versions in %pythons, as there are file conflicts for /usr/bin/pycodestyle. It however builds successfully on e.g. 15.4 where there is only one python version present... Does the %python_clone macro also modify the following line? Or is this some magic inside the %{python3_bin_suffix} macro (which only seems to evaluate to either %_python3_bin_suffix or %python3_version, so no magic on first glance). I would be really glad if someone could remove the tomatoes from my eyes or explain why that works. Thanks in advance. Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Attachments:

OpenPGP_signature.sig (application/pgp-signature — 840 bytes)

Show replies by date

Dan Čermák

13 Jan 13 Jan

07:23

Hi Johannes, Johannes Kastl writes:

...

Hi all,

yesterday I came across a line in a python spec file that somehow works, but I have no clue why.

...
https://build.opensuse.org/package/show/devel:languages:python/python-pycode...

...
%install %python_install %python_clone %{buildroot}%{_bindir}/pycodestyle ln -sf pycodestyle-%{python3_bin_suffix} %{buildroot}%{_bindir}/pycodestyle %python_expand %fdupes %{buildroot}/%{$python_sitelib}

I am talking about the "ln" line.

Apparently it creates a relative soft link in the %{buildroot}%{_bindir}/ directory pointing to the file pycodestyle in the same directory %{buildroot}%{_bindir}/.

For me this command looks "the wrong way round", because I am used to have "ln -sf foo bar" create a new link "bar" pointing to "foo". So "foo" is the file already existing, and "bar" is the link that gets created. Not the other way round.

In addition, in the current working directory there is no file "pycodestyle-%{python3_bin_suffix}". So all this should do is create a broken link by overwriting "%{buildroot}%{_bindir}/pycodestyle" with a link pointing to a non-existent file.

But it does not. Apparently it changes the working directory before creating the link.

The magic here is the %python_clone macro, which according to the upstream documentation [1] performs the following: --8<---------------cut here---------------start------------->8--- %python_clone filename creates a copy of filename under a flavor-specific name for every flavor. This is useful for packages that install unversioned executables: /usr/bin/foo is copied to /usr/bin/foo-%{python_bin_suffix} for all flavors, and the shebang is modified accordingly. --8<---------------cut here---------------end--------------->8--- Cheers, Dan Footnotes: [1] https://github.com/openSUSE/python-rpm-macros#install-macros -- Dan Čermák Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

Johannes Kastl

07:29

Good morning Dan, On 13.01.23 at 08:23 Dan Čermák wrote:

...

...
But it does not. Apparently it changes the working directory before creating the link.

The magic here is the %python_clone macro, which according to the upstream documentation [1] performs the following:

--8<---------------cut here---------------start------------->8--- %python_clone filename creates a copy of filename under a flavor-specific name for every flavor. This is useful for packages that install unversioned executables: /usr/bin/foo is copied to /usr/bin/foo-%{python_bin_suffix} for all flavors, and the shebang is modified accordingly. --8<---------------cut here---------------end--------------->8---

The %python_clone creates the file and modifies its shebang. But it does not create a link. The state before the ln line is that there are multiple versions of pycodestlye in the %{buildroot}%{_bindir}/ directory. Files, not links (otherwise the ln line would be unnecessary). That part is clear to me. The funny part is why the ln line works the way it does. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Dan Čermák

08:19

Johannes Kastl writes:

...

Good morning Dan,

On 13.01.23 at 08:23 Dan Čermák wrote:

...
...
But it does not. Apparently it changes the working directory before creating the link.

The magic here is the %python_clone macro, which according to the upstream documentation [1] performs the following:

--8<---------------cut here---------------start------------->8--- %python_clone filename creates a copy of filename under a flavor-specific name for every flavor. This is useful for packages that install unversioned executables: /usr/bin/foo is copied to /usr/bin/foo-%{python_bin_suffix} for all flavors, and the shebang is modified accordingly. --8<---------------cut here---------------end--------------->8---

The %python_clone creates the file and modifies its shebang. But it does not create a link.

The state before the ln line is that there are multiple versions of pycodestlye in the %{buildroot}%{_bindir}/ directory. Files, not links (otherwise the ln line would be unnecessary).

This is the state before the ln: [ 11s] -rwxr-xr-x. 1 abuild abuild 984 Jan 13 09:14 pycodestyle [ 11s] -rwxr-xr-x. 1 abuild abuild 984 Jan 13 09:14 pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.8 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.9 and this is how it looks after the ln: [ 11s] lrwxrwxrwx. 1 abuild abuild 16 Jan 13 09:14 pycodestyle -> pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 984 Jan 13 09:14 pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.8 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.9 which, is more or less what I'd expect, is it not? Cheers, Dan -- Dan Čermák Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

Johannes Kastl

08:39

Hi Dan, On 13.01.23 at 09:19 Dan Čermák wrote:

...

and this is how it looks after the ln:

[ 11s] lrwxrwxrwx. 1 abuild abuild 16 Jan 13 09:14 pycodestyle -> pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 984 Jan 13 09:14 pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.8 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.9

which, is more or less what I'd expect, is it not?

Yes, but only if I call the ln command **inside this folder**. But the ln command is called from inside the "/home/abuild/rpmbuild/BUILD/pycodestyle-2.10.0" directory, not from "/home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/". (At least if the pwd I inserted does not lie to me...). So in my limited understanding the link should not have been created in the .../usr/bin/ folder, but inside "/home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/". See this output:

...

[ 9s] + pwd [ 9s] /home/abuild/rpmbuild/BUILD/pycodestyle-2.10.0 [ 9s] + cp /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.8 [ 9s] + sed -ri '1s@#!.*python.*@#!/usr/bin/python3.8@' /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.8 [ 9s] + cp /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.9 [ 9s] + sed -ri '1s@#!.*python.*@#!/usr/bin/python3.9@' /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.9 [ 9s] + cp /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.10 [ 9s] + sed -ri '1s@#!.*python.*@#!/usr/bin/python3.10@' /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.10

This is from the %python_clone

...

[ 9s] + pwd [ 9s] /home/abuild/rpmbuild/BUILD/pycodestyle-2.10.0 [ 9s] + ls -lh /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.10 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.8 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.9 [ 9s] -rwxr-xr-x 1 abuild abuild 984 Jan 13 08:29 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle [ 9s] -rwxr-xr-x 1 abuild abuild 984 Jan 13 08:29 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.10 [ 9s] -rwxr-xr-x 1 abuild abuild 983 Jan 13 08:29 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.8 [ 9s] -rwxr-xr-x 1 abuild abuild 983 Jan 13 08:29 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.9

This was the output of "ls -lh %{buildroot}%{_bindir}/pycodestyle*"

...

[ 9s] + pwd [ 9s] /home/abuild/rpmbuild/BUILD/pycodestyle-2.10.0

Working directory before the ln command.

...

[ 9s] + ln -sf pycodestyle-3.10 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle

Working directory after the ln command, no file in the current directory:

...

[ 9s] + ls -lh [ 9s] total 216K [ 9s] -rw-r--r-- 1 abuild abuild 27K Nov 23 18:26 CHANGES.txt [ 9s] -rw-r--r-- 1 abuild abuild 3.1K Nov 23 18:26 CONTRIBUTING.rst [ 9s] -rw-r--r-- 1 abuild abuild 1.3K Nov 23 18:26 LICENSE [ 9s] -rw-r--r-- 1 abuild abuild 243 Nov 23 18:26 MANIFEST.in [ 9s] -rw-r--r-- 1 abuild abuild 31K Nov 23 18:27 PKG-INFO [ 9s] -rw-r--r-- 1 abuild abuild 3.4K Nov 23 18:26 README.rst [ 9s] drwxr-xr-x 3 abuild abuild 4.0K Jan 13 08:29 _build.python38 [ 9s] drwxr-xr-x 3 abuild abuild 4.0K Jan 13 08:29 _build.python39 [ 9s] -rw-r--r-- 1 abuild abuild 10 Jan 13 08:29 _current_flavor [ 9s] drwxr-xr-x 3 abuild abuild 4.0K Jan 13 08:29 build [ 9s] -rw-r--r-- 1 abuild abuild 4 Nov 23 18:26 dev-requirements.txt [ 9s] drwxr-xr-x 2 abuild abuild 4.0K Nov 23 18:27 docs [ 9s] drwxr-xr-x 2 abuild abuild 4.0K Jan 13 08:29 pycodestyle.egg-info [ 9s] -rwxr-xr-x 1 abuild abuild 100K Jan 13 08:29 pycodestyle.py [ 9s] -rw-r--r-- 1 abuild abuild 191 Nov 23 18:27 setup.cfg [ 9s] -rw-r--r-- 1 abuild abuild 1.9K Nov 23 18:26 setup.py [ 9s] drwxr-xr-x 2 abuild abuild 4.0K Nov 23 18:27 testsuite [ 9s] + exit 99

I just tested this, apparently ln has hidden superpowers (that I did not find in the man page): If I call "ln -sf /tmp/something foo", then "foo" gets created in my current directory. If I call "ln -sf foo /tmp/something" from any directory, then "/tmp/something" gets overwritten with a link to "foo" **relative to the /tmp/ directory**

...

$ ln -sf foo /tmp/something $ cd /tmp/ $ ll something* lrwxrwxrwx 1 xxx users 3 13. Jan 09:36 something -> foo $

So, that part seems solved. I still do not understand the packaging error for /usr/bin/_current_flavor if I create the link manually inside the directory: %python_clone %{buildroot}%{_bindir}/pycodestyle cd %{buildroot}%{_bindir}/ln -sf pycodestyle-%{python3_bin_suffix} pycodestyle %python_expand %fdupes %{buildroot}/%{$python_sitelib} Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Dan Čermák

09:22

Johannes Kastl writes:

...

Hi Dan,

On 13.01.23 at 09:19 Dan Čermák wrote:

...
and this is how it looks after the ln:

[ 11s] lrwxrwxrwx. 1 abuild abuild 16 Jan 13 09:14 pycodestyle -> pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 984 Jan 13 09:14 pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.8 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.9

which, is more or less what I'd expect, is it not?

Yes, but only if I call the ln command **inside this folder**.

Nope: --8<---------------cut here---------------start------------->8--- ❯ mkdir -p /tmp/foo && touch /tmp/foo/bar && ln -sf bar /tmp/foo/baz ❯ ll /tmp/foo/ total 0 -rw-r--r--. 1 dan dan 0 Jan 13 10:18 bar lrwxrwxrwx. 1 dan dan 3 Jan 13 10:18 baz -> bar --8<---------------cut here---------------end--------------->8---

...

But the ln command is called from inside the "/home/abuild/rpmbuild/BUILD/pycodestyle-2.10.0" directory, not from "/home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/". (At least if the pwd I inserted does not lie to me...).

So in my limited understanding the link should not have been created in the .../usr/bin/ folder, but inside "/home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/".

See this output:

...
[ 9s] + pwd [ 9s] /home/abuild/rpmbuild/BUILD/pycodestyle-2.10.0 [ 9s] + cp /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.8 [ 9s] + sed -ri '1s@#!.*python.*@#!/usr/bin/python3.8@' /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.8 [ 9s] + cp /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.9 [ 9s] + sed -ri '1s@#!.*python.*@#!/usr/bin/python3.9@' /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.9 [ 9s] + cp /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.10 [ 9s] + sed -ri '1s@#!.*python.*@#!/usr/bin/python3.10@' /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.10

This is from the %python_clone

...
[ 9s] + pwd [ 9s] /home/abuild/rpmbuild/BUILD/pycodestyle-2.10.0 [ 9s] + ls -lh /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.10 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.8 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.9 [ 9s] -rwxr-xr-x 1 abuild abuild 984 Jan 13 08:29 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle [ 9s] -rwxr-xr-x 1 abuild abuild 984 Jan 13 08:29 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.10 [ 9s] -rwxr-xr-x 1 abuild abuild 983 Jan 13 08:29 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.8 [ 9s] -rwxr-xr-x 1 abuild abuild 983 Jan 13 08:29 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle-3.9

This was the output of "ls -lh %{buildroot}%{_bindir}/pycodestyle*"

...
[ 9s] + pwd [ 9s] /home/abuild/rpmbuild/BUILD/pycodestyle-2.10.0

Working directory before the ln command.

...
[ 9s] + ln -sf pycodestyle-3.10 /home/abuild/rpmbuild/BUILDROOT/python-pycodestyle-2.10.0-0.x86_64/usr/bin/pycodestyle

Working directory after the ln command, no file in the current directory:

...
[ 9s] + ls -lh [ 9s] total 216K [ 9s] -rw-r--r-- 1 abuild abuild 27K Nov 23 18:26 CHANGES.txt [ 9s] -rw-r--r-- 1 abuild abuild 3.1K Nov 23 18:26 CONTRIBUTING.rst [ 9s] -rw-r--r-- 1 abuild abuild 1.3K Nov 23 18:26 LICENSE [ 9s] -rw-r--r-- 1 abuild abuild 243 Nov 23 18:26 MANIFEST.in [ 9s] -rw-r--r-- 1 abuild abuild 31K Nov 23 18:27 PKG-INFO [ 9s] -rw-r--r-- 1 abuild abuild 3.4K Nov 23 18:26 README.rst [ 9s] drwxr-xr-x 3 abuild abuild 4.0K Jan 13 08:29 _build.python38 [ 9s] drwxr-xr-x 3 abuild abuild 4.0K Jan 13 08:29 _build.python39 [ 9s] -rw-r--r-- 1 abuild abuild 10 Jan 13 08:29 _current_flavor [ 9s] drwxr-xr-x 3 abuild abuild 4.0K Jan 13 08:29 build [ 9s] -rw-r--r-- 1 abuild abuild 4 Nov 23 18:26 dev-requirements.txt [ 9s] drwxr-xr-x 2 abuild abuild 4.0K Nov 23 18:27 docs [ 9s] drwxr-xr-x 2 abuild abuild 4.0K Jan 13 08:29 pycodestyle.egg-info [ 9s] -rwxr-xr-x 1 abuild abuild 100K Jan 13 08:29 pycodestyle.py [ 9s] -rw-r--r-- 1 abuild abuild 191 Nov 23 18:27 setup.cfg [ 9s] -rw-r--r-- 1 abuild abuild 1.9K Nov 23 18:26 setup.py [ 9s] drwxr-xr-x 2 abuild abuild 4.0K Nov 23 18:27 testsuite [ 9s] + exit 99

I just tested this, apparently ln has hidden superpowers (that I did not find in the man page):

If I call "ln -sf /tmp/something foo", then "foo" gets created in my current directory. If I call "ln -sf foo /tmp/something" from any directory, then "/tmp/something" gets overwritten with a link to "foo" **relative to the /tmp/ directory**

...
$ ln -sf foo /tmp/something $ cd /tmp/ $ ll something* lrwxrwxrwx 1 xxx users 3 13. Jan 09:36 something -> foo $

So, that part seems solved. I still do not understand the packaging error for /usr/bin/_current_flavor if I create the link manually inside the directory:

%python_clone %{buildroot}%{_bindir}/pycodestyle cd %{buildroot}%{_bindir}/ln -sf pycodestyle-%{python3_bin_suffix} pycodestyle

This is due to the python flavor switching magic which is performed by writing the current python flavor into the file _current_flavor. The macros assume that the switching code is never executed inside %buildroot and so littering pwd with additional files is not an issue. It becomes one if you cd into %{buildroot} of course. Cheers, Dan -- Dan Čermák Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

Johannes Kastl

09:32

New subject: Solved (was: Puzzled by a line in a python spec file: Why does this work?)

Thanks for your patience, Dan! On 13.01.23 at 10:22 Dan Čermák wrote:

...

Johannes Kastl writes:

...
On 13.01.23 at 09:19 Dan Čermák wrote:

...
and this is how it looks after the ln:

[ 11s] lrwxrwxrwx. 1 abuild abuild 16 Jan 13 09:14 pycodestyle -> pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 984 Jan 13 09:14 pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.8 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.9

which, is more or less what I'd expect, is it not?

Yes, but only if I call the ln command **inside this folder**.

Nope: --8<---------------cut here---------------start------------->8--- ❯ mkdir -p /tmp/foo && touch /tmp/foo/bar && ln -sf bar /tmp/foo/baz

❯ ll /tmp/foo/ total 0 -rw-r--r--. 1 dan dan 0 Jan 13 10:18 bar lrwxrwxrwx. 1 dan dan 3 Jan 13 10:18 baz -> bar --8<---------------cut here---------------end--------------->8---

As stated at the end of my last mail, that is a behaviour I did not know ln had (and that is not obvious in the manpages).

...

...
So, that part seems solved. I still do not understand the packaging error for /usr/bin/_current_flavor if I create the link manually inside the directory:

%python_clone %{buildroot}%{_bindir}/pycodestyle cd %{buildroot}%{_bindir}/ln -sf pycodestyle-%{python3_bin_suffix} pycodestyle

This is due to the python flavor switching magic which is performed by writing the current python flavor into the file _current_flavor. The macros assume that the switching code is never executed inside %buildroot and so littering pwd with additional files is not an issue. It becomes one if you cd into %{buildroot} of course.

Ah, that explains it. If I switch the working directory back from %{buildroot}%{_bindir} before the %python_expand macro call at the end of the %build section, then the file does not appear. Thanks, Dan! Have a nice day, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Ben Greiner

10:45

New subject: Solved (was: Puzzled by a line in a python spec file: Why does this work?)

Am 13.01.23 um 10:32 schrieb Johannes Kastl:

...

Thanks for your patience, Dan!

On 13.01.23 at 10:22 Dan Čermák wrote:

...
Johannes Kastl writes:

...
On 13.01.23 at 09:19 Dan Čermák wrote:

...
and this is how it looks after the ln:

[ 11s] lrwxrwxrwx. 1 abuild abuild 16 Jan 13 09:14 pycodestyle -> pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 984 Jan 13 09:14 pycodestyle-3.10 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.8 [ 11s] -rwxr-xr-x. 1 abuild abuild 983 Jan 13 09:14 pycodestyle-3.9

which, is more or less what I'd expect, is it not?

Yes, but only if I call the ln command **inside this folder**.

Nope: --8<---------------cut here---------------start------------->8--- ❯ mkdir -p /tmp/foo && touch /tmp/foo/bar && ln -sf bar /tmp/foo/baz

❯ ll /tmp/foo/ total 0 -rw-r--r--. 1 dan dan 0 Jan 13 10:18 bar lrwxrwxrwx. 1 dan dan 3 Jan 13 10:18 baz -> bar --8<---------------cut here---------------end--------------->8---

As stated at the end of my last mail, that is a behaviour I did not know ln had (and that is not obvious in the manpages).

Thanks, Dan!

Have a nice day, Johannes

Hi, it seems that there was a time where the commands were cloned but not managed by update-alternatives. These lines should have been removed when switching to alternatives, but were not (that SR was by me): https://build.opensuse.org/request/show/805552 Fix: https://build.opensuse.org/request/show/1058199 `%python_clone -a` takes care of the necessary files and the correct link is created in the %post scriptlet. And %python_alternative creates the correct %ghost entry. Regards, Ben

467

Age (days ago)

467

Last active (days ago)

List overview

Download

7 comments

3 participants

participants (3)

Ben Greiner
Dan Čermák
Johannes Kastl

Puzzled by a line in a python spec file: Why does this work?

tags

participants (3)