Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Samuelsson <ulf.samuelsson@atmel.com>
To: buildroot@busybox.net
Subject: [Buildroot] Creating a stable Buildroot release
Date: Sat, 03 Jan 2009 22:35:13 +0100	[thread overview]
Message-ID: <1231018513.8886.203.camel@linux-yrgm.site> (raw)

Since this was brought up, I think I'd better share my views.

?I think we should separate the build of the toolchain
and at the end of the toolchain build, we
should create files which gets included by 
the Buildroot file system Configs and Makefiles.

Possibly we should require a certain combination
of toolchain configs for a distribution.

For each stable version, I believe we should select *one*
version of each package and stay with that version.
We should not have to test multiple combinations 
We need to support a development version as well.

At the moment, we only know if a package is old, by
the disappearance of its tarball from Internet.
Would be good if someone figured out a way to
detect new packages.

Using a single version probably means that we need 
to have several makefiles
adn Config files for each package.
One per distribution.


?package--><package1>--><V1.0>-> <package1>.mk
				Config.in
       --><package2>--><V1.0>-> <package2>.mk
				Config.in

	...


        --><packagen>--><V1.0>-> <packagen>.mk
				 Config.in



When you release a new distribution, this becomes:

?package--><package1>--><V1.0>-> <package1>.mk
				Config.in
?			<V2.0>-> <package1>.mk
?				 Config.in
       --><package2>--><V1.0>-> <package2>.mk
				Config.in
?			 <V2.0>-> <package2>.mk
				? Config.in

	...


        --><packagen>--><V1.0>-> <packagen>.mk
				Config.in
?			 <V2.0>-> <packagen>.mk
?				 Config.in

One way to implement this is to maintain
files of package versions.
Alternatively, you store the info in each directory.

Ideally you would want to have a conditional include
but maybe we can achieve this using links.

include "versions"
foreach package
	ln -s distrib-1.0/socat repo/socat/?$(SOCAT_VERSION)
ln -s package distrib-1.0

Once we have a working distribution, we should be very careful
on checking in changes, and we should not update package
versions.
That could be done in release candidates in separate directories
under the main package directory.



Best Regards
Ulf Samuelsson

             reply	other threads:[~2009-01-03 21:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-03 21:35 Ulf Samuelsson [this message]
2009-01-04  1:37 ` [Buildroot] Creating a stable Buildroot release Daniel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1231018513.8886.203.camel@linux-yrgm.site \
    --to=ulf.samuelsson@atmel.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox