Bug 1315024

REVIEW: http://review.gluster.org/13613 (packaging: postun scriptlet fail /sbin/ldconfig: relative path `1') posted (#1) for review on master by Kaleb KEITHLEY (kkeithle)

(In reply to Vijay Bellur from comment #1)
> REVIEW: http://review.gluster.org/13613

Related to this, the end of a scriptlet body is the start of another, or another section such as %files (ignoring empty lines).

In the Fedora docs, "exit 0" is not a pattern for ensuring where a script ends, it is there for ensuring zero exit status from the script, more about that in https://fedoraproject.org/wiki/Packaging:Scriptlets

Preventing non-zero exit status pretty much at all costs was necessary some 10 years ago, and I'm fairly confident that it is no longer so if an actual error for which it is good to notify users occurs. No use in letting harmless non-zero exit statuses through though. The "Non-zero exit codes from scriptlets break..." chapter in the above packaging doc is outdated, I'll file a bug for removing it.

(In reply to Ville Skyttä from comment #2)
> I'll file a bug for removing it.

Looks like %pre is still something to pay special attention to, but otherwise the info seems outdated indeed. https://fedorahosted.org/fpc/ticket/606

(In reply to Ville Skyttä from comment #2)
> (In reply to Vijay Bellur from comment #1)
> > REVIEW: http://review.gluster.org/13613
> 
> Related to this, the end of a scriptlet body is the start of another, or
> another section such as %files (ignoring empty lines).
> 
> In the Fedora docs, "exit 0" is not a pattern for ensuring where a script
> ends, it is there for ensuring zero exit status from the script, more about
> that in https://fedoraproject.org/wiki/Packaging:Scriptlets

And nothing I wrote says that I expect it to determine where the scriptlet ends. I.e. where rpm/rpmbuild stops copying the scriptlet.

It is, exactly as I wrote, simply a way to ensure that the script exits reliably, where it is expected to exit; regardless of how much of the scriptlet was copied.

REVIEW: http://review.gluster.org/13613 (packaging: postun scriptlet fail /sbin/ldconfig: relative path `1') posted (#2) for review on master by Kaleb KEITHLEY (kkeithle)

REVIEW: http://review.gluster.org/13613 (packaging: rpm scriptlet cleanup, handle -p /sbin/ldconfig) posted (#3) for review on master by Kaleb KEITHLEY (kkeithle)

REVIEW: http://review.gluster.org/13613 (packaging: rpm scriptlet cleanup, handle -p /sbin/ldconfig) posted (#4) for review on master by Kaleb KEITHLEY (kkeithle)

REVIEW: http://review.gluster.org/13613 (packaging: rpm scriptlet cleanup, handle -p /sbin/ldconfig) posted (#5) for review on master by Kaleb KEITHLEY (kkeithle)

COMMIT: http://review.gluster.org/13613 committed in master by Kaleb KEITHLEY (kkeithle) 
------
commit 5cb80ac63b17a3c34d4deef1816e1782757687d9
Author: Kaleb S KEITHLEY <kkeithle>
Date:   Sat Mar 5 16:06:18 2016 -0500

    packaging: rpm scriptlet cleanup, handle -p /sbin/ldconfig
    
    The RPM documention indicates that during an rpm install or erase, the
    script(lets): %post, %preun, and %postun (and %pre, %build, %install,
    etc.) are copied to a temp file, and then the temp file is run as a
    (/bin/sh or bash) script.
    
    Unfortunately the documentation is not clear about how rpmbuild and/or
    rpm determine where the end of any scriptlet is when it is copied to
    the file.
    
    Most things in the glusterfs.spec work correctly as is. These are the
    %preun, %post, and %postun scriptlets that are "closed" by a following
    %preun, %post, and %postun, or poetentially another scriptlet, e.g.
    %file.
    
    The ones that don't work correctly (only one actually) are those where
    there is a comment in the spec file before it is closed by another
    scriptlet. Further complicating things is that the type of scriptlet
    affects what rpm does and what `rpm -qp --scripts ...` shows.
    
    The specific one that didn't work was the "%postun libs" scriptlet. It
    is followed by a comment before being "closed" by the %files section (or
    scriptlet). It can be written two ways: "%postun libs\n/sbin/ldconfig"
    or "%postun libs -p /sbin/ldconfig" Either way it's written, `rpm -qp
    --scripts glusterfs-libs...` will include the comment lines between the
    %postun libs line and the following %files line.
    
    But the way rpm executes these depends on how they're written. If
    written as "%postun libs\n/sbin/ldconfig" rpm will simply run
    /sbin/ldconfig with no command line options, i.e.
      execve ("/sbin/ldconfig", [ "/sbin/ldconfig" ], [ ]);
    
    But when written as "%postun libs -p /sbin/ldconfig", it will copy
    the comment lines to a temp file, and pass the temp file name and "1"
     as (command line) parameters, i.e.
      execve ("/sbin/ldconfig", [ "/sbin/ldconfig", "/tmp/tmpXXXXXX", "1" ],
              [ ]);
    
    Which results in ldconfig exiting with an error. (Remember, both ways show
    the comment in `rpm -qp --scripts ...`)
    
    (Note though, that the similar "%postun api -p /sbin/ldconfig" is run
    correctly, because it is "closed" by the following "%postun server"
    scriptlet.)
    
    Finally, through trial and error, it appears that rpm can be tricked with
    a hack, and "closure" of the scriptlet forcedlike this:
    
     %postun libs -p /sbin/ldconfig
    
     %if ( 0%{?_undocumented_hack_closes_scriptlets} )
     %postun
     %endif
    
    in which case ldconfig appears to run correctly. Note also that here too
    the comment will be included in the output of `rpm -qp --scripts ...`
    But that's very ugly hack.
    
    Change-Id: I587a490ddcdf47d01605479bc8ef8b0e439108fb
    BUG: 1315024
    Signed-off-by: Kaleb S KEITHLEY <kkeithle>
    Reviewed-on: http://review.gluster.org/13613
    Smoke: Gluster Build System <jenkins.com>
    Reviewed-by: Niels de Vos <ndevos>
    NetBSD-regression: NetBSD Build System <jenkins.org>
    CentOS-regression: Gluster Build System <jenkins.com>
    Reviewed-by: Raghavendra Talur <rtalur>

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.8.0, please open a new bug report.

glusterfs-3.8.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://blog.gluster.org/2016/06/glusterfs-3-8-released/
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user