From: Thomas Lundquist <lists@zelow.no>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC] Support for "distributions" in buildroot
Date: Sun, 22 Jul 2007 16:51:56 +0200 [thread overview]
Message-ID: <20070722145155.GA27429@zelow.no> (raw)
In-Reply-To: <002501c7cc4a$65c56530$dcc4af0a@atmel.com>
On Sun, Jul 22, 2007 at 09:08:50AM +0200, Ulf Samuelsson wrote:
>
> I see buildroot as a promising tool to allow newbies to get running
> with embedded linux, and the goal of most of my efforts are to
> reduce the obstacles for the user.
I also think this is a nice goal.
> When the newbie wants to start developing a product
> then ideally it is good to use the latest version of packages,
> but if that fails, then having a distribution where at least the
> packages have been known to cooperate is a good thing.
which is where he'd better use the snapshot anyway.
the downside is that it will be an easier path for the user to fork and
work on his own snapshot.
> Instead of just applying "*.patch", I much prefer that the makefile fragment
> use a file with a list of patches which should be applied to the tarball.
>
> Each supported package version then only needs its list of files ("series"?).
> If a new version with new patches is added, then that needs
> a separate "series" file.
I'd rather have a separate patch directory for each version instead of
files. then the user can just drop his own patch in that directory
without having to edit a file that is in svn.
> Adding a new patch for a new version will then not cause a problem,
> since the "series" file for the old version is not updated.
> Patches can be shared between different versions, something which is not
> possible if we use the current method "<package>-$(version)-<name>.patch".
svn handles softlinks..
> It would also be good if there were a structured way to have some patches
> downloaded from internet, instead of the ad-hoc methods used today.
as you already have said, downloading from the internet can be annoying
because the patches or source tarballs can disappear.
> - What happens if one architecture needs version 'A',
> and another architecture needs version 'B'?
it is a good question indeed.
Thomas.
next prev parent reply other threads:[~2007-07-22 14:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-20 12:30 [Buildroot] [RFC] Support for "distributions" in buildroot Ulf Samuelsson
2007-07-20 14:04 ` Steven J. Hill
2007-07-20 22:34 ` Ulf Samuelsson
2007-07-21 18:42 ` Thomas Lundquist
2007-07-22 7:08 ` Ulf Samuelsson
2007-07-22 14:51 ` Thomas Lundquist [this message]
2007-07-22 15:03 ` Ulf Samuelsson
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=20070722145155.GA27429@zelow.no \
--to=lists@zelow.no \
--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