RSG Software Management System Code
RSG is a Software Management System
Brought to you by:
aofarrell2
Menu
▾
▴
Tree [2bce31] default tip / History
| File | Date | Author | Commit |
|---|---|---|---|
| doc | 2017-01-07 |
aofarrell2
|
[6a1353] No commit message. |
| lib | 2016-12-30 |
aofarrell2
|
[bc0ab2] Deprecated chkroot.cc |
| main | 2016-09-14 |
aofarrell2
|
[822a17] Added checksum.b library. |
| modules | 2016-12-30 |
aofarrell2
|
[73af16] Added README files. |
| .project | 2016-08-28 |
alec
|
[c79638] Added GPL v3 |
| COPYING | 2016-08-28 |
alec
|
[c79638] Added GPL v3 |
| README | 2017-01-09 |
aofarrell2
|
[2bce31] Migration to Eclipse Neon.2 |
Read Me
RSG Ready Set Go, (C) Copyright 2016 Keagan Winterthieme. RSG is a part of the LibraNext Computer Systems family. RSG stands for Ready Set Go. RSG is a software management system. It is designed to work exclusively with LIMS (LibraNext Image Management System). RSG takes a different approach to handling the installation, configuration, and removal of applications. This software is licensed under the GNU GPL version 3. See the COPYING file for more information. RSG must be built as part of the LIMS build process. It can not be built separately (with the exception of building the bootstrapping component). See the LIMS build documentation for more information. Software Management versus Package Management =============================================== RSG differs from traditional package managers in that it does not directly alter system configuration. It's sole job is to install applications (both binary and source). Package managers will directly modify system configuration. Poorly built software or packages can easily mess up system files, and package managers don't perform sanity checks. RSG is a software management system and does not directly modify system configuration. Instead, while it installs application files, it interfaces with LIMS to make system configuration changes. This allows LIMS to run sanity checks and also helps maintain compatibility with legacy applications because there is a standardized configuration interface. Regardless of how the underlying system changes, the application will always still see setting A as setting A, even if the underlying system now references setting A as setting AA.
