hello,
in my private code stash I now have the following RPM macro:
# (d)rop shebang (interpreter) line: %update_shebang -d <files...> # (s)et shebang (interpreter) line to /usr/bin/foo: %update_shebang -s /usr/bin/foo <files...>
This is useful for python, but i don't want to put this in python-rpm-macros because it is going to be useful for other packages and languages as well.
Instead I'd prefer to put this into /etc/rpm/macros.shebang, or /usr/lib/rpm/macros.d/macros.shebang (which of the two is preferred these days btw?) But I'm faced with the question of how to package it. ISTM this should be part of the default build environment. If we need a BuildRequires: shebang-macros, we can as well stick with adhoc "sed" invocations in every package. So i'd create the shebang-macros package and add it as Requires for ... what? rpm-build? rpm itself? Maybe instead add the macro to rpm and push upstream? This fully implicit installation won't be portable to other distros though. What then, invoke the macros always as %{?update_shebang:%update_shebang -d} ? That seems stupid.
Maybe I'd keep it as a requirement to python-rpm-macros, and other potential users (perl, ruby) can add it as a requirement to their respective macro sets too?
what do you folks think?
m.
On Monday 2017-09-11 15:56, jan matejek wrote:
Instead I'd prefer to put this into /etc/rpm/macros.shebang, or /usr/lib/rpm/macros.d/macros.shebang (which of the two is preferred these days btw?)
/usr is for everything shipped. /etc is for host-specific configuration.
But I'm faced with the question of how to package it. ISTM this should be part of the default build environment. If we need a BuildRequires: shebang-macros, we can as well stick with adhoc "sed" invocations in every package. So i'd create the shebang-macros package and add it as Requires for ... what? rpm-build? rpm itself? Maybe instead add the macro to rpm and push upstream?
osc meta prjconf -e Add it there, like sed is.
This fully implicit installation won't be portable to other distros though. What then, invoke the macros always as %{?update_shebang:%update_shebang -d} ? That seems stupid.
Make other distros ship the macros? Contribute them to rpm upstream?
* Jan Engelhardt (jengelh@inai.de) [20170911 16:20]:
/usr is for everything shipped. /etc is for host-specific configuration.
Wrong, new macros are supposed to go to /etc/rpm/macros.<name>
Philipp
On Wednesday 2017-09-13 10:24, Philipp Thomas wrote:
- Jan Engelhardt (jengelh@inai.de) [20170911 16:20]:
/usr is for everything shipped. /etc is for host-specific configuration.
Wrong, new macros are supposed to go to /etc/rpm/macros.<name>
You must be new here.
* Jan Engelhardt (jengelh@inai.de) [20170913 10:25]:
You must be new here.
Very funny telling that to someone dealing with SUSE Linux since about 1996. Have a look into /etc/rpm and tell me what you see.
Philipp
On Wednesday 2017-09-13 10:29, Philipp Thomas wrote:
- Jan Engelhardt (jengelh@inai.de) [20170913 10:25]:
You must be new here.
Very funny telling that to someone dealing with SUSE Linux since about 1996. Have a look into /etc/rpm and tell me what you see.
Old historic artifacts. Go with the times!
10:33 a4:~ > rpm -qf /usr/lib/rpm/macros.d/macros.ninja ninja-1.8.1-1.1.x86_64 10:33 a4:~ > rpm --eval '%ninja_build'
/usr/bin/ninja -v -j12