[Buildroot] Buildroot maintainer and stable releases
ulf.samuelsson at atmel.com
Wed Jan 7 23:28:53 UTC 2009
ons 2009-01-07 klockan 20:36 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson at atmel.com> writes:
> >> That's what tags, branches and releases are for.
> >> Having separate makefiles sounds messy.
> Ulf> I am not an expert in Source Code Management,
> Ulf> but do you have this capability in Subversion?
> Ulf> I know you have it in git, but using git
> Ulf> is apparently not an option.
> Yes, ofcourse you can do it in svn, and as I said, git is coming.
> Ulf> I do not see it as too messy to use directories.
> I do - But more importantly, it would just keep on growing, making it
> harder and harder to test everything.
That is not my intention.
Let me provide an example:
assume we work with the dbus package.
the file ".distribution" contains
Ok, so I want to update to dbus-1.1.2
I copy the directory 1.1.1 to 1.1.2-arm and add a patch
the file ".distribution-1.0" still contains
but I add
so now whenever I build, I will use my own version,
and if someone adds a powerpc version with another fix
and we get.
When we enter the test phase we create a merged testing directory
is added to ".distribution-2.0.testing"
Once all the packages selected by the merge of
".distribution-1.0" and ".distribution-2.0-testing"
can be built with the ARM architecture
you can commit the following addition to the
You then prune the directory structure to get:
At that point you also freeze "1.1.1"
No more changes are allowed so there will be
little and no more support.
This is a VERY important thing, because
otherwise we end up in the support nightmare
that you rightfully are scared of.
Assume that we do 5 distribution and one
poor package gets a new version every time
so you have 5 version directories
I do not suggest that we use KConfig to
allow the user to select which of the 5
versions he/she wants to use.
Again that will end up in a support nightmare
since packages mightr depend on that other packages
have a certain version.
The user will only use Kconfig to select
which *package* and not which *version*.
Either the user selects a distribution
and then he will be limited by which
packages are tested for that distribution
and might also be limited by the architecture.
Or he disables the distribution system
and can build anything he wants, but
then this is not a supported activity.
He STILL cannot select the version with Kconfig.
If the move from dbus-1.1.1 would break the powerpc
architecture, you would be able
to have ".distribution-2.0-powerpc"
This file might be created at the release of distribution-2.0
but can be overridden by a new
in local files by developers so they can continue
working on the powerpc versions all the time
and do not have to care about release cycles.
Eventually dbus-1.1.2 is working for the powerpc
and ".distribution-3.0" could contain.
and ".distribution-3.0-powerpc" could be empty.
If the distribution does not change package versions
then of course there will be no added directory.
If you want to test if a certain distribution works
for an architecture, you will only have one version
of each package to test.
If you are doing development for a new distribution
you again will only have one package version to test.
Even if we eventually end up with multiple versions
for each and every package, the distribution mechanism
will only support one version per package per
I do not think that it is a good idea to check
in two or more versions when we create a new distribution
The distribution will allow max one added version per package
but it should be OK to allow an architecture to keep
an old revision of a package, if the new version breaks,
but the old CAN NOT be modified, even for bug fixes.
A developer avoiding or overridign the distribution
mechanism can using override files use each an any
apcakage in whatever version they want,
including test versions, but we need to prune
aggressively after a new release.
We should document the last revision before pruning begins
so that people can retrieve the work on a non-completed
package which did not make it into the new distribution
and create new testing directories preparing for
the next distribution.
I really think this would work
and would be better than just tarballing
the tree and then put it on a webpage.
If we can achieve the same functionality
with a SCM, then I am fine with this.
I am not convinced yet though.
Parts can be done with the SCM, I am sure,
but can you get the flexibility?
Automatically adding/creating the config enables
and the distribition files would be good.
More information about the buildroot