[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status of 1.4



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.


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.


 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.

Thanks,

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

GPO Box 3411
Sydney NSW	2001
Australia
E-mail:  ..hidden..