On Wed, Jul 28, 2021 at 1:54 PM Richard Purdie
<richard.purdie@...> wrote:
On Wed, 2021-07-28 at 13:43 -0700, Andre McCurdy wrote:
On Wed, Jul 28, 2021 at 1:24 PM Richard Purdie
<richard.purdie@...> wrote:
On Wed, 2021-07-28 at 21:00 +0100, Richard Purdie via lists.openembedded.org wrote:
On Wed, 2021-07-28 at 12:32 -0700, Andre McCurdy wrote:
On Wed, Jul 28, 2021 at 7:15 AM Richard Purdie
<richard.purdie@...> wrote:
The automated conversion of OE-Core to use the new override sytax isn't
perfect. This patches some mis-converted lines and some lines which were missed
by the automation.
Signed-off-by: Richard Purdie <richard.purdie@...>
@@ -86,7 +86,7 @@ python systemd_populate_packages() {
bb.debug(1, 'adding systemd calls to postinst/postrm for %s' % pkg)
paths_escaped = ' '.join(shlex.quote(s) for s in d.getVar('SYSTEMD_SERVICE:' + pkg).split())
- d.setVar('SYSTEMD_SERVICE:ESCAPED_' + pkg, paths_escaped)
+ d.setVar('SYSTEMD_SERVICE_ESCAPED:' + pkg, paths_escaped)
This is manually fixing the misconversion of _ESCAPED to :ESCAPED,
right? If so then does it mean a bug in the automatic conversion
script since overrides can't be uppercase?
There are several bugs in the script, yes. The question is how far to go
in trying to address them and this wasn't a common issue.
In case it isn't clear, this isn't as easy as you might first think. We need
to convert SYSTEMD_SERVICE_${PN} which has uppercase characters in it. Can it
be fixed? Probably, yes. Is it worth the effort/complexity? Maybe not.
I haven't read the script but doesn't it distinguish between things
following an _ which might be an override (and will never be all
uppercase) and the variable name which is being overridden (which may
be uppercase)?
The script is not a parser in any sense, it is looking for expressions using
pattern matching and making changes based upon that. It is quite horrible in
some ways, equally it is doing a reasonable job of the conversion on the most
part too.
Since the script will be reused many times for many private layers I'd
say making it as robust as possible is a worthy goal.
Well, sure. I have spent days on it and improved it several times over compared
to what it did do. I have it working for 10,000 cases in OE-Core with around 40
exceptions which I didn't think was too bad. I felt I'd reached the point of
diminishing returns with it. As with most things, we can improve it and patches
are welcome.
Unfortunately those most affected by shortcomings in the script are
probably also those least likely to submit patches for it. Just as
those most affected by the new recipe syntax were probably not reading
oe-arch when you proposed the change and asked for feedback. They will
instead find out about it months or years from now when they discover
their meta layers don't work when they try using a new release of OE.
At that point a lot of them will just shug and keep on using 3.1
LTS...
I'm more worried that the patterns of metadata in the wild may be quite different
to what we've trained the script with in OE-Core too, that may be a much more
important issue.
Yes, that's a concern too. Looking at the script now it seems to be
mostly a long list of exceptions. The chances of it working well on
layers you haven't considered don't look too good.
