[lfs-dev] Git

Ken Moffat zarniwhoop at ntlworld.com
Thu Feb 25 09:59:52 PST 2016

On Thu, Feb 25, 2016 at 06:08:21AM -0700, Roger Koehler wrote:
> Has anyone on this list tried tracking all of the LFS sources using git? I
> think it would be awesome if we could list git clone instructions for each
> of the packages listed.

To what end ?  If I am reading you correctly, you want to clone all
upstream git trees.  If you want to use svn-to-git on the LFS
projects, then I have misunderstood and you can stop reading now.
But if I understood correctly, then I guess you either want to run
the "latest and hopefully greatest" (aka as "bleeding edge"), or
else you want an easier way to find commits which fix a bug you are

Both are worthwhile, to an extent, but probably more so in BLFS.
There are a number of potential problems with using the latest
versions of everything (even fedora and debian sid are not always
using the latest - I needed some Python package t'other day and
inadvertently downloaded an alpha release tarball (it had an a in
the version, something like 1.4a which I assumed was an improved
version of 1.4, then later wondered why fedora was using 1.3.1 -
there was a 1.3.5 source when I looked again.)

The big problem with using the latest version of everything is, of
course, deciding which package caused a runtime problem.

More generally, even packages which use git have different
processes, e.g. kernels go through a several-week -rc process, then
after release there is an equally long (or short, if you think 6 to
8 weeks is short) time where a stable kernel is maintained.  Then
one, or maybe two, kernels per year get long-term support (but by
that stage LFS has usually moved on).

For other packages, things can be very different - development
might happen only in one or more branches until just before
release, possibly with throwaway (non-public, temporary)
integration test branches on a build machine if there are multiple
branches (so, a bit like linux-next, but not necessarily with an
available merged branch), or all changes might go into master.

I'm not sure about all the packages in LFS, but I will be surprised
if all of them are using git.

The result of this, as I see it, is that you need to understand how
a particular upstream is currently doing its development.  Only then
can you make a sensible decision about which branch(es) to clone.
And to understand the development, I guess that a mailing list for
that project is probably the best place to start.

This email was written using 100% recycled letters.

More information about the lfs-dev mailing list