Description of problem: When upgrading from f23->f24, f23 glusterfs-libs postun scriptlet failed Cleanup : glusterfs-libs-3.7.8-1.fc23.x86_64 2985/3742 /sbin/ldconfig: relative path `1' used to build cache warning: %postun(glusterfs-libs-3.7.8-1.fc23.x86_64) scriptlet failed, exit status 1 Non-fatal POSTUN scriptlet failure in rpm package glusterfs-libs Non-fatal POSTUN scriptlet failure in rpm package glusterfs-libs Not sure how important this is, or is it fixed already, I see in package git this new releases have changes to calls for ldconfig in package scritptlets, but I don't know how this works. If this is already fixed, or can be ignored, please close the bug, and sorry for the noise. Version-Release number of selected component (if applicable): libs-3.7.8-1.fc23.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This was fixed with upstream bug 1145989, change http://review.gluster.org/8835 and needs to be included in the glusterfs.spec for Fedora.
Change pushed to the master branch (for Rawhide) and f24.
glusterfs-3.7.8-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f974e3a4d8
glusterfs-3.7.8-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f974e3a4d8
glusterfs-3.7.8-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
While this does fix the immediate problem, it introduces another: now all packages are missing the necessary scriptlet dependencies on ldconfig. The root cause of the issue is the attempt to use comment blocks with lines starting with #'s, and specifically the last one between %postun libs and %files caused the failure. # is not really a comment character in specfile syntax. Removing all of them, or at least the following attempted comment between %postun libs and %files would have been the better fix. The other alternative is to sprinkle a bunch of manual "Requires(something): /sbin/ldconfig"s where necessary. ##----------------------------------------------------------------------------- ## All %%files should be placed here and keep them sorted by groups ##
http://www.rpm.org/max-rpm/ch-rpm-inside.html and https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-specfile-syntax.html would seem to suggest that # is a comment character in specfile syntax. Why do you say it's not?
(In reply to Kaleb KEITHLEY from comment #7) > would seem to suggest that # is a comment character in specfile syntax. > > Why do you say it's not? I trust the word of the rpm maintainers, and experience. There are numerous examples to be found here and there where they state it very clearly, for example bug 1095408 comment 2. And not only I trust the maintainers, I trust my eyes. If # would be a real comment character everywhere, then it would be really ignored and not cause this particular problem, and would not end up in the content of the %postun script which caused this failure. $ rpm -qp --scripts http://kojipkgs.fedoraproject.org//packages/glusterfs/3.7.8/1.fc25/x86_64/glusterfs-libs-3.7.8-1.fc25.x86_64.rpm postinstall program: /sbin/ldconfig postuninstall scriptlet (using /sbin/ldconfig): ##----------------------------------------------------------------------------- ## All %files should be placed here and keep them sorted by groups ##
1) The _official_ documentation says # is a comment. As developers, when we need answers, we can't be expected to hunt down things like "...the word of rpm maintainers and random people's experience..." We turn to the official documentation and rely on that being accurate. The ISO C language spec has a section called the Rationale, The Rationale is the words of the maintainers and their experience; it is not the C language definition. If you quote the Rationale as justification for something, you'll be told that the Rationale is not the Standard. Likewise here, the official documentation is what I consider definitive. 2) If too much text is copied to a scriptlet file from the .spec, including # comments in the .spec, at least in bash and /bin/sh scripts # lines are also comments, and are, thus, harmless. 3) you seem to be specifically concerned with the apparent %files in the comment following the %postun libs line in the glusterfs.spec, and cite https://bugzilla.redhat.com/show_bug.cgi?id=1095408#c2, which speaks to the expansion of macros in comments. That comment also includes advice that such macros may be escaped by the use of %%, and if you had bothered to check the glusterfs.spec file in Fedora dist-git (http://pkgs.fedoraproject.org/cgit/rpms/glusterfs.git/tree/glusterfs.spec), you'd have seen that – in fact – the comment has %%files (and has for quite a while now), and what you are seeing in your `rpm -qp ...` example is the result. The harmless result. 4) In bz 1095408 Lucas asked – repeatedly – where this fact (macros expanded even in comments) is documented, which Panu ignored and merely kicked the can down the street by indicating that he no longer works on rpm. So it's still not documented anywhere, right?
1) Official/unofficial aside, there is no up to date, accurate documentation with good coverage available. The best source these days are the folks that work or have worked on rpm, and experienced community members. 2) It is harmless when passed to e.g. a shell. That does not make it a comment character in rpm specfile syntax. And it certainly is not generally harmless either, which is what this bug and the end of my comment 8 clearly shows. See the next point. 3) You're misunderstanding me entirely. The content of the scriptlet passed to /sbin/ldconfig does not matter, and my point has nothing to do with how many % characters there are in it (and yes, I have bothered to read the glusterfs specfile). The point is that there *is* content in the first place. If # was really a comment character in specfile syntax, there probably would not be. ldconfig fails no matter what the content is, because it simply does not take any files as arguments that way. $ touch 1 $ ldconfig 1 ldconfig: relative path `1' used to build cache $ echo $? 1 In this example I showed the problem using an empty file. The stuff you call "The harmless result" could have just as well been used as the content of the file. It causes ldconfig to fail exactly the same way. Not harmless. 4) Is continuation of the misunderstanding. You asked me why I think # is not a comment, and I cited the first ref based on a quick web search I found from someone who has worked on rpm for a long time. That cite says "what looks like a comment (but is not in all contexts)", and the "what" there is #.
1) Kaleb *is* an experienced community member. Your argument is specious. 2) Your comment 8 *does* show it being harmless. 3) There is no content being passed to ldconfig. 4) That line does not say that "#" is not a comment, but rather that under some circumstances it might not be. It's completely irrelevant. Scriptlets are run in the default shell. You can assume that the default shell (/bin/sh) is bash. The contents of the postun end up being one command and three lines of comments. Comments that are irrelevant, sure, but there's no harm in them being there. I'm still trying to figure out what "now all packages are missing the necessary scriptlet dependencies on ldconfig" means. Scriptlet dependencies? Are you suggesting there's a needed requirement for ldconfig? That's part of glibc and is to be assumed installed.
(In reply to Joe Julian from comment #11) > 2) Your comment 8 *does* show it being harmless. No, it does not. > 3) There is no content being passed to ldconfig. Yes, there is. The content you are calling "harmless". My comment 8 shows the content. Don't believe me? Download the rpm, and run "rpm -qp --scripts" on it, and rpm _shows you the content_ it ends up passing to ldconfig. > 4) That line does not say that "#" is not a comment, but rather that under > some circumstances it might not be. It's completely irrelevant. The "some circumstances" is exactly the circumstance in this bug. It is the cause of the original bug here. To be clear, with all of the above I am talking about the glusterfs-libs 3.7.8-1.fc25 package, i.e. the one that had the "-p /sbin/ldconfig" calls. > Are you suggesting there's a needed requirement for ldconfig? That's part of > glibc and is to be assumed installed. It's not always that simple. A transaction might be installing both glusterfs-libs and glibc for the first time (e.g. initial installation), and in that case it is needed for getting the order of installation right.
I apologize. I was reading this conversation against a more recent commit in gerrit where the -p.*$ had already been removed and the scriptlet was, indeed, running under the default shell. That's why I was so confused about the controversy.
Fixed in glusterfs-3.7.8-4. While the comment lines do still appear in `rpm -qp --scripts glusterfs-libs-3.7.8-4.x86_64.rpm, ldconfig runs correctly and successfully. I.e. it does not exit with an error nor does it output the "/sbin/ldconfig: relative path `1' used to build cache" message (only seen when run with -vv command line option or in strace -f. This is true for all the sub-packages with %post and %postun scriptlets. setting Status to ON_QA for now, please close at your convenience.
glusterfs-3.7.8-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9a67b32a72
glusterfs-3.7.8-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9a67b32a72
glusterfs-3.7.8-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.