public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Sinan Kaya" <okaya@kernel.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [meta-oe][PATCH v2] procps: split into binary subpackages
Date: Tue, 1 Dec 2020 11:49:54 -0500	[thread overview]
Message-ID: <278a2145-7ebe-ea4b-375c-c2e65e69a06a@kernel.org> (raw)
In-Reply-To: <5b161d2cc31540dc73c42df6068e0ef7f69574f2.camel@linuxfoundation.org>

On 12/1/2020 10:07 AM, Richard Purdie wrote:
> On Tue, 2020-12-01 at 09:39 -0500, Sinan Kaya wrote:
>> On 12/1/2020 9:30 AM, Otavio Salvador wrote:
>>>>>> I am starting to get a little worried about the direction these
>>>>>> patches
>>>>>> are heading in. How much of the system are we going to split into
>>>>>> individual package per binaries?
>>>>> I am wondering why this is a concern for you? If we keep the old
>>>>> package rdepends on the new ones I see no problem in allowing this
>>>>> granular packaging.
>>>> Taking this to a conclusion its heading towards, most recipes
>>>> generating more than one binary would end up with this splitting code.
>>>> I don't like having large blocks of python in each recipe and heading
>>>> that way means we should probably change approach somehow.
>>>>
>>>> My worry is that simpler recipes are easier to maintain, test and
>>>> upgrade.
>>> Maybe Sinan could try to rework this and move the python code to a
>>> class reducing code duplication?
>>
>> The problem I'm trying to solve is I only need ps file out of this
>> entire package. Everything else in this package is useless for me. I'm
>> sure no-one wants dead code in their system especially if they are size
>> constrained.
>>
>> Ideal solution would be to have --with/without-foo support upstream
>> that we can configure with PACKAGECONFIG.
>>
>> I'm happy to look at other options if there is an alternative.
> 
> The question is how many other packages are you going to need just one
> thing out of?
> 
> You might want ps, someone else might want something different. We've
> had this problem a lot with util-linux and e2fsprogs so we split those
> in the end as the patches were getting painful.
> 
> If this is a widespread issue we might want to have a generic class,
> kind of like lib_package but for splitting the binaries into individual
> packages.
> 
> I just need an idea of how big this problem is going to be as I don't
> want to iterate over half the recipes in oe-core over the next 9
> months! :)

I see. In terms of my project requirements, the only package that I'm
planning to go after like this is sudo.

We should not open the path for subpackages across the board. We need to
prefer PACKAGECONFIG as the right option.



      reply	other threads:[~2020-12-01 16:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01  3:43 [meta-oe][PATCH v2] procps: split into binary subpackages Sinan Kaya
2020-12-01 10:37 ` [OE-core] " Richard Purdie
2020-12-01 11:29   ` Otavio Salvador
2020-12-01 14:15     ` Richard Purdie
2020-12-01 14:30       ` Otavio Salvador
2020-12-01 14:39         ` Sinan Kaya
2020-12-01 15:07           ` Richard Purdie
2020-12-01 16:49             ` Sinan Kaya [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=278a2145-7ebe-ea4b-375c-c2e65e69a06a@kernel.org \
    --to=okaya@kernel.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio.salvador@ossystems.com.br \
    --cc=richard.purdie@linuxfoundation.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