It is common for documentation to be in a separate package from the code. SMP
provided documentation normally has the same FMID as the code.
If you want an equivalence with SMP rather than just parallel roles, then you
really need to factor in, e.g, cvs, svn, git.
________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
Joel C. Ewing <jce.ebe...@cox.net>
Sent: Saturday, August 26, 2023 12:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
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
>> <ste...@wkyr.net> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
