All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Paul Eggleton <bluelightning@bluelightning.org>,
	 openembedded-core@lists.openembedded.org
Cc: luca.boccassi@gmail.com
Subject: Re: [OE-core] [PATCH v4] util-linux: split uuid in separate recipe to allow bootstrapping
Date: Tue, 19 Jan 2021 23:23:34 +0000	[thread overview]
Message-ID: <45331765fb689a78bb52363d4fc8f5970693c763.camel@linuxfoundation.org> (raw)
In-Reply-To: <2056926.Mh6RI2rZIc@linc>

On Wed, 2021-01-20 at 12:13 +1300, Paul Eggleton wrote:
> On Wednesday, 20 January 2021 09:52:41 NZDT Richard Purdie wrote:
> > I think the one remaining issue here is the need to change the DEPENDS
> > of so many other recipes, likely not just here in this patch but in
> > other layers. I think if util-linux DEPENDS on util-linux-uuid that
> > might remove the need for those changes? That should still allow you to
> > break the circular dependency problem?
> 
> I have to admit to a gap in my own knowledge of how our build system handles 
> transitive dependencies. Of course the recipe sysroot should still get 
> everything it needs in it even if the dependency is only indirectly included, 
> in the back of my mind I have the impression that there are expectations that 
> all dependencies are explicitly called out and there are subtle issues if they 
> aren't, but that could be a mistaken impression on my part.

I do wonder a little about that as well. As you say, sysroot
dependencies should handle this. Anything linking against libuuid
should also establish an package level runtime dependency through the
linkage so I think this should work.

We definitely don't explicitly list every dependency in every recipe.

If this can work, it makes the migration path for people easier so I
think its at least worth investigating/testing.

Just while I'm thinking, the PACKAGES_remove also bothers me a little.
Can we rearrange the variables so libuuid is only added in the libuuid
recipe variant?

[the idea being that since we control the metadata in oe-core, we
shouldn't need to use _remove and can restructure so we don't need to,
they're hard to undo. I know we do use it in places sadly even in core]

> > I suspect libuuid should really be maintained/built as a separate
> > software project given the dependency problems but that isn't my
> > decision, we just have to deal with it.
> 
> I agree that it would be better being separate, FWIW.
> 
> > I am also worried this is going to break AUH and mean we have to
> > manually handle this recipe but again, I suspect there is little to be
> > done and we just have to deal with it.
> 
> Could we perhaps fix the AUH to handle this properly? Do we need some kind of 
> mechanism to get it to always upgrade the two recipes together or is that only 
> part of the issue?

I don't know for sure that AUH won't handle it, I just worry about it.
If it doesn't it definitely could be something we could fix there. I
just don't know of anyone with the time to spend on what is a marginal
corner case if it doesn't work.

Cheers,

Richard


  reply	other threads:[~2021-01-19 23:23 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-05 20:13 [PATCH] util-linux: split uuid in separate recipe to allow bootstrapping luca.boccassi
2019-12-05 23:29 ` Ross Burton
2019-12-09 16:24 ` [PATCH v2] " luca.boccassi
2020-11-23 13:28   ` [PATCH v3] " Luca Bocassi
2020-12-10 15:52     ` [OE-core] " Richard Purdie
2020-12-10 18:47       ` Luca Boccassi
2020-12-10 20:04         ` Richard Purdie
2020-12-11  9:51           ` Luca Boccassi
2020-12-11 16:54             ` Richard Purdie
2020-12-14 16:32               ` Luca Boccassi
2020-12-10 18:46     ` [PATCH v4] " Luca Bocassi
2021-01-19 20:52       ` Richard Purdie
2021-01-19 23:13         ` [OE-core] " Paul Eggleton
2021-01-19 23:23           ` Richard Purdie [this message]
2021-01-19 23:28             ` Paul Eggleton
2021-02-25 15:31               ` Luca Bocassi
2021-02-25 15:30       ` [PATCH v5] " Luca Bocassi
2021-02-26 19:02         ` [OE-core] " Khem Raj
2021-03-02 19:01           ` Luca Bocassi
2021-02-27 14:52         ` Alexandre Belloni
2021-02-27 15:08           ` Alexandre Belloni
2021-02-27 15:15             ` Alexandre Belloni
2021-03-02 17:31               ` Luca Bocassi
2021-03-02 18:49                 ` Alexandre Belloni
2021-03-03 22:30         ` Richard Purdie
2021-03-04 12:05           ` Luca Bocassi
2021-03-04 12:27       ` [PATCH v6] " Luca Bocassi
2021-03-05  0:13         ` Richard Purdie
2021-03-05 11:03           ` Luca Bocassi
2021-03-05 11:02       ` [PATCH v7] " Luca Bocassi
2021-03-08 19:29         ` Richard Purdie
2021-03-09 11:07           ` Luca Bocassi
2021-03-09 11:18           ` [OE-core] " Kory Maincent
2021-03-09 13:26             ` Luca Bocassi
2021-03-09 13:47               ` Kory Maincent
2021-03-09 13:48                 ` Richard Purdie
2021-03-09 13:56                   ` Luca Bocassi
2021-03-09 11:13       ` [PATCH v8] " Luca Bocassi
2021-03-09 13:56       ` [PATCH v9] " Luca Bocassi
2021-03-09 23:43         ` Richard Purdie
2021-03-10 18:28           ` Luca Bocassi
2021-03-11 10:15             ` Luca Bocassi
2021-03-11 10:31               ` Richard Purdie
2021-03-11 14:37                 ` Luca Bocassi
2021-03-11 14:38       ` [PATCH v10] " Luca Bocassi
2021-03-11 14:44         ` Richard Purdie
2021-03-11 15:10           ` Luca Bocassi
2021-03-11 15:09       ` [PATCH v11] " Luca Bocassi
2021-03-14 22:10         ` Richard Purdie
2021-03-15 10:44           ` Luca Bocassi
2021-03-15 10:49             ` Richard Purdie
2021-03-15 11:50               ` Luca Bocassi
2021-03-15 12:21                 ` Richard Purdie
2021-03-15 13:04                   ` Luca Bocassi
2021-03-15 13:55                   ` [OE-core] " Martin Jansa
2021-03-15 13:57                     ` Richard Purdie
     [not found]                     ` <166C88B2CBAB1BAF.20509@lists.openembedded.org>
2021-03-15 21:51                       ` Richard Purdie
2021-03-24 16:52                         ` Scott Branden
2021-03-24 17:03                           ` Luca Boccassi
2021-03-24 17:37                             ` Richard Purdie
2021-03-24 17:52                               ` Luca Bocassi
2021-03-25  9:17         ` Oleksiy Obitotskyy
2021-03-25  9:34           ` Richard Purdie
2021-03-25  9:48             ` Luca Bocassi
2021-03-25 14:22             ` Peter Kjellerstedt
2021-03-25 14:27               ` Richard Purdie
2021-03-25 15:45                 ` Luca Bocassi
2021-03-25 16:01                   ` Khem Raj
2021-03-25 16:19                 ` Peter Kjellerstedt
2021-03-25 16:51                   ` Richard Purdie
2021-03-26 18:06                     ` Peter Kjellerstedt
2021-03-26 18:12                       ` Richard Purdie
2021-03-26 18:22                         ` Andre McCurdy
2019-12-09 16:33 ` [PATCH] " Luca Boccassi

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=45331765fb689a78bb52363d4fc8f5970693c763.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bluelightning@bluelightning.org \
    --cc=luca.boccassi@gmail.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 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.