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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
