Re: [Gumstix-users] gumstix-buildroot vs. vanilla/upstream buildroot?

[Craig H. <cr...@gu...>]

On Nov 23, 2006, at 2:05 PM, Alexandre Pereira Nunes wrote:

>> 4. There are some packages that only exist in one version.
>>
>>
>>
> Gumstix is not in sync with upstream, it was forked some time ago, and
> in the meanwhile packages were added independently to both buildroots.
> AFAIK there's no merging happening between the two trees.

Yup, that's more or less the case.  I forked off originally a long  
time back, before the directory structure change in the upstream  
buildroot.  Then the directory structure change happened, and it took  
me a while to merge that in successfully; I was planning on sending  
back changes I'd made then, but then got swamped with other stuff.   
The main problem with sending back up patches & changes I make is  
that I kind of cheat when making gumstix-specific changes to the  
buildroot.  Some changes/patches I apply will quite possibly (likely  
even?) break other systems, and buildroot is supposed to be something  
which targets lots of systems.  There are some cases where I could  
probably shoehorn stuff into working based on a "is this building for  
gumstix?" flag, but in many cases as far as I recall (without digging  
around for actual examples right now) this is not easy to do.

Basically, the bottom line is that I don't directly have a lot of  
time to weed my gumstix-specific stuff out of any variation between  
my buildroot and the upstream one in order to submit "clean" patches  
for them; but on the other hand, I do publish every line of every  
piece of code or patch I write, and it's all very well indexed by  
google, so chances are anyone trying to solve a problem in the  
upstream buildroot, or looking for a package which we've written  
the .mk for or whatever will probably find ours within about 10  
seconds of starting to look; hopefully then those folks (if they're  
working of the upstream buildroot in the first place) would be able  
to do the weeding out of gumstix stuff, and then have stuff more  
suitable for upstream.

Not a great "share alike" answer maybe, but I just fundamentally  
don't have a huge amount of time.  I'm doing the best I can to make  
the work I've done available to anyone (as well as making it as easy  
to find as possible), but that's about all I have time for  
unfortunately.  I have sent a handful of patches for specific  
packages back up to those packages' upstreams, and in many cases  
those do get folded in over time, thus end up in the upstream  
buildroot effectively anyway.

C