I've been lazy and been leaning on 31-bit stuff for too long, but I've also been tending toward statically linked executables. The following Chicory packages are 31-bit mode but are statically linked and should run on any S390 or S390X Linux build or release.
bind-9.11.1 ncurses-5.9 ncurses-6.0 ntp-4.2.8p9 sharutils-4.15.2 The full URL for RSYNC for each would be ... *rsync://chic.casita.net/opt/bind-9.11.1/Linux-s390/** **rsync://chic.casita.net/opt/ncurses-5.9/Linux-s390/** **rsync://chic.casita.net/opt/ncurses-6.0/Linux-s390/** **rsync://chic.casita.net/opt/ntp-4.2.8p9/Linux-s390/** **rsync://chic.casita.net/opt/sharutils-4.15.2/Linux-s390/* There are others which are dynamically linked, several times more. (And Rick promises himself to kick-up a 64-bit z/Linux build system real soon now. Personal stuff lags work stuff.)The '*chicory-install*' script wraps '*rsync*' and figures out the platform, so one could snag any of these as a one-shot. Works. I occasionally announce new Chicory makefile stubs following new releases from the package maintainers. I usually DO NOT advertise the pre-compiled chiclets. That's restricted to my friends in the z/VM and z/Linux world. (Don't y'all feel special?) -- R; <>< On 9/17/19 7:08 PM, Rick Troth wrote: > 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 lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390