Openembedded Core Discussions
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox