scripts without she-bang in /usr/lib/packagename/

Toshio Kuratomi a.badger at gmail.com
Thu Nov 17 17:53:14 UTC 2011


On Thu, Nov 17, 2011 at 12:26:13PM -0500, Paul Wouters wrote:
> 
> I have a package that contains ruby scripts in /usr/lib/packagename/
> 
> These scripts are only called/included via other binaries.
> 
> If I do not make these executable, then rpmlint complains about
> non-executable content in /usr/lib/packagename/ and suggests I
> move it to /usr/share/packagename. If I make them executable, then it
> complains about missing she-bang.
> 
> upstream thinks there is no problem and says the scripts should never
> be executed on their own, so no she-bang should be there. Fedora does
> not allow executing from /usr/share.
> 
> Should I just ignore rpmlint for this case?
> 
When you talk about scripts, do you mean that the code calling these scripts
does the equivalent of this (note, I generated my examples by reading up on
ruby on the web just prior to posting... please allow for this perhaps not
being real ruby code :-))::

  system('/usr/lib/packagename/foo.rb')

or this::

  require '/usr/lib/packagename/foo.rb'

  Foo::run()

or this::

  system('/usr/bin/ruby /usr/lib/packagename/foo.rb')

The first example needs a shebang.  The second example should be mode 0644
and you could place them in /usr/share/packagename/.  The third example is
in a grey area since it's "data of the ruby interpreter" and can be mode
0644 but it's really not functionally different from the first example.  I'd
say that based on upstream's assertion it's probably best to move it to
/usr/share/packagename, mode 0644, no she-bang. (But in this case "best" is
an ideal and there's room for you to make a case for treating it as one of
the other two cases as well).

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111117/62f09f7b/attachment.bin 


More information about the devel mailing list