This is something I have been giving some thought to. I don't think we are
running in different directions with this. Here are some quick
thoughts/nitpicks in line though ;-)
On Sun, Feb 26, 2012 at 11:59 AM, Michael Richardson <[email protected]>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
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
