Re: [lmi] Using Git submodules for the dependencies

[Vadim Zeitlin]

On Fri, 20 Sep 2019 18:45:06 +0000 Greg Chicares <address@hidden> wrote:

GC> Okay, I guess, though I'm not sure I understand the ramifications.
GC> Does this simply mean that we'd now add all the wx etc. sources to
GC> lmi's savannah repository? And that then, at our leisure, we could
GC> adjust makefiles and scripts to use those newly local sources? But
GC> that for now nothing would break--i.e., we could continue building
GC> as in the past, and it would still work?

 There are indeed 2 steps:

1. Adding submodules (note that this doesn't necessarily add them to
   Savannah repository, it just adds the pointers to whichever repository
   really contains them -- but it could, and probably is going to, be
   Savannah too, as per the discussion below).

2. Starting to use them instead of whatever we do now (i.e. clone remote
   Git repositories or downloading tarballs from SourceForge etc).

 Usually it makes sense to do both together because there is not much point
in having (1) if the submodules are never used. But if you'd like, we could
do this in 2 different steps. (1) will definitely be helpful to us, anyhow,
as the upcoming install_linux.sh could use the submodules, even if
install_msw.sh does not.

GC> We already use "third_party" somewhere, and I hesitate to change
GC> that to "3rdparty" because name changes cost something and I see
GC> little benefit to this particular one.

 Well, we don't use it in the repository itself, only in the makefiles
building third party libraries. But let's use "third_party", it's not a
problem.


GC> >  Similarly, I wonder where would you want the submodule URLs to point to.
GC> > We could just continue using https://github.com/wxWidgets/wxWidgets.git 
and
GC> > https://github.com/vadz/wxpdfdoc.git as we do now in install_wx*.sh, but
GC> > perhaps you want to use some repositories on Savannah instead? This can be
GC> > changed later, but if you already know which repositories do you want to
GC> > reference, it would make sense to start by using them immediately. Of
GC> > course, if you don't, then you don't really need to waste time thinking
GC> > about it and I can just use the same URLs as now.
GC> 
GC> Today, we depend only on gnu.org and other well-known free sites:
GC> the same kind of sites that debian depends on.

 Sorry, but this isn't really the case. install_wx.sh depends on GitHub as
it clones wx from https://github.com/wxWidgets/wxWidgets.git. And so does
install_wxpdfdoc.sh. And install_mingw.make depends on SourceForge, as it
downloads MinGW from http://downloads.sourceforge.net/ (which should
probably be changed to HTTPS nowadays). And we get other dependencies from
other sites (ftp://xmlsoft.org and https://storage.googleapis.com/, without
mentioning ftp://ftp.gnu.org/, which is not a problem from this point of
view).

GC> I very much want to keep it that way. I don't want to introduce a
GC> dependency on github, because of proverbs about Greeks bearing gifts
GC> and leopards changing their spots.

 I understand this argument and am not going to argue with it, although I
hardly believe that GitHub could disappear without a long transitional
period during which we'd have time to migrate from it. But I just want to
emphasize that we can't "keep it that way" because it isn't that way right
now. We could change it to be that way, however, by creating the
repositories containing the submodules on Savannah.

GC> I don't know. Maybe the version we have on redhat does support
GC> submodules, but its failure on
GC>   git clone jobs=
GC> caused me to question that.

 According to

https://github.blog/2016-03-28-git-2-8-has-been-released/#parallel-fetches-of-submodules

"--jobs" parameter of git-clone was added in Git 2.8, while Git version in
RedHat 7 is 1.8, which is almost 7 years old. But you have to install SCL
to get any reasonably recent versions of development tools under RedHat
anyhow, and there is rh-git218 which contains a version which is perfectly
usable with submodules.

 BTW, Git is also pretty easy (and fast) to compile from source.


GC> > Of course, there is always the "when all you have is
GC> > Debian, any Linux looks like an OS where you can install it in a chroot"
GC> > approach, i.e. you could use debootstrap to create a chroot of Buster on
GC> > this machine and just do everything inside it with minimal drawbacks (a 
few
GC> > hundred of extra MiB of disk consumption).
GC> 
GC> Is that feasible? If so, it sounds like an excellent idea.

 I think it is... I've never done it in this direction, only the other
way round, but there is this package

https://rpmfind.net/linux/RPM/epel/7/x86_64/Packages/d/debootstrap-1.0.109-2.el7.noarch.html

and I guess it's at least supposed to work, if it exists. Should I try
creating a Debian chroot inside my (just installed) CentOS chroot?

GC> If my debian system had no GUI; and forced me to use a
GC> little rubber keyboard with no Ins key at all (while many
GC> other keys require Fn, like Fn+UpArrow = PgUp), and a
GC> tiny screen, and a touchpad; and terminated any session
GC> after 15 minutes of inactivity--then I'd find debian
GC> pretty hard to use, too.

 Sorry if I'm just being obtuse, but why can't you ssh into this system
from a machine with a larger screen and better pointing device?

GC> Perhaps I should do the same. After actually installing
GC> fedora (before finding out that's not very close to redhat),
GC> for multi-booting (before you explained that there are
GC> better ways), I looked into installing a centos chroot,
GC> but it seemed like too much work for me, for too little gain.
GC> 
GC> But if you're going to do that anyway, maybe you could share
GC> your exact steps and I can just ride your coattails.

 I've documented the steps I used for creating my CentOS 7.6 chroot at

http://www.tt-solutions.com/en/articles/install_centos_in_debian_chroot 

Some of this might be unnecessary, e.g. I guess you could live without
pseudo-terminals if you always used [s]chroot to enter the chroot, but as I
have a setup in which I can ssh myusername-chrootname@localhost to enter a
chroot as if it were a remote machine, I do really need them (and handling
chroots and remote machines in the same way is convenient).

 Please let me know if anything in this small guide is unclear or doesn't
work for you.

 And also please let me know if you'd like me to create the mirrors for
everything we use at Savannah.

 Thanks,
VZ

pgpf1nyfdbzpR.pgp
Description: PGP signature