Forum OpenACS Development: Wrong path for interpreters on openacs scripts

1: Wrong path for interpreters on openacs scripts

Posted by Héctor Romojaro on 02/28/08 02:51 PM

Hi,

Making tests of building a debian package of openacs, I realized there are errors on the location of the interpreter in some scripts. I can change them in local to build the package, but if the goal is to follow FHS, maybe they should be changed in cvs. What do you think about?

Next is the list of files with the changes proposed.

etc/deploy.sh (#!/bin/bin/tclsh => #!/usr/bin/tclsh)
packages/acs-core-docs/www/files/restart-aolserver-daemontools.txt (#!/usr/sh => #!/bin/sh)
bin/ad-context-server.pl (#!/usr/local/bin/perl => #!/usr/bin/perl)
bin/create-sql-drop-file.pl (#!/usr/local/bin/perl => #!/usr/bin/perl)
bin/data-dictionary-diff.pl (#!/usr/local/bin/perl => #!/usr/bin/perl)
bin/encode64.pl (#!/usr/local/bin/perl => #!/usr/bin/perl)
bin/plsql-diff.pl (#!/usr/local/bin/perl => #!/usr/bin/perl)
bin/triggers-diff.pl (#!/usr/local/bin/perl => #!/usr/bin/perl)

Regards,

Héctor Romojaro

2: Re: Wrong path for interpreters on openacs scripts (response to 1)

Posted by Emmanuelle Raffenne on 03/01/08 09:58 PM

Hi Héctor,

I'd say go ahead and edit them if they're wrong. If you don't have a CVS account, email OCT to ask for one.

Thanks.

3: Re: Wrong path for interpreters on openacs scripts (response to 1)

Posted by Malte Sussdorff on 03/06/08 07:41 AM

While you are at it, is our general way of installing FHS compliant? I mean storing the files in /var/lib/aolserver probably is, but should we store the configurations in /etc/aolserver?

I'm not keen on changing my beloved location of files, but when you build the package for Debian I was wondering if there is need for adaptation.

4: Re: Res: Re: Wrong path for interpreters on openacs scripts (response to 3)

Posted by Héctor Romojaro on 03/06/08 11:37 AM

Hi Malte,

I'm following the Debian policy for webapps as a guide of where to store the files, and those are the correct places:

/usr/share/(openacs|dotlrn): the application itself.
/var/log/aolserver4/(openacs|dotlrn): log files.
/etc/(openacs|dotlrn): config files.
/etc/init.d/(openacs|dotlrn): the init script (based on aolserver one).

I have not decided where to put content repository files yet (maybe at /var/lib/(openacs|dotlrn)).

BTW, I realized that there are lots of files that doesn't look like config files in etc/ openacs directory, like the install directory and the daemontools... Should not they be moved to another place, like openacs/bin/install or openacs/install (in the install directory case)?

5: Re: Wrong path for interpreters on openacs scripts (response to 3)

Posted by Stefan Sobernig on 03/06/08 11:53 AM

Malte,

I'm not keen on changing my beloved location of files, but when you build the package for Debian I was wondering if there is need for adaptation.

There is not necessarily the need to adapt the OpenACS distribution/ file system per se. That's why there is packaging logic for Debian (dpkg-*) and all the other flavours that allows to separate these two concerns. From my experience, a formal packaging process always leads to clean-up in upstream.

However, I would definitely not align OpenACS to a single what-so-ever distribution of hosting platform, e.g. Debian file system layout or Debian Policy layouts.

6: Re: Wrong path for interpreters on openacs scripts (response to 5)

Posted by Malte Sussdorff on 03/07/08 09:56 AM

Okay, but this means that we have the default OpenACS layout as per documentation. Then we have a special layout if the package was installed on Debian using the package Hector is building. Yet, when someone installed it on Debian using the installation instructions it looks like default OpenACS.

Then again on Solaris or RedHat we would have other locations where OpenACS sites are installed? Brrr..... but that's maybe only me as I usually have to figure out first where on the server OpenACS is installed when I'm asked to consult.

7: Re: Wrong path for interpreters on openacs scripts (response to 1)

Posted by Christian Brechbuehler on 03/26/08 03:15 AM

For the path of interpreters, using env is more portable, e.g.,

#!/usr/bin/env perl

Some people have /usr/local/bin/perl, others have /usr/bin/perl, but env finds any on the path. (Don't know if that's FHS compliant.) Known drawbacks: If you keep several versions installed and want a specific one, this may not work. Specifically with perl, you can't use the "-w" option; must "use warnings".