On Sun, Feb 26, 2012 at 11:59 AM, Michael Richardson
<..hidden..> wrote:
The various packagers (RPM and DEB) are currently moving a number of
files out of . of the package, which usually becomes /usr/share/ledgersmb,
with the web server pointing at it.
This currently causes some issues and in fact there have been bugs in LedgerSMB exposed due to this process. The move of templates is a big one but that is corrected for 1.3.11 or 1.3.12 (will have to check changelog again to be sure which one).
There are also issues (also present in the DEB) which doesn't properly configure directories where stuff is moved..... Not that it would have mattered before a recent bugfix though.
The other files move elsewhere, usually /usr/share/doc/ledgersmb.
What does not get moved, which could be moved is the LedgerSMB directory
full of .pm files, which could be reached by Perl search path.
My proposal is to move all of the wrapper .pl files out of the root
directory into a directory which could be called "htdocs" or something
like this.
I think Erik has been suggesting moving all the Perl files into a src directory. I don't see that happening before 1.4 because it would make svn merging a big of an additional pain, but I like that idea. The current directory structure is in fact very developer friendly, and I am not sure I want to force a lot of hacks in that way to deal with it. So I don't foresee the specifics here being accepted.
However, I think the problem you are trying to solve is a real and a valid one. I just think we can solve it without making it hard for me to run 1.2, 1.3, and 1.4 in parallel at the same time.
Here is my suggestion, which is to focus on tweaking the make process rather than the current file structure:
1) Tweak the Makefile.PL so that make install ONLY installs the LedgerSMB.pm, and the files in the LedgerSMB directory.
2) Create a separate make install webapp target which accepts a directory in some way and allows you to install/configure the web app in a directory of your choice. This would copy the top level .pl files, the bin/* files and the UI directory. Note that scripts/* is moved into LedgerSMB/Scripts for 1.4 so that would all go into somewhere in $ENV{PERLLIB}
Long-run, the ideal thing would be to get rid of all the files that go into the web app directory except for a single request handler.
Now, almost all of the real functionality is now in the bin/ directory,
and this would be among the things that could go somewhere else when
installed, rather than being under DocumentRoot.
I don't see us doing this with the bin/ scripts. Sorry. The reason is that these are big scripts that came from SQL-Ledger and they are pretty brittle. I would not be surprised if moving them around would cause weird things to break in non-obvious ways. Each major release is seeing good size chunks of code pulled out of bin and we want to keep that up.
If we want to keep the ability for people to tar xzf into /var/www,
then we might want to have a script that creates a series of symlinks,
but we should instead encourage users to change their DocumentRoot.
(Perhaps it is supported right now to point at bin/)
My thinking is:
1) Keep things as they are for directory structure and allow a make test run on this. This allows for a developer to install several major versions concurrently, which is the strength of the current approach.
2) Support a make install-based approach. Right now make install creates significant supportability issues. However, if we allow one to make install, it could be downloaded into a user's home directory, and built from there. Then the minimal files could be copied into the web app directory specified (either in DocumentRoot or somewhere else).
My reasons for suggesting this are twofold:
1) depth-in-security: misconfigured web servers can not allow writing
to things they can not see.
I am not quite sure I understand your concern here.
2) to make unit testing a bit more obvious.
I'd rather not pollute DocumentRoot accessible directory with even
more things that a web server could do the wrong thing with. In
particular, I've been working on some testing where one needs to
import different databases, and then do things.
Want some more benefits to add to your list?
Here's a big one:
Right now the LedgerSMB logic only works for web apps, but we are putting a lot of effort into trying to ensure that you could build GUI's for it also. The current core logic has a bit of a problem in that the way it is installed only works for a web app and if you make install, that causes supportability issues. I think getting this sort of thing working for 1.4 needs to be a priority.
Best Wishes,
Chris Travers