Chris,
On Wed, 10 Aug 2011 21:23:11 -0700, Chris Travers wrote: > On Wed, Aug 10, 2011 at 2:59 PM, Neon <[email protected]> wrote: >>> I would be interested in testing it out - I have had other >>> things to >>> deal with for a while but I want to get back to this >>> soon. >> I think (as Matt suggested) I'll try to post it on the devel list. >> Will you get it there? Subscribed. >>> Ideally, it >>> would be good if we could package it into an RPM. >> True, to a certain extent. An RPM would allow the dependencies to >> get automatically loaded onto the system (through YUM) (except for >> those I had to go to CPAN for). And, if maintained, might get packaged >> into the distro itself (with all sorts of help making those CPAN >> dependancies also get into the distro). The main hassle for me in the past every time I have looked at the install is that I have tried to install all the appropriate Perl RPMs so that I don't need to do a CPAN install (which is not nice - I want to minimise non-RPM installs). I have always been, eventually, unsuccessful and had to fall back to CPAN. > Have you tried the RPM for 1.2.24? If there are bugs at the > installation there we can fix that or tweak the spec file to include > anything additional we need to be doing or provide scripts for things > that can't go into the rpm installation itself. I haven't but since the one company that I really used v1.2 for no longer exists, I am not interested in going back to v1.2 . >> But I think it would have limited use with a working-out-of-box >> LSMB. It was a bit of a hassle getting things right (mostly within >> Postgre, not so much with apache or the OS) > > This is not something we can really do in the rpm for a number of > reasons. The big issue is we want to play nicely with other apps. What do you mean? Why should creating an RPM be unfriendly? - it should be the opposite for other apps . . > What I am thinking about for 1.3 is to break things up into two > RPM's, > one for the db and one for the web app. This would allow us to > install the db server if necessary as well as command-line tools for > setting up the db That would suit me - I use PG heavily for other things and would always have it already installed. >> It would be nice to edit some config files within LSMB so that we >> don't have to worry about getting the right database, or the right >> host, or whatever, whenever we set up the datasets and users. It >> seemed to me that those things are going to be always unchanged (or at >> least default) after they're set up on the user's machine. Being able >> to set those from the setup means it's less error-prone during usage >> and there's less instructions for the end-user to fiddle with. > > In 1.3, one lsmb app has to hit one set of host/port. The users are > set up for the most part within the application itself. PG was never really an issue for me . . mostly Perl . . Thanks, Phil. > Best Wishes, > Chris Travers > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. > http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Ledger-smb-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ledger-smb-users -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: [email protected] ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
