| | 1 | = Updating NCM Components = |
| | 2 | [[TracNav]] |
| | 3 | |
| | 4 | [[TOC(inline)]] |
| | 5 | |
| | 6 | |
| | 7 | NCM components are maintained as part of the core Quattor distribution and QWG templates are using them as is. It is important to keep core Quattor distribution and QWG templates in sync with this respect. This page describes the procedure required to properly update NCM Components. |
| | 8 | |
| | 9 | |
| | 10 | == Modifying Component Templates == |
| | 11 | |
| | 12 | Templates related to components (located in directory `components/xxx` where `xxx` is the component name) '''must never be modified''' in place. These files are imported from Quattor CVS and edits made directly in QWG templates will be lost at next update of the component. |
| | 13 | |
| | 14 | If you need to modify these templates (e.g. to add support for a new configuration option), you need to get a copy of [http://quattor.web.cern.ch/quattor/software.htm Quattor CVS], make your modification and commit your changes in CVS to produce a new version of the component. This requires write access to Quattor CVS : if you don't have such an access, contact the component maintainer (look at `config.mk` file) or ask for write access on Quattor Project mailin list `<project-quattor AT cern.ch>`. |
| | 15 | |
| | 16 | If you are not familiar with Quattor build tools, here is the steps required to produce a new version of the component : |
| | 17 | 1. Make your modifications keeping the current version number (without committing them), rebuild the component and install you changes. '''Take care of editing `.cin` files''' instead of the real file (component module, doc or templates). |
| | 18 | 1. Test your changes : if you modified the component module, it is recommended you install your RPM manually on one node to test it (use `ncm-ncd --configure component` to execute it). The commands to rebuild the component are : |
| | 19 | {{{ |
| | 20 | make |
| | 21 | make rpm |
| | 22 | }}} |
| | 23 | 1. Commit your changes : don't do a `CVS commit` directly but use `make` targets. There are 3 targets related to tagging a new release, according to the importance of the change : |
| | 24 | * `release` for minor modifications without new features (increment `r` in `M.m.r-n`) |
| | 25 | * `minorversion` for significant modifications (including new features) but without major redesign of the component (increment `m` in M.m.r-n`) |
| | 26 | * `majorversion` for major changes like component rewrite or incompatible changes with a previous version (increment `M` in M.m.r-n`). |
| | 27 | 1. Rebuild the new version of the component : it is important to do a `clean` before else `TPL/config.tpl` may not be updated properly : |
| | 28 | {{{ |
| | 29 | make clean |
| | 30 | make |
| | 31 | make rpm |
| | 32 | }}} |
| | 33 | |
| | 34 | == Installing a New Version == |
