Re: [lmi] Using Git submodules for the dependencies

[Vadim Zeitlin]

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? Again, it
doesn't really bother me, and the bus factor is not that much of a concern
neither, because all these repositories are public and you could always
clone them and update the submodules to point to the new clones if
necessary, but it just seems like using an organisation/project account
would be tidier.

GC> I'm just leery of destabilizing anything right now. A major release
GC> will be distributed on Halloween, according to the latest plan, and
GC> I don't want to take any risks until that has gone out--so delaying
GC> (2) temporarily seems wise.

 OK.

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.

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.

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.

GC> > GC> > Of course, there is always the "when all you have is
GC> > GC> > Debian, any Linux looks like an OS where you can install it in a 
chroot"
GC> > GC> > approach, i.e. you could use debootstrap to create a chroot of 
Buster on
GC> > GC> > this machine and just do everything inside it with minimal 
drawbacks (a few
GC> > GC> > hundred of extra MiB of disk consumption).
GC> > GC> 
GC> > GC> Is that feasible? If so, it sounds like an excellent idea.
GC> > 
GC> >  I think it is... I've never done it in this direction, only the other
GC> > way round, but there is this package
GC> > 
GC> > 
https://rpmfind.net/linux/RPM/epel/7/x86_64/Packages/d/debootstrap-1.0.109-2.el7.noarch.html
GC> > 
GC> > and I guess it's at least supposed to work, if it exists. Should I try
GC> > creating a Debian chroot inside my (just installed) CentOS chroot?
GC> 
GC> Yes, please. If that works, then it resolves an entire category
GC> of problems, some of which I may not yet even have encountered.

 >>TODO

 Regards,
VZ

pgpdaSfCJzeer.pgp
Description: PGP signature