Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Andreas Oberritter <obi@opendreambox.org>
To: Leandro Dorileo <leandro.maciel.dorileo@intel.com>,
	 Bruno Bottazzini <bruno.bottazzini@intel.com>,
	openembedded-core@lists.openembedded.org
Subject: Re: [PATCH V5 3/3] systemd: split modules into packages
Date: Tue, 16 Jun 2015 21:09:35 +0200	[thread overview]
Message-ID: <5580746F.8000305@opendreambox.org> (raw)
In-Reply-To: <5580690B.9070908@intel.com>

Hello Leandro,

On 16.06.2015 20:20, Leandro Dorileo wrote:
> On 05/13/2015 07:41 PM, Andreas Oberritter wrote:
>> Hello Bruno,
>>
>> On 13.05.2015 23:51, Bruno Bottazzini wrote:
>>> +########################################################################
>>>
>>> +# Aggregation of Split Packages
>>> +########################################################################
>>>
>>> +PACKAGES =+ "${PN}-services-base"
>>> +SUMMARY_${PN}-services-base = "Base services aggregation"
>>> +ALLOW_EMPTY_${PN}-services-base = "1"
>>> +RDEPENDS_${PN}-services-base = " \
>>
>> I think it would be better to use RRECOMMENDS, in order to support
>> BAD_RECOMMENDATIONS per image. This would also remove the need to use
>> bb.utils.contains, because unavailable recommended packages get ignored
>> by the package managers.
> 
> 
> In the end, isn't it just a different approach? a different way of
> doing the same thing?

No. Although recommended packages get installed by default, just like
depended-upon packages, the difference is that you can choose to
uninstall these packages selectively or to disable automatic
installation using "BAD_RECOMMENDATIONS".

If you choose this route, then it doesn't make a difference whether you
use bb.utils.contains(...) for each package or not when declaring the
relationship between packages (unless you keep old packages on your
update feeds). I just mentioned that, because the patch is already hard
to read and any simplification in syntax may be a plus. I don't think
it's important though.

> By the way, from my point of view, semantically
> we're saying "we want a given package feature" besides the "we want a
> given distro feature", don't you think?

I can't follow you, sorry. At this point, PACKAGECONFIG already
determined which files got built, installed and packaged. I fail to
connect this to distro features in this context, besides its use for
sane defaults of the PACKAGECONFIG variable.

Regards,
Andreas


  reply	other threads:[~2015-06-16 19:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 21:51 [PATCH V5 0/3] systemd: split modules into packages Bruno Bottazzini
2015-05-13 21:51 ` [PATCH V5 1/3] dbus: split tools package Bruno Bottazzini
2015-05-13 21:51 ` [PATCH V5 2/3] systemd: removing workaround odering journal after remote-fs.target Bruno Bottazzini
2015-05-13 21:51 ` [PATCH V5 3/3] systemd: split modules into packages Bruno Bottazzini
2015-05-13 22:41   ` Andreas Oberritter
2015-05-19 13:18     ` Bottazzini, Bruno
2015-06-05 16:52       ` Bottazzini, Bruno
2015-06-16 18:11         ` Bottazzini, Bruno
2015-06-16 18:46           ` Andreas Oberritter
2015-06-16 18:20     ` Leandro Dorileo
2015-06-16 19:09       ` Andreas Oberritter [this message]
2015-06-17  8:27       ` Anders Darander

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=5580746F.8000305@opendreambox.org \
    --to=obi@opendreambox.org \
    --cc=bruno.bottazzini@intel.com \
    --cc=leandro.maciel.dorileo@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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