[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Using Git submodules for the dependencies
From: |
Greg Chicares |
Subject: |
Re: [lmi] Using Git submodules for the dependencies |
Date: |
Wed, 25 Sep 2019 12:36:09 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
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 –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 ?
- Re: [lmi] Using Git submodules for the dependencies, (continued)
- Re: [lmi] Using Git submodules for the dependencies, Greg Chicares, 2019/09/20
- Re: [lmi] Using Git submodules for the dependencies, Vadim Zeitlin, 2019/09/20
- Re: [lmi] Using Git submodules for the dependencies, Greg Chicares, 2019/09/20
- [lmi] debian chroot in redhat [Was: Using Git submodules for the dependencies], Greg Chicares, 2019/09/20
- Re: [lmi] debian chroot in redhat, Vadim Zeitlin, 2019/09/24
- Re: [lmi] debian chroot in redhat, Greg Chicares, 2019/09/26
- Re: [lmi] debian chroot in redhat, Vadim Zeitlin, 2019/09/27
- Re: [lmi] Using Git submodules for the dependencies, Vadim Zeitlin, 2019/09/21
- Re: [lmi] Using Git submodules for the dependencies, Greg Chicares, 2019/09/23
- Re: [lmi] Using Git submodules for the dependencies, Vadim Zeitlin, 2019/09/23
- Re: [lmi] Using Git submodules for the dependencies,
Greg Chicares <=
- Re: [lmi] Using Git submodules for the dependencies, Vadim Zeitlin, 2019/09/25
- [lmi] Mounting proc and devpts for chroot [Was: Using Git submodules for the dependencies], Greg Chicares, 2019/09/23
- Re: [lmi] Mounting proc and devpts for chroot [Was: Using Git submodules for the dependencies], Greg Chicares, 2019/09/23
- Re: [lmi] Mounting proc and devpts for chroot [Was: Using Git submodules for the dependencies], Vadim Zeitlin, 2019/09/23
- Re: [lmi] Mounting proc and devpts for chroot [Was: Using Git submodules for the dependencies], Greg Chicares, 2019/09/23
- Re: [lmi] Mounting proc and devpts for chroot [Was: Using Git submodules for the dependencies], Vadim Zeitlin, 2019/09/23
- Re: [lmi] Mounting proc and devpts for chroot [Was: Using Git submodules for the dependencies], Greg Chicares, 2019/09/24