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
