Hey,
This is my intent to reach an agreement on the best way to maintain both the Tryton and GNU Health packages in Debian. I realize it's a long email, but please bear with me as it is meant to be the start of a discussion. Please speak up and argument your opinion!
========
Let me first introduce a couple of fictitious users. The goal is to visualize how to best serve the interests of our users. Feel free to suggest other personas if you feel this is not covering specific scenarios.
Marc: a seasoned IT-manager, he's just started to work for a start-up. He has been tasked to come up with a system to handle the company's accounting, invoicing, sales and purchase management. He has extensive experience in setting up and configuring Linux-based servers, and has his preferred way of doing things. He's got access to powerful virtual servers, and he's got all intents of using them!
Adèle: a senior doctor working for one of the biggest hospitals in the capital city of a developing economy, she is one of the respected voices of her organization. Next to the patient care that takes most of her time, she's got to handle lots of aspects of running the hospital, in particular the transition from paper to an electronic medical record. Exciting, but demanding times.
Luis: a cranky server admin, he was fired at the end of last year due to economic reasons. Forced to sell his house, he has moved with his wife and kids to live with his in-laws (which makes him even more cranky!). His mother-in-law is a recently retired family doctor, and she still has a lot of contacts among her former colleagues. Luis hopes to capitalize on her connections to set up a new company aiming to provide computer services to general practitioners in the area.
Sophie: a Business Administration student, she's excited to start her new internship at a local department store, where she is charged of redesigning the inventory management system in 2 months. Her success at that task will allow her to validate her 3rd study year.
========
This is the package layout I'm suggesting, with the goal of being as modular possible to meet all our personas' uses.
[A] database-independent server package(s)
- provides the functionality (i.e. source code)
- comes with an example start-up script, but does not install it in /etc/init.d
- suggests the database-specific packages [B]
=> install if you want to manually configure the database, the start-up service, etc.
[B] multiple database-specific package
- one package per supported database backend (postgres, sqlite)
- depends on the generic package [A]
- depends on one of the database backend
- uses dbconfig-common to configure the database for the user
- update process takes care of making a backup prior to upgrading, and upgrades the database (running upstream-provided scripts, if provided).
- installs a start-up script
- question: should these be mutually exclusive with the other db-specific package, or should both be able to live next to each other (maybe 2 servers running on different ports?)
- idea: install a daily crontab to make automatic backups of the database
=> install if you want to have an out-of-the box working server, with minimal configuration and maintenance
[C] one client package
- to be installed on a workstation
- wish: detects if a server is installed on the same machine
=> pretty self-explanatory: install the client if you plan to connect to the server ;)
[D] one all-in-one package
- has the short name of the project
- depends on both the client and one database-specific package (the one that makes most sense for a production system)
=> install if you want an out-of-the box installation combining both the server and the client on the same machine. Focus is easy to install and maintain.
[E] a demo package
- depends on one of the db-specific packages (same as [D], as these 2 packages must be able to live side-by-side)
- creates a separate demo database, filled with the demo data provided by upstream
=> install to have an offline version of the demonstration data. This is a low-priority project, but is still useful for connection-challenged areas, or when people are often traveling without Internet connection (think about playing around with the demo while seated in a train or plane).
========
This is how this package layout would translate for Tryton:
[A] `tryton-server`: provides the source code for the server functionality. The current package would have to be modified to not install the start-up service in /etc/init.d. It would provide an example configuration file, which would need to be manually edited to fit the user's needs, and instructions in the README.Debian file containing the steps to configure the database (similar to current package).
Suggests: tryton-server-postgres | tryton-server-sqlite
All the different `tryton-modules-*` packages are also part of this category: they depend on tryton-server, provide the source code for their functionality, but don't need to care about a start-up service or database-configuration instructions.
[B] 2 new packages would be introduced, each depending on `tryton-server` and on one supported database backend:
- `tryton-server-postgres`
- `tryton-server-sqlite`
At installation time, the user will be prompted to configure the database using `dbconfig-common`. The database would be created (using the default installation of the database backend, as provided by their Debian packagers) and prepared for use with Tryton (sudo -u <TRYTONUSER> TRYTONPASSFILE=<PASSFILE> trytond --database=tryton --init=all --config=<TRYTON_CONFFILE>). Database will be backed up at upgrade time, and the database itself will be upgraded (sudo -u <TRYTONUSER> trytond --database=tryton --update=all --config=<TRYTON_CONFFILE>)
These 2 packages install their start-up script. Goals is that using the default configuration of the database backend, and configuring with `dbconfig-common`, a user doesn't need to fiddle with the configuration files (unless they want to, obviously!)
[C] The `tryton-client` package would basically stay the same as what is currently packaged. Maybe provide a `tryton` alias?
[D] A new `tryton` package would be introduced, depending on `tryton-client`, `tryton-server-postgres`, and a few often-used modules (or even `tryton-modules-all`?). Once the packages are installed and the database is configured via `dbconfig-common`, launching the Tryton client is all that's needed to run Tryton.
[E] A new `tryton-demo` package could be created, providing the same data as is available online at
demo.tryton.org. Package would depend on `tryton-server-postgres` and create a new database, just for the demo data.
========
This is how this package layout would translate for GNU Health:
[A] `gnuhealth-server`: bare-bones installation, depends on `tryton-server` and the requisite Tryton modules, but does not handle anything related to databases or start-up services (an example is provided, but not installed in /etc/init.d).
Suggests: gnuhealth-server-postgres | gnuhealth-server-sqlite
[B] 2 new packages, both depending on `tryton-server` (i.e. not one of the database-flavored packages) and providing GNU Health-specific start-up service (separate port as the default Tryton installation).
- `gnuhealth-server-postgres`
- `gnuhealth-server-sqlite`
Same as for the Tryton packages of category [B], installation takes care of creating an preparing the database, upgrades take care of backing up and upgrading the database (also running the eventual upgrade scripts provided by upstream)
[C] `gnuhealth-client`: depends on tryton-client, provides a wrapper that is pre-configured for the GNU Health -specific daemon (namely: separate port as the default Tryton installation)
[D] The `gnuhealth` package, depending on `gnuhealth-client` and `gnuhealth-server-postgres`, is the one-stop-shop to provide an instantaneous solution to run GNU health.
[E] A new `gnuhealth-demo` package would provide similar data as at
health.gnusolidario.org. Like `gnuhealth`, it depends on `gnuhealth-server-postgres`.
========
Finally, going back to our personas:
Marc (the seasoned IT-manager) has set up a couple of virtual servers to build up his ultimate ERP system:
- one running a patched version of PostgreSQL, the primary database
- a second server, identical to the first one, running Postgres in Warm Standby/Log Shipping mode (High Availability) to replicate the primary database in real-time. This setup provides continuous backup and short failover times, should the primary database server experience a failure.
- another server is dedicated to run Tryton. Since the database runs on separate servers, Marc enjoys the flexibility of installing the `tryton-server` package and manually editing the configuration files, pointing the database information to the remote primary Postgres server.
Adèle (the estimated doctor) was finally able to find a few hours of her spare time to research the best options to equip her health center, and she's selected GNU Health to present to her fellow board members. Together with her teenage kid, they install the `gnuhealth` and `gnuhealth-demo` packages provided by Debian, and after answering some questions (not always very clear to the laymen), Adèle is able to give a demo to her colleagues. After in depth sessions are held with key hospital staff, the Debian workstation is "promoted" to a role of central server, one of the first that is running in this important but low-resource hospital. A few workstation are installed here and there (namely in the Emergency Department, in the Intensive Care Unit and outside of the Operating Rooms). Installing the `gnuhealth-client` package on these computers provides for a quick way of setting workstations up. All in all, this new GNU Health installation is a big step forward, but in the coming months the IT infrastructure of the hospital will have to be beefed up!
Luis (cranky admin) has come up with a systems architecture that he hopes will allow him to provide optimal service to the general practitioners in his new city: on a central server, Luis has installed the `gnuhealth-server` package, and for each customer he's set up a separate VM, running its own database. Using Puppet, each time his mother-in-law convinces a peer to join Luis' network, a new VM is created, together with a separate GNU Health server dedicated for that healthcare provider. Luis was happy to be able to inspire himself from the start-up service provided as an example in that package, and has adapted it for his own particular needs.
Sophie (the BA student) hasn't got much time: in less than two months, the internship she's just started will be over! Having heard about Tryton, she just goes for it and installs the `tryton` package that provides both the server and the client on her laptop. After a few days reading tutorials and playing with the online demo provided by Tryton, she's set up the roots for a working inventory management system. Showing it off to her mentor the next week, she's getting approval to continue on that path and enter all the department store's inventory in that new system. At the end of her internship, one of the idle servers of the company is used to install `tryton-server-postgres`, the data is migrated from the laptop to this new server, and the head of the department gets a fresh install of the `tryton-client` package on her desktop. Mission accomplished!
========
So, this is where the discussion continues: what do you think of my proposal for the package layout for both Tryton and GNU Health?
Anything that crosses your mind when reading the made-up scenarios? I tried to make them realistic, but we all know the world out there is much more complex. Providing only 4 examples will obviously not cover all use-cases, but by trying to make it a bit less abstract, I hope we can make this a productive discussion and find the best solution in the long run.