All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Samuelsson <ulf@atmel.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC] Support for "distributions" in buildroot
Date: Sun, 22 Jul 2007 17:03:22 +0200	[thread overview]
Message-ID: <00f201c7cc71$8bf68c30$dcc4af0a@atmel.com> (raw)
In-Reply-To: 20070722145155.GA27429@zelow.no

> 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.

At one stage, it is likely that the user wants to swap from the snapshot
to the current svn.

> 
> the downside is that it will be an easier path for the user to fork and
> work on his own snapshot.
> 
According to Stephen, forking is a preferred method...
Personally, I want to avoid forking!

>> 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.
> 

It is not mutually exclusive.  I do like having a separate directory as well.
Sometime patches has to be applied in a certain order,
and then you need either to name it in directory order (which I don't like)
or you have a list of patches in the correct order.

>> 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.
> 
> 

Which needs to be answered by those not ack'ing the distribution patch!

Best Regards
Ulf Samuelsson

      reply	other threads:[~2007-07-22 15:03 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
2007-07-22 15:03           ` Ulf Samuelsson [this message]

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='00f201c7cc71$8bf68c30$dcc4af0a@atmel.com' \
    --to=ulf@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.