[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of 1.4
- Subject: Re: Status of 1.4
- From: Chris Travers <..hidden..>
- Date: Wed, 15 Feb 2012 00:53:24 -0800
On Wed, Feb 15, 2012 at 12:43 AM, Philip Rhoades <..hidden..> wrote:
> 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
>> 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
>> 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
>> 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.
>> 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?
>> 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.
>> 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
>> 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.
> Philip Rhoades
> GPO Box 3411
> Sydney NSW 2001
> 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.
> Ledger-smb-devel mailing list