GNU Health/Patches and Patchsets
GNU Health Patch Sets
Since version 2.2.1, "patchsets" will be released for the GNU Health stable versions (those with even minor number, ej 1.2.3 )
Suppose the following scenario : The health center GNU SOLIDARIO HOSPITAL installs version 2.2.0 . After some weeks of running the server in the production environment, a bug is discovered that affects the health_service module. It's not a critical bug but it should be addressed shortly.
In the meantime, the bug has been reported and it has been fixed and documented. The system administrator at GNU SOLIDARIO HOSPITAL has two options :
- a) Download and apply the individual patch using the patch tool
- b) Wait and apply the latest patchset
It will be the context that will determine which method to use, but a general rule, unless you are in the context of a critical bug, you should use the patchset approach.
Some general ideas :
- The patches and patchsets don't require to do the whole installation again. The scripts are usually small and the installation time is very short in general.
- The patchsets are valid for minor numbers (ej, 2.0.x, 2.2.x ... )
Whenever a patchset is generated, a new GNU Health version is released, with the patchlevel number of the patchset.
Patches vs Patchsets
This section discusses the general concepts behind a patch and a patchset, and when to use one or the other.
Generally speaking, a patch is a portion of code that fixes a program or its components. In GNU Health, a patch is a "patch file" generated in a Mercurial specific Changeset .The patch file (diff) modifies specific sections of code, not replacing the whole file. It is applied with the Patch command. As stated before, the patch is associated to a specific Changeset, but not necesarily to the latest patch-level number (third component of the , ej, 1.2.3).
Pros of Patches:
- They are available immediately : If it's a critical bug, you can patch it immediately, no need to wait for the patchset.
- Very specific : Because of this high specificity, many times you could apply a patch in GNU Health with a running system, not affecting the availability.
Cons of Patches
- Requires more technical knowledge
- Very specific
- More cumbersome when dealing with binary files, like LibreOffice Reports
- Need to keep track of other un-applied patches
The high specificity of the patch makes it both a pro and a con. So it's quite operator dependent .
Note : We recommend avoid using patches unless is a critical bug that must be applied immediately.
Patch sets act at a higher level than patches, dealing with entire files and not chunks of code. They are packaged in the form of a compressed ŧar file. Applying a patchset is also a selective operation, in the sense that only part of the GNU Health kernel is modified.
Pros of Patchsets:
- Can be re-applied after a patch
- Applies all patches in that time-frame, including non-critical patches that were collected over time.
- Easier periodic installation / updates process.
- Linked to a specific GNU Health version ( the patchlevel number )
Cons of Patchsets
- Are not as immediate as patches . Although the time for critical patches should not exceed 24 hours
Criteria for a new patchset release
- Bugs marked as critical / Blockers
- Important Security issues
- The Number of non-critical bugs
- Read the instructions related to the patchset in Savannah. Depending on the patch you might need to update the module(s)
- Stop the GNU Health instance
- Backup your kernel and Database (always, no matter how small is the patch)
- Login using the gnuhealth account
- Don't change directories. Stay at your $HOME.Verify you're in the /home/gnuhealth
- Download the latest patchset for your Major.minor number . For example, if you are in version 2.6.x
- Uncompress the patchset
tar -xzvf gnuhealth_patchset-2.6.latest.tar.gz
- Restart the server