Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [RFC - WIP v2 01/10] conf-files: New recipe to create single recipe for config files
Date: Fri, 13 Jun 2014 09:06:37 +0100	[thread overview]
Message-ID: <1402646797.12440.477.camel@ted> (raw)
In-Reply-To: <CAP9ODKobCoJiCmLZ+-JwoZB8hBZdTSn0jX0bbmgFtosWXVJ2WQ@mail.gmail.com>

On Thu, 2014-06-12 at 10:57 -0300, Otavio Salvador wrote:
> On Thu, Jun 12, 2014 at 2:56 AM, Saul Wold <sgw@linux.intel.com> wrote:
> > This recipe will create 1 package for config files, we could optionally add
> > a bbclass file to ensure consistency with RRECOMMENDS_ = =conf
> >
> > This is a work in progress, the do_install might even beable to automagically
> > generated.  We don't want to create a bbclass for these since it will cause
> > the actual recipe/packaging to become machine specific, using this recipe will
> > ioslate that.
> >
> > [YOCTO #4011]
> >
> > Signed-off-by: Saul Wold <sgw@linux.intel.com>
> 
> I think the configuration file, nowadays, already made those machine
> specific in every BSP which has those overriden so I don't see why use
> a single recipe to provide several configuration files.
> 
> I think it will be confusing and this recipe will fast grow.

There are a few good reasons to do this. 

Machine customisation is spread around a whole load of different recipes
at the moment and its hard to obtain a good view of what files are
available and which ones a BSP author may need to provide.

Its rather ugly to have to provide and maintain multiple bbappend files
with rather ugly syntax within them. Its also rather inefficient from a
build process standpoint to have 15-20 recipes just packaging
configuration files.

The intent isn't to mandate *every* config file should be in this
recipe, you will as now be able to add additional ones. Where we see the
same files being added in many layers, adding something common and
shared makes sense though.

It should in some cases also allow the "core" recipe to stop being
machine specific and shared, improving build efficiency. There is little
point in a recipe becomming machine specific over a config file.

So I'd consider this move a consolation which we can improve over time.
For new users I'd suggest that one more common place for the majority of
machine specific files would be more understandable too.

Cheers,

Richard




  reply	other threads:[~2014-06-13  8:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12  5:56 [RFC - WIP v2 00/10] conf-files: New recipe to consolidate config file Saul Wold
2014-06-12  5:56 ` [RFC - WIP v2 01/10] conf-files: New recipe to create single recipe for config files Saul Wold
2014-06-12 13:57   ` Otavio Salvador
2014-06-13  8:06     ` Richard Purdie [this message]
2014-06-13 15:30       ` Otavio Salvador
2014-06-13 15:40         ` Richard Purdie
2014-06-13 16:10           ` Mark Hatle
2014-06-12  5:56 ` [RFC - WIP v2 02/10] apmd: convert to use conf-files Saul Wold
2014-06-13 10:35   ` Paul Eggleton
2014-06-12  5:56 ` [RFC - WIP v2 03/10] alsa-state: " Saul Wold
2014-06-12  5:56 ` [RFC - WIP v2 04/10] formfactor: convert to conf-files Saul Wold
2014-06-12  5:56 ` [RFC - WIP v2 05/10] connman: convert to use conf-files Saul Wold
2014-06-12  5:56 ` [RFC - WIP v2 06/10] init-ifupdown: " Saul Wold
2014-06-12  5:56 ` [RFC - WIP v2 07/10] pointer: convert to conf-files and remove Saul Wold
2014-06-12  5:56 ` [RFC - WIP v2 08/10] xserver-xf86-config: convert to use " Saul Wold
2014-06-12  5:56 ` [RFC - WIP v2 09/10] pointercal-xinput: convert to " Saul Wold
2014-06-12  5:56 ` [RFC - WIP v2 10/10] xorg-config: move xorg.conf files into conf-files as bbappend Saul Wold
2014-06-13 13:30 ` [RFC - WIP v2 00/10] conf-files: New recipe to consolidate config file Paul Eggleton

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=1402646797.12440.477.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio@ossystems.com.br \
    /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