octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib now a subrepo


From: Rik
Subject: Re: gnulib now a subrepo
Date: Thu, 17 Nov 2011 22:00:59 -0800


Date: Thu, 17 Nov 2011 22:17:48 -0500
From: Jordi Guti?rrez Hermoso <address@hidden>
To: Octave Maintainers List <address@hidden>
Subject: gnulib now a subrepo

tl;dr: make sure you have at least Mercurial 1.8 from now on,
otherwise, business as usual.

Following a discussion in #octave, we decided that saying "have you
updated gnulib?" isn't always the best thing to do, because gnulib can
change and leave us stranded in the middle in a broken state. Trying
to fix this, the hash of the gnulib revision is now versioned in each
hg cset in a subrepository. I currently set the gnulib revision to
84c3f9cf54eaa688c5a1a26925886535079a91de since that's what Kai Habel
reported was working.

If you're curious to know how it works, read on. If not, it should all
be handled automatically from now on *IF* you have Mercurial 1.8 or
later. If not, I'm not sure what will happen, but it probably won't be
pretty. Mercurial 1.8 isn't hard to obtain (even Debian stable has it
in a subrepo!) so I don't see any reason for anyone to be using an
older hg.
One reason is a dislike of sysadmin activities.  I run the Long Term Release version of Kubuntu (from 4/2010) so that things stay more or less stable for a few years.  Currently, I'm only on version 1.4 of Mercurial.  I guess I'll try and find a PPA for it.
There is now an .hgsub file at the top-level directory that should map
the gnulib/ directory to its Savannah URL. Additionally, there is an
.hgsubstate file under hg control that tracks the gnulib revision that
is known to work with this particular commit. When we decide to update
the gnulib revision, go into the gnulib/ directory, run whatever git
incantations are necessary to update ("git pull" and perhaps "git
checkout $githash" should be enough), test that most things work, and
commit one directory above. hg will automatically update the
.hgsubstate file and this git revision will now be associated to this
hg revision.
Does this invalidate the --gnulib-srcdir option to configure?  Since compilation from scratch takes so long, I have made several copies of the Octave code tree which have been compiled with different options.  However, they all point to a single gnulib installation which I update from time to time.  I deliberately do not update gnulib too frequently because there are bad revisions out there.

--Rik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]