Re: Any progress with FIS GT.M?
On Mon, 02 Jul 2012, Luis Ibanez wrote:
> yeap -- all executables scripts must have shebang to guarantee proper
> environment to be chosen.
> I'm now inserting the shebang line in the "rules" file, by calling sed.
> It is not pretty, but it does the trick.
I would strongly recommend just to do these changes in upstream
repository so they become a part of upcoming fresh "orig" tarball. If
those scripts are POSIX-shell compliant (e.g. with dash which is default
/bin/sh on Debian systems) -- use #!/bin/sh. If they require bash --
#!/bin/bash (which might be a safer choice altogether).
> Note that, after the change, one of the scripts get a format warning
> from lintian. (must still track that one: +1 in my TODO list).
;-) just change in upstream sources -- any objections Amul?
> if they are to be sourced they should not be executable... we might
> altogether place them under /etc/fis-gtm/5.5.000/ since they sound like
> environment configuration files. Are they supposed to be sourced by any
> fis-gtm's script? then we might like to symlink them back under
> /usr/lib/fis-gtm/V5.5-000_x86_64/
> This is a question for Bhaskar.
> The implications escape me... :-)
there should be none (unless there is some obscure readlink -f logic
inside ;) )
> most probably. if no internal scripts/binaries rely on it to be there:
> rm after installation (in debian/rules). If they are needed -- lintian
> override is needed with a description for that
> I used the dictatorial method of deleting the COPYING file
> with an entry in the rules file. Another non-pretty solution,
> but yet one that does the trick...
that one is how I would do it -- so must be correct! ;)
> > >W: fis-gtm-5.5.000: shlib-with-executable-stack
> usr/lib/fis-gtm/V5.5-000_x86_64/libgtmshr.so
> > [amul:1] This is expected. Ignore it
> weird -- that should have been ignored since I added creation of an
> override in debian/rules... may be that old lintian did not understand
> the '*' in the file pattern... test with a fresh one
> I'll post the outputs of a fresh build.
I hope we could avoid that ;) (i.e. it would just work ;) )
> This step resets permissions to safe defaults.
> In our case, we have to override the default behavior
> of this stage, in order to prevent it from changing the
> permissions that we have set correctly in the intermediate
> installation.
> Is that right ?
sounds correct
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Reply to: