[Buildroot] Buildroot maintainer and stable releases

Thomas Lundquist lists at zelow.no
Wed Jan 7 18:02:08 UTC 2009

On Wed, Jan 07, 2009 at 01:34:23PM +0100, Ulf Samuelsson wrote:
> We need to differentiate between testing and releases.
> I have already made the comment, that I believe 
> a distribution should use a single version of the source
> (with patches).

That's what tags, branches and releases are for. 
Having separate makefiles sounds messy.

> I am talking about the process of getting a package
> into the stable distribution, and currently there
> is no process of doing this.

You could tag each package in Config.in or something 
with "UNTESTED" "TESTING" or whatever aswell, then change or remove when
we know it works.

(Or just use EXPERIMENTAL as other projects does)

> Your goal of a single source package that will not break
> for any supported architecture will thus be met by the 
> packages IN the distribution. Packages outside
> the distribution are not supported.

This is another story, maybe we should support contrib/*.* like you 
once had with local/ for out-of-tree packages and boards.

> It will also allow people to build old distributions.

That's why we have version control. Just check out an earlier

> When it is time to look at a new release, then
> it is easy to check what has been introduced
> since the last distribution, and create 
> the version file for the new testing phase.

NEW (and oldconfig)

> If it does not build, then it is set to broken
> for that architecture.

What you are suggesting here is a package-tagging about the status 
of the package per ARCH.

This would suggest a new file per package with metainfo (Which could be used
to make Config.in since we'd rather not duplicate information.)

> If the problem can be fixed with a patch, then
> a new directory is created with the patch.

As long as we keep having only one version of each package we won't need
to do this.


More information about the buildroot mailing list