Pre Packaged Git Installation

[lbdyck]

I propose a pre-packaged installation that includes git, curl, and any other pre/co-requisites that would all install into a common structure to minimize paths and confusion.

As part of this I propose a variation of the .env that can be copied into /etc/profile or the users .profile to configure the correct environmental variables.

Basically a 'turn key' install for the git users.

This common structure can then be easily copied into a new zfs and mounted at a unique mount point which will allow the zfs to be replaced with updates as needed.

[MikeFultonDev]

I agree. I had a similar idea - let me find it and we can link the discussions

[lbdyck]

I'd like to proposed a variation of zopen-setup, perhaps zopen-git-setup. It would install the zopen git port along with any pre/co-req's and then install zigi.

During the process it should prompt for:

1. target location to install the tools
2. if zigi should be installed
3. create a file to be added to ~/.profile or /etc/profile (bootenvs?)

One zot to rule the world :)

[MikeFultonDev]

What if we had an option to say what to install with zopen-setup and you could specify the tool(s) you want, eg zopen-setup zigi.
then when it looks at zigi it can see what tools it needs (git) and then for each of those tools see what they need (Perl bash)? Then it would be more general purpose? It could likely use zopen-install under the covers since it’s now sort of a package manager?

[IgorTodorovskiIBM]

I like the idea of using zopen install under the covers of zopen-setup

[lbdyck]

That works for me.

Also need an option to update an installation.

Note that there may be multiple target installation directories - one for production, one for testing, and one for experimentation. Thus a 'zopen update' would need to prompt for the installation location to update so as not to update the others. In these examples the experimentation could be just to play around and possibly make changes to the installation files, testing would be pre-production to validate no issues arise from the 'zopen update', and production speaks for itself. Each location may, probably will be, a unique zfs.

[lbdyck]

I tried a clean install starting with curl and then meta and then the gitport. The zopen install git installed git and identified all pre/co-reqs and installed them all but it didn't create a single .env file.

Ideally to keep things simple and reduce the size of the env variables is there a chance of installing all into the same set of directories (all bin into bin, all man into man, etc.)? that will simplify the env variables and keep the length of the environment variables shorter (which bpxwunix prefers - i think it chokes at 255)

[IgorTodorovskiIBM]

Hey @lbdyck , regarding the first comment, the latest zopen install from today should resolves this. It creates a .depsenv file and sources it within the .env file.

[wizardofzos]

You and me we're thinking the same think Lionel :)

I've create a oneclick installer for git (and prereqs) as I've seen more peeps struggling with getting all the required softwares installed from the internets :)

Your pull requests to that private repo made it 'good enough' to share so it's there, and public available.

Check it out at : https://github.com/wizardofzos/gitmaster/releases/tag/v1.1.0

In case one wonders, release notes and repo-name written by my new friend ChatGPT (based on the shellscript as input)

[MikeFultonDev]

Hi Great to see. The first step indicates you need to clone the repo but it doesn’t list git as a pre-req. is the thought that someone would manually scp up the directory of files or did you miss git as a pre-req?

…

On Mon, Feb 20, 2023 at 13:58 wizardofzos ***@***.***> wrote: You and me we're thinking the same think Lionel :) I've create a oneclick installer for git (and prereqs) as I've seen more peeps struggling with getting all the required softwares installed from the internets :) Your pull requests to that private repo made it 'good enough' to share so it's there, and public available. Check it out at : https://github.com/wizardofzos/gitmaster/releases/tag/v1.1.0 In case one wonders, release notes and repo-name written by my new friend ChatGPT (based on the shellscript as input) — Reply to this email directly, view it on GitHub <https://github.com/orgs/ZOSOpenTools/discussions/142#discussioncomment-5057687>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOSFFEIEIG7DURMV2Z5SCNLWYPSIBANCNFSM6AAAAAAUHSSAUU> . You are receiving this because you commented.Message ID: ***@***.***>

[MikeFultonDev]

Also it talks about curl being a pre-req but the command pulls down perl

[wizardofzos]

Hey Mike,

If you want to package it yourself, yeah you need curl.... but the release (just pushed 1.2) has binaries attached with the installer already built. Just download the gitinstaller.sh and ship to you Mainframe, or download the zipped XMI, transfer, receive then copy to USS and run...

I've just put the 'installer creator' out there on GitHub so one can see how it's built, and people can build it themselves on LPARS that have a connection going out.... (as who in their right might would run a self-extracting-pax-file-mime-encoded-in-a-shell-script :) )
This is what running the installer looks like in v1.2

[MikeFultonDev]

@wizardofzos this is definitely a good idea. I took a peek into the script and it got me thinking:

• it would be nice if people with no connectivity to the 'real world' from their mainframe could have some sort of solution.
• What if we had some sort of tool that would let people sync up the latest vetted pax files from github.com to an internal server inside their firewall?
• a 'bundler' like your tool could pull them into a self-extracting blob they could upload to their mainframe?

[v1gnesh]

I'm afraid this goes into the territory of relying on existing artifact workflows in sites.
zOSMF natively pulling in artifacts (ideally, Portable Software Instances) via Nexus Repository / JFrog Artifactory.

IMHO, the earlier that these worlds overlap, the quicker & wider the adoption of zopen will be.
What do you think :) ?

[v1gnesh]

Also, fewer things to do (build) means getting up to speed quicker.
Ref - https://github.com/orgs/ZOSOpenTools/discussions/194
IBM & vendors could centralize the build, packaging, and release of these (through their GitHub Actions or whatever else), and provide PSIs or OCI artifacts. The latter may be stretching it though..

[MikeFultonDev]

@wizardofzos @lbdyck how close are we with the latest tools?
I think it would be pretty easy to create a simple 'wrapper' script that, after installing zopen tools, would then install a list of tools someone wants - which is just:
zopen init
zopen install

[wizardofzos]

I haven't had time lately tbh ;(

Still using that "pax package tool" in my own env and really works for me ;)