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)

Héctor Romojaro

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.

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.

#!/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".