> On Friday, August 25, 2023 at 09:32:34 PM PDT, Joel C. Ewing > <jce.ebe...@cox.net> wrote:
> in that sense a package is similar to an FMID of a z/OS product; A Unix package name combined with the version is an SMP/e FMID. Just like Unix, a z/OS will have 1 or more FMID. Like Unix, installing 1 of the FMIDs will automatically cause the related/dependant FMIDs to be installed. > There isn't really any direct equivalence between RPM and SMP/E > concepts of maintenance. I repeat, RPM installs packages that has nothing to do with maintenance. The Unix maintenance philosophy is to create multiple smaller packages in the hopes that a single package is less of an impact than reinstalling the entire product. In SMP/e, we can use 1 FMID instead of worrying about maintenance philosophy. > Since a large Linux application (like LibreOffice) may be packaged as > several interdependent packages, but the number of pieces/files contained in a > package tends to vary more widely than for z/OS products, in some cases > containing very few files. Ask yourself why a package with just a few files that could have been included with another package. The one question you don't answer is what goes into your packaging decisions. What are the benefits to creating multiple packages/FMIDs versus 1 large package/FMID? > but new release levels of a package also occur with much greater > frequency than new versions or release levels of a z/OS product. > A new release level of a package typically contains a number of code fixes, > and in that respect is more like a z/OS PTF that fixes multiple APARS. IBM is on a 2 year package / FMID release cycle. Are you saying that z/OS would be manageable where PTFs become available every 2 years? > current RPM download protocols also support just downloading the RPM delta > from the previous package level if only a small part of a large package RPM > file > has changed. Installing changed files versus installing the entire package doesn't change anything except speeding up the process. The new package has been installed completely. > the dependency requirements are simpler to resolve when there are > only package-level dependencies to consider. Dependency resolution is the same for RPM and SMP/e. Neither is complicated for the user. >The frequency of occurrence of new package releases with minor changes > definitely entitles this to be called a maintenance process. Frequency of packaging is the maintenance process. If you change to 20 year packaging frequency, you wouldn't call this maintenance. The process (not RPM) is the maintenance philosophy. > The decentralized nature of Linux package maintenance Linux and RPM are free. Both are basic solutions to a problem. Unlike z/OS, a Linux image is only active on 1 physical machine. Maintenance is applied directly to the active system. A $10,000 machine being down for a couple hours is trivial. Google has 5,500,000 servers so missing 10,000 servers would go unnoticed. On the other hand a multi-million $ sysplex will be catastrophic. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
