Description of problem: rpmdiff reports syntax errors for a few files: /opt/rh/postgresql92/root/usr/bin/pltcl_delmod /opt/rh/postgresql92/root/usr/bin/pltcl_listmod /opt/rh/postgresql92/root/usr/bin/pltcl_loadmod this is because it treats them as shell scripts while in fact they are tcl scripts, but rpmdiff cannot tell as they are using /bin/sh shebang I believe there is no reason to obfuscate the script language this way ... Version-Release number of selected component (if applicable): postgresql92-postgresql-pltcl-9.2.10-2.el6 How reproducible: always Steps to Reproduce: 1. head -n 5 /opt/rh/postgresql92/root/usr/bin/pltcl_delmod Actual results: #! /bin/sh # src/pl/tcl/modules/pltcl_delmod.in # # Start tclsh \ exec /usr/bin/tclsh "$0" "$@" Expected results: #! /usr/bin/tclsh ... Additional info:
Created attachment 1000903 [details] change shebang to /bin/tclsh Attached patch should fix the issue. I am not sure about background of tcl in postgresql. The change may potentiality harm existing user modules. I have asked on impact of this change at upstream mailing list. See http://www.postgresql.org/message-id/1426155421.2535.11.camel@redhat.com
(In reply to Jozef Mlich from comment #2) > The change may potentiality harm existing user modules. pardon my ignorance, but could you shed some light on this, what do you mean, how the scripts could depend on this? > I have asked on impact of this change at upstream mailing list. See > http://www.postgresql.org/message-id/1426155421.2535.11.camel@redhat.com fine, let's what upstream has to say about that note that at first I thought this is Red Hat specific due to hardcoded paths, I haven't realized these are macros expanded during build, so maybe on some other systems it could mean to execute 'tclsh' from the search path, not hardcoding the directory, but in that case, I guess using #!/usr/bin/env tclsh would be more portable (except for OpenServer 5.0.6 and Unicos 9.0.2 :-)) (https://en.wikipedia.org/wiki/Shebang_(Unix)#Portability)
(In reply to Karel Volný from comment #0) > Description of problem: > rpmdiff reports syntax errors for a few files: > /opt/rh/postgresql92/root/usr/bin/pltcl_delmod > /opt/rh/postgresql92/root/usr/bin/pltcl_listmod > /opt/rh/postgresql92/root/usr/bin/pltcl_loadmod This is known problem of rpmdiff. Feel free to ignore this FP. > this is because it treats them as shell scripts while in fact they are tcl > scripts, but rpmdiff cannot tell as they are using /bin/sh shebang The origin of this technique is probably http://wiki.tcl.tk/708 > I believe there is no reason to obfuscate the script language this way ... ... and fixing it is worthless (and definitely in RHEL/RHSCL packages). I'm not a expert, but I tend to say its not obfuscation (meaning that it beats readability) but rather known tcl coding style. (In reply to Karel Volný from comment #3) > > I have asked on impact of this change at upstream mailing list. See > > http://www.postgresql.org/message-id/1426155421.2535.11.camel@redhat.com > > fine, let's what upstream has to say about that And then switch this against Fedora Rawhide please. > note that at first I thought this is Red Hat specific due to hardcoded > paths, I haven't realized these are macros expanded during build, so maybe > on some other systems it could mean to execute 'tclsh' from the search path, > not hardcoding the directory, but in that case, I guess using > > #!/usr/bin/env tclsh > > would be more portable (except for OpenServer 5.0.6 and Unicos 9.0.2 :-)) > (https://en.wikipedia.org/wiki/Shebang_(Unix)#Portability) Why do you think that /usr/bin/env is _more_ portable? Pavel
Here is a reply from Tom Lane in postgresql-hackers mailinglist: http://www.postgresql.org/message-id/10747.1426168649@sss.pgh.pa.us > That is the time-honored standard formatting for tcl scripts, see for > example page 2 here: > http://www.tcl.tk/doc/styleGuide.pdf > While we might get away with ignoring that convention for this specific > use-case, it carries a risk of breaking things, eg for people who have > multiple Tcl installations. I'm disinclined to change it, especially > not if the reason is "rpmdiff is too dumb to recognize tcl scripts". > Somebody's gonna need to fix that anyway. In my opinion we should stay close to the upstream in this case.