Re: Status of 1.4

On Thu, Feb 16, 2012 at 12:30 AM, Philip Rhoades <..hidden..> wrote:

Chris,

On 2012-02-15 19:53, Chris Travers wrote:
> On Wed, Feb 15, 2012 at 12:43 AM, Philip Rhoades <..hidden..>
> wrote:
>> Chris,
>>
>>
>> On 2012-02-15 16:24, Chris Travers wrote:
>>> Hi Philip;
>>>
>>> Important work on 1.4 for better RPM installs have already been
>>> done
>>> but more needs to be done.
>>>
>>> We have already removed dependencies to PostgreSQL
>>> contrib/extensions.
>>> I am pushing for a policy that contrib/extensions should only be
>>> used
>>> on LedgerSMB extensions and not by the core software. This will
>>> allow us to have two RPMs, one of which will list postgresql-server
>>> as
>>> a dependency and the other will only list the client libraries.
>>>
>>> Note that the above only works for PostgreSQL 8.4 or higher. We
>>> cannot backport this to 1.3 because if we do we have to drop
>>> support
>>> for PostgreSQL 8.3. I dont see this happening.
>>>
>>> The above change has also resulted in significant performance gains
>>> in
>>> affected areas.
>>
>>
>> Is there something I can test?
>
> As soon as I finish up with the rewrite of projects/departments, etc
> (this week) I intend to release another milestone for 1.4. I expect
> it could be done in RPM format too.

OK, let me know.

>>> There are, however, a few other areas to address. It isnt clear
>>> whether these can be backported to the standard branch but they
>>> will
>>> be done as well.
>>>
>>> The first is that Config::Std really doesnt seem to be as well
>>> supported on various packages as I would like. We need to figure
>>> out
>>> how best to approach this. One option would be, since this is a
>>> pure
>>> Perl module, to just include it in the RPM in the local install.
>>> Another option would be to change the config parsing to a
>>> different
>>> module. This would probably not be a big job.
>>
>>
>> perl-Config-Std seems like something to be eliminated from my point
>> of
>> view . .
>
> Any recommendations for a replacement .ini parser?

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.

Config::General looks like it is well supported. We'll go ahead and use that.

The ledgersmb.conf is supposed to control system-specific configuration information, while the defaults table contains company-specific information. Putting this in the various company databases in 1.3 and higher is not really desirable because it is installation, not company, specific. Reserving another central database is something we have been trying to get away from.

>>> The final thing that needs to be done is that we need a tool that
>>> can
>>> try to validate installation configuration and correct if possible
>>> without going through the whole build process.
>>
>>
>> Yes, I realise that my desire for a fully RPM-based install may not
>> be
>> possible and that some post RPM processing may be necessary. I am
>> not
>> sure what the best solution to that issue is - I haven't come across
>> something similar with other packages.
>
> I think that misses the point of the tools.
>
> Suppose you install the RPM and you keep getting Perl code back to
> your browser. It would make sense to have the ledgersmb-httpd.conf
> file something that could be re-generated and dropped in the relevant
> directory without going through a program that wants to run make
> test.
>
> Right now, if it works, it works, and if it doesn't, then suddenly
> you
> need additional packages from CPAN, which is far from ideal.

I was thinking of some executable or script that could check out the
installation to see if everything looks sensible.

Will have to think about this one more.

>>> Either that or we
>>> need to make a decision that we will require the build-requires
>>> modules as well as the modules required for use. The
>>> build-requires
>>> include Test, Test::More, and Test::Exception. Either of these
>>> approaches could be done in the stable branch.
>>>
>>> Any feedback on these approaches, or other things you think need to
>>> be
>>> done are worth noting, however.
>>
>>
>> Really, I just need to get something going - as a means of trying to
>> debug the latest RPM install problem (setup.pl not finding stuff in
>> /usr/share/pgsql/contrib) I went back to a manual tar.gz install (on
>> a
>> clean virtual machine) but had other problems with that and
>> eventually
>> gave up. A working LSMB RPM is ideal for me but I have to get some
>> actual accounting work done soon.
>
> Ok, let's see what we can do with the latest, and go from there. I
> will announce the next 1.4 milestone as soon as this is complete.

It sounds like I should be testing 1.4 so I will wait a bit more . .

BTW, once I have an RPM version that installs nicely or that I can see
will eventually install nicely, I need to actually start doing the
accounting and I happy to pay for accounting advice once I am actually
committed.

Understood.

Thanks,

Phil.
--
Philip Rhoades, EO
Cryonics Association of Australasia

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