Re: [lmi] Using Git submodules for the dependencies

[Greg Chicares]

On 2019-09-23 21:38, Vadim Zeitlin wrote:
> On Mon, 23 Sep 2019 18:48:10 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-09-21 21:48, Vadim Zeitlin wrote:
> GC> > On Fri, 20 Sep 2019 18:45:06 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> Okay, I guess, though I'm not sure I understand the ramifications.
> GC> > GC> Does this simply mean that we'd now add all the wx etc. sources to
> GC> > GC> lmi's savannah repository? And that then, at our leisure, we could
> GC> > GC> adjust makefiles and scripts to use those newly local sources? But
> GC> > GC> that for now nothing would break--i.e., we could continue building
> GC> > GC> as in the past, and it would still work?
> GC> > 
> GC> >  There are indeed 2 steps:
> GC> > 
> GC> > 1. Adding submodules (note that this doesn't necessarily add them to
> GC> >    Savannah repository, it just adds the pointers to whichever 
> repository
> GC> >    really contains them -- but it could, and probably is going to, be
> GC> >    Savannah too, as per the discussion below).
> GC> 
> GC> I think we need copies rather than pointers. Our corporate server blocks
> GC> almost everything except github.
> 
>  OK, but we already have most of things on GitHub. I can create
> repositories for the ones that are not available there, but it just seems
> strange to have them under my "vadz" account namespace. I remember your
> misgivings about creating GitHub account, but maybe I could create another
> account myself somehow more appropriate for these repositories?

Sure.

> GC> > But you have to install SCL to get any reasonably recent versions of
> GC> > development tools under RedHat anyhow, and there is rh-git218 which
> GC> > contains a version which is perfectly usable with submodules.
> GC> 
> GC> According to
> GC>   https://www.softwarecollections.org/en/scls/rhscl/rh-git218/
> GC> it should be as easy as this:
> GC> 
> GC> sudo yum-config-manager --enable rhel-server-rhscl-7-rpms
> GC> sudo yum install rh-git218
> GC> scl enable rh-git218 bash
> 
>  Yes, it should be as simple as this. I haven't used the real RHEL since a
> very long time (last one I used was 3 or maybe 4, I think), but there is no
> reason for this to be more complicated there than under CentOS, where the
> same commands worked without any problem for me.

Now that I'm digging into this more deeply, I noticed:
> GC> scl enable rh-git218 bash
                           ^^^^
"bash"?

  https://access.redhat.com/solutions/527703
| When I reboot or logout of my machine, all my enabled software collections
| are disabled, and do not persist.
...
| The usual way to enable software collections for whole sessions is to run
| a new bash wrapped with "scl enable" call, for example like that:
|   $ scl enable mysql55 bash
...
| The following is considered to be a work-around only, because we don't have
| a supported way to do it correctly now.
...
| How the software collection concept works: The difference between running
| python from a software collection and core system's python is only in
| environment variables defined at a time you run python command. These
| variables are set using "scl enable python33 ..." call, which basically
| executes a bash script located in /opt/rh/python33/enable.
...
| $ cat /etc/profile.d/enablepython33.sh
| #!/bin/bash
| source scl_source enable python33
...
| NOTE: However, there is a side effect with this approach in that
| you cannot disable the collections thereafter. Also, shebang in
| the script affects which interpreter will be used.

We want zsh. So I guess we could do something like this:

sudo su -

cat >/etc/profile.d/use_git218.sh <<EOF
#!/bin/zsh
source scl_source enable rh-git218
EOF

chmod +x /etc/profile.d/use_git218.sh

Why do they say "you cannot disable the collections thereafter"?
I'm a sudoer, so I should be able to do anything; surely I could
  rm /etc/profile.d/use_git218.sh
and then the collection would be disabled?

> GC> But is that likely to break anything else?
> 
>  No, it won't. Just to be clear, "scl enable <collections...> <command>"
> launches the command in the environment where collections can be used, i.e.
> it sets up PATH, LD_LIBRARY_PATH etc accordingly. Outside of this
> particular bash session, nothing changes whatsoever. Installing an SCL just
> dumps its files under /opt/rh.

I haven't logged in to the server to try this yet, but...couldn't
I just set PATH and LD_LIBRARY_PATH myself (in my own ~/.zshrc e.g.)
and not touch anything like /etc/profile.d ?

I'm reluctant to change a system-wide profile because any mistake
might make logging in impossible. That already happened once, when
we copied a line like
  exec /bin/zsh -l
from email into ~/.bash_login , but corporate email is 'outlook',
which altered that line to something like
  exec /bin/zsh &ndash;l
and locked us out. (Fortunately, we have two sudoer accounts and
were able to fix it ourselves.)

> GC> IOW, would we just be yum-ing git from some alternative place, like
> GC> grabbing a single package from debian-testing--with no effect on any
> GC> other package?
> 
>  rhscl-7-rpms is another "yum source" (by analogy with "apt sources"), but
> my understanding is that it only contains packages not present in the main
> repositories (which is why Git package is called rh-git218 and not just
> "git"), so it doesn't interfere with the main system at all.

Then wouldn't it be even easier to set up an alias like
  alias git="/opt/rh/rh-git218'
in our own ~/.zshrc ?