Re: [OE-core] [PATCH 1/4] devtool: account for sources in UNPACKDIR

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2025-04-25 at 19:29 +0200, Alexander Kanavin wrote:
> On Fri, 25 Apr 2025 at 11:31, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > > 3. This will also break all the tools that assume the current
> > > structure, and another reason this change shouldn't be taken lightly.
> > 
> > Perhaps, or perhaps not. Do we have a lot of tools that wouldn't cope
> > with this?
> 
> Likely Visual Studio Code support will have to be fixed? Impact of
> changes like this is difficult to predict until they're done. Then
> everyone comes out complaining their private scripts broke.
> 
> Otherwise, I'm slowly getting convinced that this is the right thing :)

I think you can see how my thoughts ended up here :)

> 
> > That 'logic' is effectively what do_unpack is already doing itself to
> > maintain 'compatibility'. Perhaps we could use the same logic in both
> > places and be consistent!
> > 
> > I'm torn here. I could take your patch, bury my head in the sand and
> > pretend everything is fine. We could try and actually improve this and
> > set things in a better direction for the future, at the expense of
> > breaking things in the short/medium term. I don't know what to do for
> > the best here to be honest. Taking the patch is way easier for me I
> > doubt we'll ever improvements if I don't push back on things at times
> > :/.
> 
> Here's something I want to propose, feel free to shoot it down. Should
> we start by just dropping support for this legacy compatibility of
> sources in workdir, and S = "${WORKDIR}/something"? So S, when set
> that way, becomes a hard recipe_qa error, and sources are always in
> UNPACKDIR. Yes, there would be a ton of recipes to be fixed, but the
> fix would be largely a search-and-replace. Admittedly, I didn't follow
> the arguments around UNPACKDIR closely and it may have been talked
> about, but why not just do it?

I think this is where I got to last time I looked at this. I ended up
introducing UNPACKDIR and cleaning up some of the stuff and leaving
that workaround in place in do_unpack.

To be honest I'm torn. Part of me wants to do it, part of me worries
about the breakage. We probably would need to prototype some patches,
see how bad it really is.

> Then this fix for devtool wouldn't add more complexity, it would just
> similarly replace workdir with unpackdir - not making things better
> but not making them worse either. On the other hand, if we do nothing,
> then devtool currently doesn't work for recipes that set S to
> unpackdir, negatively impacting AUH rates for one thing (this is why I
> got into it in the first place) :-(

I agree we need to do something, it is just a question of what (and
perhaps when).

Cheers,

Richard