Ben

I'm happy to help out with this one, if we can get it moving to a quick fix.

Thanks,

Jamie Duncan

Moving to the Packager's Guide.

I've added a patch to the RPM Guide to add that clarification.  The new information should be part of git commit cc44b49e0977e4f50ae09f48b15b8367c59331de.  The new information should show up in the guide the next time the document is rebuilt.

Just as an FYI, the RPM Guide is fairly old and not being actively maintained like it should be.  There's a new effort underway to take the most important information from the RPM Guide and build a Packager's Guide, but that guide doesn't yet go into any detail on scripts.  Petr Kovar reassigned this bug to him, so hopefully he'll add something to the Packager's Guide about scriptlets.

Thanks for adding the patch.

Why was the decision made to create a new guide rather than just renaming or updating the old guide?

Also, wouldn't it make more sense to start by documenting the spec file syntax/"language" as part of the rpm-build rpm?  It seems like the problem is that there's a tool, rpmbuild, that processes a syntax, spec files, that isn't documented or standardized.

In my mind, a "guide" is high level documentation that is very nice to have, but should be based on my low level documentation.  The low level documentation for the tool, rpmbuild, exists, but we're missing the low level documentation for what the tool processes, spec files.

Just some thoughts.  Thanks for the help.

(In reply to daniel.neuberger from comment #4)
> Thanks for adding the patch.

You're most welcome.

> Why was the decision made to create a new guide rather than just renaming or
> updating the old guide?

In short, for a couple of reasons.  The first reason is that the exiting guide is a bit overwhelming to new packagers, and we really wanted to have a guide focused on helping novice packagers get up to speed.

The second reason is the simple fact that updating the existing guide would be an enormous undertaking, and nobody has volunteered to step up and do the work.  There's nothing that says we can't have two guides, we just need help to do the work.

> Also, wouldn't it make more sense to start by documenting the spec file
> syntax/"language" as part of the rpm-build rpm?  It seems like the problem
> is that there's a tool, rpmbuild, that processes a syntax, spec files, that
> isn't documented or standardized.

It makes sense to me, but I'm just a volunteer, and I don't have either the time or inclination to dive into documenting every detail at that level.  Until someone volunteers to do the work or gets asked to do it as part of their day job, it's just wishes and dreams.  

One of the unfortunate truths is that writing documentation isn't sexy, and in open source communities, it often doesn't get the attention that developing new code does.  As with everything else in open source, we either have to scratch the itch ourselves, pay someone to scratch it for us, or find a way to convince someone else that it's their itch.

Thanks Jared for all the info.  Unfortunately, I can't undertake the complete task myself either (at least not right now).  I will do my best to help push things in the right direction and contribute bits and pieces as I go along with my work.

The Fedora packager guide has been deprecated in favor of https://github.com/redhat-developer/rpm-packaging-guide/.

Moving this bug to the RHEL version of redhat-developer/rpm-packaging-guide to investigate if this still is a relevant issue.

The most common example for -p is with ldconfig:
  https://fedoraproject.org/wiki/Packaging:Scriptlets#Linker_Configuration_Files

But... we are trying to get rid of this in recent Fedora (and *this one* is not needed), so I would rather choose some different example.

Hmm I would propose this wordings:

The scripts support a special flag, -p, which allows the scriptlet to invoke a particular interpreter instead of the default -p /bin/sh. If you use bashisms in a scriptlet, it would be prudent to specify -p /bin/bash.

You can specify any interpreter `%post -p /usr/bin/python3` and write your script in python3. Just do not forget to specify it as dependecy: `Requires(post): python3`. 

You can use `%post -p <lua>` and then write your script in lua, which is embeded directly into rpm. This is in fact your only choice if you are going to write %pretrans script, because when installing system from scratch there is not even bash when transaction starts.

The -p option may also be used to invoke one program directly without the shell indirection, e.g. by using %post -p /sbin/ldconfig. 

The scriptlets also take an argument, passed into them by the controlling rpmbuild process. This argument, accessed via $1, is the number of packages of this name which will be left on the system when the action completes, except for %pretrans and %posttrans, which are always run with $1 set to 0. (%pretrans and %posttrans are available in rpm 4.4 and later). So, for the common case of install, upgrade, and uninstall, we have:

	install 	upgrade 	uninstall
 %pretrans 	$1 == 0 	$1 == 0 	(N/A)
 %pre 	$1 == 1 	$1 == 2 	(N/A)
 %post 	$1 == 1 	$1 == 2 	(N/A)
 %preun 	(N/A) 	$1 == 1 	$1 == 0
 %postun 	(N/A) 	$1 == 1 	$1 == 0
 %posttrans 	$1 == 0 	$1 == 0 	(N/A)

Hello Miroslav,

thank you for very useful explanation.

Could you please send me an example of simple script written in python3 which is commonly used with -p /usr/bin/python3? I will make a whole chapter about -p around this example.

Thank you!

It is definitely not used commonly. There are some cases. E.g., https://stackoverflow.com/questions/50137854/python-behaves-differently-giving-unwanted-extra-string-when-executed-via-rpm-sp
But this is very rare. Yet, we should mention it.
I recommend to use a just artificial example:

%post -p /usr/bin/python3
print("This is {} code".format("python"))

New chapter submitted in a pull request:
https://github.com/redhat-developer/rpm-packaging-guide/pull/46

New chapter merged in master branch. Pull request closed. 
https://github.com/redhat-developer/rpm-packaging-guide/pull/46

New chapter published. As 6.4.2.1. with a title: Using Non-Shell Scripts in spec File. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/rpm_packaging_guide/advanced-topics#triggers-and-scriptlets