I'm starting a new thread/discussion on this with a new perspective.

I did a little research myself on how these files are being used. My
conclusion is that templateconf.cfg isn't really used by much at all
other than to decide whether to rerun setup pieces.

I'm going to make the assumption that once a build directory is setup,
the user does not want the env setup scripts messing with it again. If
they did, they'd start a new build directory.

As such:

a) showing the user a warning about the template locations changing is
probably not necessary
b) reading the value back in from templateconf.cfg isn't then necessary
as either the files don't exist and we set then up or we don't care

Therefore, my thinking is that we should simply remove
templateconf.cfg?

What am I missing?

Cheers,

Richard

For future enhancements, I would want to keep some kind of record
inside build/conf of where the original template was taken from. I
agree that build init scripts should not use it at all, but that
record can be utilized to either update the build config from an
updated template (with an explicit, separate command), or update the
template itself without having to specify where it is.

Alex

On Wed, 28 Sept 2022 at 10:42, Richard Purdie
<richard.purdie@...> wrote:

I'm starting a new thread/discussion on this with a new perspective.

I did a little research myself on how these files are being used. My
conclusion is that templateconf.cfg isn't really used by much at all
other than to decide whether to rerun setup pieces.

I'm going to make the assumption that once a build directory is setup,
the user does not want the env setup scripts messing with it again. If
they did, they'd start a new build directory.

As such:

a) showing the user a warning about the template locations changing is
probably not necessary
b) reading the value back in from templateconf.cfg isn't then necessary
as either the files don't exist and we set then up or we don't care

Therefore, my thinking is that we should simply remove
templateconf.cfg?

What am I missing?

Cheers,

Richard

On Wed, 2022-09-28 at 10:48 +0200, Alexander Kanavin wrote:

For future enhancements, I would want to keep some kind of record
inside build/conf of where the original template was taken from. I
agree that build init scripts should not use it at all, but that
record can be utilized to either update the build config from an
updated template (with an explicit, separate command), or update the
template itself without having to specify where it is.

I wondered about that. The thing is if you're planning to decide to do
some kind of automated update or user warning message, you need a
version string in the file itself to know what version you're dealing
with so whilst I can see why you might be interested in that
information, I'm not convinced it is as useful as you'd first think as
you'll need other information anyway...

Regardless, it would suggest we should be ignoring the file (whether
create it or not).

Taking another example to suggest it is broken, what if I delete one of
the files and let the setup scripts recreate it after using a different
TEMPLATECONF setting? Which value should templateconf.cfg have?

Cheers,

Richard

On Wed, 28 Sept 2022 at 10:55, Richard Purdie
<richard.purdie@...> wrote:

I wondered about that. The thing is if you're planning to decide to do
some kind of automated update or user warning message, you need a
version string in the file itself to know what version you're dealing
with so whilst I can see why you might be interested in that
information, I'm not convinced it is as useful as you'd first think as
you'll need other information anyway...

Regardless, it would suggest we should be ignoring the file (whether
create it or not).

Taking another example to suggest it is broken, what if I delete one of
the files and let the setup scripts recreate it after using a different
TEMPLATECONF setting? Which value should templateconf.cfg have?

I have already written a patch :) It creates templateconf.cfg if it
does not yet exist,
but otherwise doesn't read or write to it.
https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/package-version-updates&id=0644e4cb1415b44833d57baf9d57845a331bb70b

Alex

On Wed, 28 Sept 2022 at 16:25, Peter Kjellerstedt
<peter.kjellerstedt@...> wrote:

Personally, I would expect the file to contain the latest value used
for TEMPLATECONF. I.e., if I remove the local.conf file to regenerate
it because there has been upstream changes, I would expect it to use
the TEMPLATECONF I specify at that time, and for that value to be
recorded for posterity.

That said, I doubt the value of TEMPLATECONF will actually change for
an existing build environment, so this is probably more on the
theoretical side.

This would complicate the logic (update only if some config was
updated), and if you remove local.conf but not bblayers.conf, so that
one is updated, but not the other, it is not anymore possible to tell
what came from where. Creating it once at the start is more
straightforward, even if origins of further updates are not recorded.

Alex

On Wed, 2022-09-28 at 20:02 +0000, Peter Kjellerstedt wrote:

-----Original Message-----
From: Alexander Kanavin <alex.kanavin@...>
Sent: den 28 september 2022 16:41
To: Peter Kjellerstedt <peter.kjellerstedt@...>
Cc: Richard Purdie <richard.purdie@...>;
openembedded-
architecture <openembedded-architecture@...>
Subject: Re: Template handling in OE-Core

On Wed, 28 Sept 2022 at 16:25, Peter Kjellerstedt
<peter.kjellerstedt@...> wrote:

Personally, I would expect the file to contain the latest value
used
for TEMPLATECONF. I.e., if I remove the local.conf file to
regenerate
it because there has been upstream changes, I would expect it to
use
the TEMPLATECONF I specify at that time, and for that value to be
recorded for posterity.

That said, I doubt the value of TEMPLATECONF will actually change
for
an existing build environment, so this is probably more on the
theoretical side.

This would complicate the logic (update only if some config was
updated), and if you remove local.conf but not bblayers.conf, so
that
one is updated, but not the other, it is not anymore possible to
tell
what came from where. Creating it once at the start is more
straightforward, even if origins of further updates are not
recorded.

Alex

Yeah, I guess it's a case of damned if you do, damned if you don't.
However, as this patch solves our problem, I support applying this
patch.

Ultimately, I think we'll end up removing this file. Whilst I
understand we might want to track where things came from, I think the
current way breaks for two files and doesn't give version information
anyway.

There may be a better way with a copy alongside of the template,
something involving symlinks or something else.

Meanwhile though I'll take this patch as it solves the problem enough
for release and as far as I can tell, shouldn't make anything worse.

Cheers,

Richard