[Aboriginal] Build from version control system repos instead of from tarballs (Rob Landley)

[Isaac Dunham]

> On 10/30/2012 03:49:56 AM, Alessio Igor Bogani wrote:
> > Hi Rob,
> > 
> > On 30/10/2012 03:36, Rob Landley wrote:
> >> On 09/04/2012 03:49:07 AM, Alessio Igor Bogani wrote:
> >>> Can Aboriginal grabs sources from git(Linux, musl, uclibc, busybox)
> >>> and hg(toybox) repos instead of from tarballs?
> >> populating the package cache from the git repo, and
> >> Really what I want to do is say "URL=git://busybox.net/busybox" in
> >> download.sh, have that clone the relevant repo under packages (so
> >> packages/busybox would be a directory), and then just use that as the
> >> package cache version.
> >> 
..
> > Personally I don't use tarballs at all anymore: I'll download the  
> > project's repo and build from it. I'm very happy if Aboriginal let me  
> > work in this way.
> 
> It currently does, using a two step process:
> 
> 1) Edit "configure" and add the packages you want to do git versions of  
> to the USE_ALT variable.  (USE_ALT=busybox,uClibc,linux)
> 
> 2) Then check out your repos into build/packages/alt-busybox and  
> build/packages/alt-uClibc and so on.
 
For what it's worth, it would be quite possible to just use 
"git clone $URL alt-$PACKAGE"

> > For example (sorry in git-ish):
> > 
> > git clone aboriginal
> 
> I'm vaguely interested in having a git mirror of the mercurial repo,
That would be enough for this purpose, AFAICT.  
> but I have no interest in hosting any of my projects in git. The git
> user interface is appalling, and their solution to all their problems  
To each his own (I actually enjoy it)
> is to expose implementation details to the user.

> > cd aboriginal/ && ls
> > build.sh config cross-compiler.sh .. (these should works with any  
> > version and doesn't
> > care if gcc is 4.2.2 or 4.7.1)
> 
> The build script required for 4.2 and 4.7 are _totally_different_.  
> For one thing, newer gcc versions have something like 4 prerequisite  
> packages you have to build first, requirements 4.2 didn't have.
> 
> Unfortunately, your desire doesn't match reality there.
> 
> > ls package/linux (<- this is a submodule)
> > git submodule init
> > git submodule update
> > cd package/linux
> 
<snip long discussion of why it isn't a good idea>

> > git reset --hard origin (reset to the Linus' HEAD)
> > (don't change anything other aka let's use Rob's default versions)
> > ./build i686-virtio
> 
> How about this:
> 
> I can modify the scripts so that if there's a directory under packages  
> with the package name, we use that source verbatim. (No patches, no  
> nothing.) Otherwise, we fall back to the current behavior. (Basically  
> it's just implementing a search path for the package cache with the  
> first entry searched before attempting to _populate_ the package cache.)

Be sure to make {,dist,real}clean...
Otherwise, sounds reasonable to me.
 
> > Why I bother with this crazy request? Because In this way I can  
> > handle multi-level
> > changes in a very simple way. So if I want add a feature which 
> > needs to change/patch
> > kernel, libc and application I could treat this like a single 
> > atomic commit.
Doesn't this make tracking down what caused breakage harder?
ie, if you git bisect to an atomic commit in all three, you can't 
tell if the kernel or the libc patch is responsible.

> Which would never go upstream.
> 
> My build uses clean vanilla release versions of upstream packages, and  
> separates out all the patches (and I try to send those patches upstream  
> so I don't have to carry them, with varying success).
> 
> This is a design decision, so you can see what I'm using and what I did  
> to it.
> 
> Your suggestion makes things easier for you at the expense of making it  
> harder for anybody else to see what you did or reproduce it outside  
> your build system. That's fine for your purposes, but that's not what  
> I'm after.
Note that this could make GPL conformance (where it matters) a little harder-otherwise, patches plus tarballs are enough, but this may mean you need to make the repo public (I'm not sure how git archive would work with submodules, though)

OTOH, if you're using a branch for all your patches, it may make development simpler.
<snip>
> I'm happy to make the build more flexible, and I _want_ my code to to  
> stay out of your way so you can do what you want to do. I want to make  
> it trivially easy to overlay "git submodule" on top of the build, but  
> my build is not becoming dependent on git submodule.

-- 
Isaac Dunham <idunham at lavabit.com>