Re: Status of 1.4

[Chris Travers <..hidden..>]

A couple quick points.

On Sat, Feb 18, 2012 at 1:09 AM, Philip Rhoades <..hidden..> wrote:
> Roderick,
>
>
> On 2012-02-18 09:16, Roderick A. Anderson wrote:
>> Philip Rhoades wrote:
>> </snip>
>>> It looks like the choices are: Config::General, Config::Std, and
>>> Config::Tiny, YAML and JSON but why don't you just put the data into a
>>> PG table? - if localhost and port 5432 are not being used, then
>>> presumably the person is competent enough to change the config table
>>> appropriately and if the install was faulty or fails then the
>>> accounting is not going to work anyway so the config info is
>>> irrelevant.
>>
>> If it isn't localhost and port 5432 then how does LSMB connect to the
>> database to know which host and port to use?  :-)
>
>
> Perhaps I wasn't clear enough - in the great majority of cases,
> localhost and port 5432 will work fine and a "config.sh" or a create
> config table facility in a larger script is all that is needed.  In the
> cases where that won't work, then presumably the person who is managing
> the existing installation will be clued up enough to manually edit the
> "config.sh" script appropriately and change variables to correspond to
> the actual port and server name.

I think Rod has a valid point though.

To retrieve the config information, the system needs to know where to
connect to and what port.  I dont know about you but I have customers
who do have instances which span machines, and even multiple db
clusters for testing changes before they go into production.  The
connection information really does need to be stored somewhere that
the application can then use to retrieve it.

So that means some sort of a config file.  And once we go that far,
isn't it simpler to just store installation-specific config info in
that file?

Best Wishes,
Chris Travers
>
>
>> Config-Std (perl-Config-Std RPM) problems seem to be mostly
>> distribution issues -- Redhat based systems.
>
>
> Yes, the largest US/Australian commercial version of Linux.
>
>
>> I see two ways around getting the current or best RPMs.  Wse an
>> existing repo: Epel, Rpmforge, etc. or create a LSMB repo and put
>> problem packages into it.
>
>
> I think getting rid of problem packages and doing things in a simpler
> or more reliable way is better.
>
>
>> I believe if Yum is used, instead of downloading the RPMs and
>> installing them, the dependencies (or most of them) will be
>> automagically resolved.
>
>
> I use yum and that hasn't helped at all so far . .
>
>
>> According to the man page on my CentOS 5.7 workstation:
>>
>>  localinstall
>>      Is  used  to  install  a set of local rpm files. If
>>      required the enabled repositories will be used to resolve
>>      dependencies.  Note that  the  install  command  will do a
>>      local install, if given a filename.
>>
>> I still have to allocate the tuits to try an RPM/YUM install again.
>> The last RPM install attempt failed so I've been lurking and
>> following
>> the discussions letting ideas rattle around in my head.  Hopefully
>> this upcoming week I can give my ideas a chance to prove themselves.
>
>
> I'm glad that more than I are thinking about the problem!  My ideal
> situation is that on a fresh Fedora/RH/CentOS/etc system (installed from
> a LiveCD system), I can do:
>
>   yum install http://ledgersmb.org/latestversionpath/ledgersmb.rpm
>
> and, possibly with some automatic post-install checking, I can login
> and start creating company DBs.
>
> Regards,
>
> Phil.
> --
> Philip Rhoades
>
> GPO Box 3411
> Sydney NSW      2001
> Australia
> E-mail:  ..hidden..
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel