All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: Tom Rini <trini@konsulko.com>,
	Otavio Salvador <otavio@ossystems.com.br>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] u-boot: Update to 2016.01 release
Date: Fri, 15 Jan 2016 02:07:58 +0100	[thread overview]
Message-ID: <201601150207.58412.marex@denx.de> (raw)
In-Reply-To: <CAP9ODKocSQ0D4wRo-XpD9kYJ-V5hPSoWY+Yg2zFhv_Lp=vhjKw@mail.gmail.com>

On Friday, January 15, 2016 at 12:42:18 AM, Otavio Salvador wrote:
> On Thu, Jan 14, 2016 at 7:41 PM, Marek Vasut <marex@denx.de> wrote:
> > On Thursday, January 14, 2016 at 10:37:16 PM, Otavio Salvador wrote:
> >> On Thu, Jan 14, 2016 at 7:15 PM, Marek Vasut <marex@denx.de> wrote:
> >> ...
> >> 
> >> > Taking a look at u-boot.inc and uboot-config.bbclass makes me wonder
> >> > how all that could work at all. It's either a stackpile of legacy
> >> > cruft or just poor design.
> >> 
> >> I think it is a mix of both.
> >> 
> >> How would you address this in a clean way?
> > 
> > I would have one U-Boot build per package. Debian doesn't do it that way
> > tho, so their rationale might be something to consider here too.
> 
> This is what we do in uboot-config class, isn't it?

The class lacks documentation and is written in rather obscure way, so I am
not sure about how the result is packaged, sorry.

> Without going deep on the minor details, could you describe how you
> think it should be done?

Can you be more specific about this "it" ? What do you refer to ?

Best regards,
Marek Vasut


      reply	other threads:[~2016-01-15  1:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-13  3:36 [PATCH] u-boot: Update to 2016.01 release Marek Vasut
2016-01-13  4:49 ` Khem Raj
2016-01-13  5:01   ` Marek Vasut
2016-01-13  6:42     ` Khem Raj
2016-01-13 12:04 ` Otavio Salvador
2016-01-13 14:34   ` Marek Vasut
2016-01-13 15:39     ` Otavio Salvador
2016-01-13 15:53       ` Marek Vasut
2016-01-13 15:55         ` Otavio Salvador
2016-01-13 16:30           ` Marek Vasut
2016-01-13 16:40             ` Otavio Salvador
2016-01-13 17:09               ` Marek Vasut
2016-01-13 17:16                 ` Otavio Salvador
2016-01-13 17:42                   ` Marek Vasut
2016-01-13 17:56                     ` Otavio Salvador
2016-01-13 20:35                       ` Marek Vasut
2016-01-13 20:57                         ` Otavio Salvador
2016-01-13 22:09           ` Tom Rini
2016-01-14 20:43             ` Otavio Salvador
2016-01-14 21:15               ` Marek Vasut
2016-01-14 21:37                 ` Otavio Salvador
2016-01-14 21:41                   ` Marek Vasut
2016-01-14 23:42                     ` Otavio Salvador
2016-01-15  1:07                       ` Marek Vasut [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=201601150207.58412.marex@denx.de \
    --to=marex@denx.de \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio.salvador@ossystems.com.br \
    --cc=otavio@ossystems.com.br \
    --cc=trini@konsulko.com \
    /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.