* Emilien Klein: " [tryton-debian] Package layout for Tryton and GNU
Health" (Fri, 20 Sep 2013 22:29:36 +0200):
Hello Emilien,
thanks for the effort of writing this concept.
> 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.
>
> ========
First some words on Tryton:
It is very important to keep in mind, that Tryton is from the conceptual point
of view a framework. The core (server, client(s)) is meant to be able to build
whatever modular application, that basically needs (as the most important
features) user management with access control and database storage (ORM),
scalable, l10n, i18n, etc.
The current module set maintained by the Tryton project are components of a
business solution, while it is perfectly well possible to use the framework for
other purposes like schools, administration, hospitals, etc. . The modular
design of well done (generic) Tryton modules keeps in mind to be reusable by
other applications (like gnuhealth uses some of the base modues).
That said and to keep the power of the possibilities of the framework, I
consider it best for Debian packaging to follow rather closely the
well-thought-out layout of the original project.
The use cases:
If you take into account the preliminaries depicted above you will agree, that
there is not the slightest chance to get covered all use cases, when looking
from the *application* point of view. Let us rather look from the design of the
*framework* to get things clear.
The package layout:
My packaging work for Tryton in Debian is mainly focused on providing the
'toolset' (aka core and modules of the Tryton project), that Tryton is aimed to
be. This 'toolset' is always rather generic to meet the least common
denominator and thus to serve hopefully all potential users.
> This is the package layout I'm suggesting, with the goal of being as
> modular possible to meet all our personas' uses.
It is quite impossible to meet all personas' use in a generic package layout
other than to provide basic packages and to let customizing to the user, which
everyone(!) has his special needs.
I think, the current layout of Tryton packages meets most of those needs. At
least I didn't get other feedback.
> [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.
I don't see any point in not providing a startup script and not to start the
server in a secure basic configuration.
Tryton is database independent, but has a very strong preference for
PostgreSQL. This is reflected in the setup.py of the server and the boiler plate
of the project. And this is what justifies python-psycopg2 to be in Recommends,
not in Suggests.
> [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
I don't know yet dbconfig-common, but I was told by Andreas and you, that it
should be possible to opt out of the database configuration. If this is true,
I would like to have this in the base package with the possibility to configure
mainly postgres, perhaps also other databases.
I don't like at all the idea of database specific packages. In our experience
the database system to prefer is generally postgres. There is not yet a
database connector to Oracle, which perhaps could also be a reliable
alternative. With mysql there are serious issues due to non-standard SQL. sqlite
is not multi-user and therefore limited to moderate use cases. I wouldn't
recommend any other database than postgres to my users/customers. And certainly
I wouldn't do the maintenance of a mysql specific package. If someone wants to
do it, he is obviously free to do so.
> [C] one client package
> - to be installed on a workstation
> - wish: detects if a server is installed on the same machine
Running the client on a machine, which runs a Tryton server on standard ports,
just detects it on localhost. So your wish is already reality. To make it
automatically use this server may not be wished behavior.
> => 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.
The "jack of all trades device" ;)
Yes, those all-in-one packages are always an appreciated option for users
getting in touch with the software.
Some issues:
- In terms of quality they are clearly limited, because they install a lot of
stuff probably never needed in production. Who will ever use the accounting
plans of Germany, France, Belgium, Spain, Netherlands, (to be continued),
alltogether?
- An all-in-one package always targets one machine, which in production use
AFAIS is rarely the case for our users. Could be different for gnu-health
users.
I am not against an all-in-one package (tryton-modules-all is one), just
pointing at the limitations.
> [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).
Why not, yes. Could package the demo data used for providing the demo servers
on tryton.org. Could be reused by the all-in-one package.
Skipping the following detailed layout discussion, because first the general
layout must be clear and details are based on the general layout.
[snip]
> I am willing to help out (if needed) in packaging Tryton.
> For me the most important is that we reach an agreement ;)
Welcome! Thx again for your input,
Mathias
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
Attachment:
signature.asc
Description: PGP signature