I don't know git so I can't really comment. I did google gif diff and see what you mean now by a patch.
For one, it seems like overkill. Two, I don't have git diff on z/OS so somehow I'd have to get all my existing /etc (and /var) out there to compare what IBM would put out there that matches the /etc (and /var) you get with a new OS? To go back to my parmlib example, why would I need to compare IPO1.PARMLIB sample members to my running parmlib members from a system I'm about to upprade. The LNKLST, APF, SVCs, etc are are locally customized for my running system. However, if a new sample member was introduced that could be used if I implemented some new feature, then it may be nice to have that sample in my running parmlib with the "merge" process or "IEBCOPY, no replace" if you will. :) Not really a good comparison because in this scenario the new parmlib member would be put in the SMP/E target IBM.PARMLIB or in SAMPLIB, but it is the best I could come up with right now. BTW, A better approach to what the OP said happened in his upgrade (done by some 3rd party) is to not touch it at all and just use your existing /etc and /var for your OS upgrade or a copy of it with documented required changes from the upgrade workflow, just like you would handle required parmlib changes. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html On Wed, 7 Jun 2023 01:53:40 +0000, kekronbekron <[email protected]> wrote: >Consider, for example, you upgrade from Ubuntu 20.04 to 22.04, and have >updated the sudoers file. >When upgrading, you get a prompt showing a diff between the new version and >your customized version. > >And quoting a bit from your reply... >> compare the distributed /etc to what you already have to see if possible >> other changes >may be desired. > >"compare the..." > >Normal diff, git diff... > >/untouched/etc/ >/custom/etc > >(git) diff against both to see what we customized. >create a patch > >/new-untouched/etc/ >/new-custom/etc/ > >Here, I'm saying /new-custom/etc/ can be created by doing a git apply of the >patch from earlier. > >I mean... creating patches is quite common to keep just the delta, on a >version-controlled repository. > >If it still doesn't make sense, it would be good to correct my >understanding... without being pointed to the git website :) > >- KB > >------- Original Message ------- >On Tuesday, June 6th, 2023 at 9:29 PM, Mark Zelden <[email protected]> wrote: > > >> On Tue, 6 Jun 2023 03:15:46 +0000, kekronbekron [email protected] >> wrote: >> >> > I do wonder... with git now available, and this being normal USS, maybe >> > zOSMF can start formally adopting/requiring git. >> > Then, moving updates from these files onto newer versions is a matter of >> > applying git patches on the new ones, where possible. >> > Something that the zOSMF UI can accomodate. >> > >> > Do let me know if this doesn't make sense lol. >> >> >> No, that makes no sense. Think of /etc as the SYS1.PARMLIB for z/OS Unix. >> Any customization to >> existing files should not be touched. That is why it only makes sense to >> copy what's new into it >> and also compare the distributed /etc to what you already have to see if >> possible other changes >> may be desired. I can't think of many required changes of the years but when >> there are >> they are (or should be) in the migration manual or upgrade workflow for >> current versions. >> >> Regards, >> >> Mark >> -- >> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS >> ITIL v3 Foundation Certified >> mailto:[email protected] >> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
