Tthere isn't really any direct equivalence between RPM and SMP/E
concepts of maintenance.
Since a large Linux application (like LibreOffice) may be packaged as
several interdependent packages, in that sense a package is similar to
an FMID of a z/OS product; 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. I expect the average Linux package contains
many fewer elements than the typical z/OS product, so replacing the
whole thing is not that big of a deal. The Linux systems I have seen
also have many more packages installed than the typical number of FMIDs
on a z/OS system.
It is true that a package update must replace an entire package, not
just changed sub components of a package; 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. While all components of an
updated package are re-installed, it is also true that 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.
You can back out a package update by re-installing a previous package
level, just like you can back out a z/OS PTF that fixes multiple APARs
-- the dependency requirements are simpler to resolve when there are
only package-level dependencies to consider.
The frequency of occurrence of new package releases with minor changes
definitely entitles this to be called a maintenance process. That the
same RPM file can be used for new installation or maintenance is a nice
simplification from the user's standpoint.
The decentralized nature of Linux package maintenance and the extremely
large number of combinations of packages that could be present on a
Linux system does tend to make Linux platforms less predictable. It is
not so much a factor of the complete package replacement strategy
(changes at the source code level may be minor), as that the maintainers
of one package simply cannot test with all other package combinations
and may be unaware of some package combinations that are adversely
affected by their changes. Linux is more dependent upon their user
community to find non-obvious dependency issues.
Joel C Ewing
On 8/25/23 20:55, Jon Perryman wrote:
On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson
<[email protected]> wrote:
With Linux distros there are a few maint systems. The one I am
most familiar with is RPM.
Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package
which is the z/OS equivalent of product / component. Complete packages are
replaced regardless of the problems you want to fix. Every package has a
version number which is indentifies all the maintenance included in that
package.
To me YAST (the Linux equivalent of SMP/E) handles upgrades
YAST and SMP/e have nothing in common. YAST tells you it's about installation
and configuration. It's about replacing the entire package and nothing to do
with maintaining that package. The M in SMP/e stands for Maintenance. You never
see a PTF that is 1MB. The only reason SMP/e installs, is to create a
maintenance environment for the product / component. If installation is your
only requirement, then use a different tool like IEBCOPY, DFDSS or ???.
Each product/component has its own main entry and dependencies.
Unix dependencies are by version number and have nothing to do with the package
(product/component) in question. The package is completely replaced. SMP/e
dependencies can be for entities within the same function, other functions,
PTFs and APARs. A function is the SMP/e equivalent of a Unix package.
I thought it was a fairly good replacement for SMP/E for the
Linux side of things.
I can see how it could be used to do z/OS and related.....
YAST, RPM and other Unix package installers are unacceptable replacements for
SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire
product/component because they need 1 PTF. Add to that cascading product
installs because of dependencies. Worse than that, testing must include
everything that changed in those installs and every product/component that
interacts with all the installed products/components.
I think z/OS uptime is 99.9999%. You get what you pay for. Unix maint
philosophy may be acceptable on $10,000 computers but highly unacceptable on
multi-million $ computers. We don't tolerate unintentional downtime.
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
