I'm going to outline some patches that improve the installation experience for
Linux users that I've submitted for inclusion in OpenERP.
A number of things inspired me to develop these patches not the least of
which was all the newbie, first-time, user pain that was seen in the
Installation forum. To a great degree I think the painful first-time user
experience is hurting the growth of the community. And for all of us who use
OpenERP it is important that the community continues to grow.
So what are the features of these patches?
Adds a New Command 'setrelease' to setup.py
'setrelease' enables adding the code revison number into the release string and
therefore the package names for all distribution targets: 'sdist', 'bdist',
bdist_rpm' ('bdist_deb' later - see below).
Eg: (where 1759 is the code revision from bzr or other source control):
'sdist': openerp-server-5.0.0-3_00001759.tar.gz
'bdist_rpm': openerp-server-5.0.0-3_00001759.noarch.rpm
Why is 'setrelease' important? Because without it all packages in between
'official' tagged releases end up generating exactly the same package names
which is dangerous because they are actually different.
$ python setup.py setrelease
Enables Anytime Creation of RPM Packaging for OpenERP
So now you can generate your own RPM anytime you want without having to wait
for some distro package maintainer to get around to doing it for you. Here's
the steps:
TO BUILD THE RPMS:
$ cd (your openerp server bzr tree)
$ mkdir ~/build/python-dist
$ revno=$(bzr revno)
$ python setup.py setrelease sdist
$ cp dist/openerp-server-5.0.0-3_0000$revno.tar.gz ~/build/python-dist/
$ cd ~/build/python-dist
$ tar xvf openerp-server-5.0.0-3_0000$revno.tar.gz
$ cd openerp-server-5.0.0-3_0000$revno
$ python setup.py bdist_rpm
(please be patient, it takes a while to build the RPM's)
So now that we have the RPM how does this RPM make installation easier?
Protection For Your Existing Configuration Files
There's nothing worse than upgrading an application using an installer only to
find that the install wiped out your config file and you've lost all your
settings. So I've made sure to add some protection for your configuration
files by using some rpmbuild magic that makes RPM check for your config files
and if it finds any in place it will leave them alone and write out the new
config file from the RPM package to a filename ending in .rpmnew and issue a
warning message. So as you watch the installation you will see any config
warnings and you know that you need to check/merge your configuration file.
And this way you don't accidentally lose all your settings.
Automatic Configuration of Important Settings
This is probably the number one cause of all the installation pain for newbies.
They read and read and read and still cannot figure out how to get things
setup so as to get things running properly. Now the RPM installation will
automatically perform the following:
1. Adds 'openerp' user and group on server.
2. Checks for a pre-existing config file and if present use it for default
settings otherwise use some general settings as the defaults.
3. Prompts user to enter hostname(ip) and port of the postgresql server. (times
out and uses default after 15 secs.)
4. Prompts user to enter the user and database to use/create in postgresql.
(times out and uses default after 15 secs.)
5. Checks database connection.
6. Checks/creates user and database in postgresql.
And now that we have a better installation how does the new control 'init'
script make operation easier?
Better Operational Control and Flexibility
1. Enables you to run both V4 and V5 at the same time.
You can run both V4 and V5 at the same time and control them separately by
using separate config, log, pid, lock and control files.
2. Enables you to run multiple instances of V5 servers for different purpose
on the same machine.
Suppose you want one server process for development/testing and another server
process for production use. You could do this using the control 'init' script
that I've included in the patches. It allows you to create additional config
files using names like 'openerp-server-devel.conf. And control this 'devel'
server using commands like, '/etc/init.d/openerp-server start devel.
So now operationally you have full control of how you want to implement and
deploy your V4 and V5 servers including multiple server process instances that
are separately controlled.
All the functionality above has been implemented with very little code using
standard existing mechanisms in RPM and Linux.
And that makes the solution very clean and very maintainable into the future.
The patches that implement the above functionality are localed in this
launchpad bug: https://bugs.launchpad.net/openobject-server/+bug/329580
If you would like to try these installation improvement patches just do the
following:
$ cd (an openerp-server bzr tree)
$ tar xzf (the latest gzipped-tar file from the bug)
$ patch -p0 <(the latest patch file from the bug)
Regards,
Gerry
P.S. I've been working with the Python Distutils SIG to get patches for a new
comand 'bdist_deb' adopted for Distutils. There is good momentum behind this
initiative so it looks like these patches will make it in very soon. And once
that is done then we can create the same type of efficient solution for the
Debian-based distros.
-------------------- m2f --------------------
--
http://www.openobject.com/forum/viewtopic.php?p=33060#33060
-------------------- m2f --------------------
_______________________________________________
Tinyerp-users mailing list
http://tiny.be/mailman/listinfo/tinyerp-users
