Not the first time I've tried to explain Chicory. Here goes. Chicory is a package management scheme that works independently from whatever package management tools the vendor/distributor supports. The downside is that it represents a secondary ecosystem from RPM. The upside is that it offers a secondary (and independent) ecosystem.
While working at Rice University, the Doctor and I shared an office with another fellow who was attacking ye olde Unix problem of unmaintained software thrown haphazard under /usr/local/bin. He created a "/usr/site" prefix and some related documentation to guide the team (herd the cats). What he did was not Chicory but was the original inspiration for organized flexible software inventory, specifically for things which fell outside of the vendor support realm. NFS was the norm in those days, so varying residence happened organically. The rationale behind Chicory is to _separate software reference from software residence_. There are so many directions this goes that it's more than we can talk about in just one email post. Then also, Chicory runs independently from the OS primary packager so you get ample flexibility for things like user-driven software management without compromising system integrity. (Things installed via Chicory do not interfere with things installed via RPM, and vice versa.) The keystone of Chicory is its master prefix (recommended /usr/opt). Chicory packages are found under this path. Packages compiled for Chicory find their runtime requirements here. Users find the packages here, whether or not programs are also sym-linked to (e.g.) /usr/local/bin. For any "production" package, there will be two sym-links in /usr/opt: one with version qualification and one without. For example: * /usr/opt/the-3.2 /usr/opt/the* Chicory allows that you can have multiple versions of any package installed simultaneously. (Whether or not the package has its own internal multiversion logic. Some do; most don't.) You might have only one release of a package, or you might have several. For example, I keep multiple releases of GCC on-hand ... * $ ls -ld /usr/opt/gcc* lrwxrwxrwx 1 nord nord 9 Jan 12 2018 /usr/opt/gcc -> gcc-4.8.5 lrwxrwxrwx 1 nord nord 29 Jan 7 2018 /usr/opt/gcc-3.4.6 -> /opt/CD2/gcc-3.4.6/Linux-i386 lrwxrwxrwx 1 nord nord 29 Jan 5 2018 /usr/opt/gcc-4.4.6 -> /opt/CD2/gcc-4.4.6/Linux-i386 lrwxrwxrwx 1 nord nord 29 Jan 12 2018 /usr/opt/gcc-4.8.5 -> /opt/CD2/gcc-4.8.5/Linux-i386* (hoping that survives line wrap) I can point to any of them explicitly or I can change the unqualified link (if I own it) in a pinch. The version qualified sym-link points to the package residence. Any single release of any particular package can reside anywhere you like: local disk, R/O media (CD or otherwise), removable media, SAN, LAN, NFS or SMB file share, on z/VM linkable disk or perhaps in a DCSS. Anywhere. Most "chiclets" are laid out with multiple platforms in mind. Even if there's just one platform built, that name shows up in the residence path. (This is hidden at the master prefix level.) So for the Hessling Editor, you have ... * ** Linux-i386 Linux-s390 Linux-arm Linux-sparc FreeBSD FreeBSD-amd64 CYGWIN * FreeBSD and CYGWIN are 32-bit flavors which lately are better qualified for clarity (FreeBSD-i386 and CYGWIN-i386). Also known to work for Solaris, HP-UX, AIX, MacOS, Minix, OpenBSD, NetBSD, z/OS (USS), and CMS (OpenVM). The latter two have character set issues, so the multiplatform thing fails a bit there. (Details too lengthy for this note.) Note: "i386" is generic. I doubt anyone in this audience has anything less than an "i686", as RPM usually identifies 32-bit PC architecture. The handful of scripts built around Chicory for automation (things like 'chicory-install') expect this kind of platform identifier. It's derived from 'uname -s' and 'uname -m', with adjustments as needed. Most chiclets have a 'setup' script which knows all of this. Some tools tag the platform their own way. Chicory works hard to let the OS identify itself. Note: YOU CAN coordinate Chicory installations with your RPM database giving a single handle on all packages. BT/DT, it works. The 'setup' script usually drops a .inv file for such coordination. About user-driven software management, I recommend ... * chmod 1777 /usr/opt* Similar to /tmp, anyone can write, but one user cannot muck with what another user has done. Admin has final say, of course, and you don't have to do it this way. The name is new. The project has been around for a really long time and never had a name. I'm a heavy coffee drinker, and I like the New Orleans brew. The name "chicory" was not in use that I could find, so there it is. Hopefully y'all see the close comparison with MacOS "Brew" or "Homebrew". (Though I sense Chicory is simpler.) That's Chicory in a nutshell. There's a limited public repository at ... * rsync://chic.casita.net/opt/* There's a GitHub project with the latest 'chicory-install' and other scripts, make stubs for building, a growing body of PGP source signing keys ... * https://github.com/trothr/chicory/* -- R; <>< ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
