From: Baurzhan Ismagulov <ibr@radix50.net>
To: isar-users <isar-users@googlegroups.com>
Subject: Re: [PATCH] meta-isar: hello: Use <orig-version> in CHANGELOG_V
Date: Thu, 7 May 2020 22:09:26 +0200 [thread overview]
Message-ID: <20200507200926.yht2a3eq2cvaoa7w@yssyq.m.ilbers.de> (raw)
In-Reply-To: <aa7aeaca-6fc9-b21f-dce5-d23fa66d1bdb@siemens.com>
On Wed, Apr 29, 2020 at 08:10:07AM +0200, Jan Kiszka wrote:
> We have two problems to solve here:
>
> - appending to the exact debian version our own suffix when patching it
> - tracking the upstream version under which the source package is
> extracted to so that ${S} is set correctly
>
> The former is addressed by my patch to debianize, for the latter I'm lacking
> a good idea. However, that is generally not a bit issue because Debian does
> less frequently the update of the major version, often only when switching
> its own major release. Also, patches you carry are more likely to require
> adjustments anyway in that case.
>
> The problem for setting S is not the version extraction like we do for the
> changelog. It is that this has to happen rather early - but after recipe
> parsing where it normally happens. It would require to rewrite do_apt_fetch
> so that it identifies the path and sets S, somehow.
This is a very typical Debian vs. bitbake problem which falls into the 20% that
bitbake doesn't solve nicely. Another example is static DEPENDS of bitbake vs.
Debian's dynamic Depends that become known only after fetching. Besides hacking
the relevant places like do_apt_fetch, these currently tend to require
non-intuitive, hard-to-debug stuff like S="${@...}" or anonymous functions. I
think this particular issue is a good minimal example how we could tackle such
stuff with bitbake. That said, it requires careful consideration beyond the
useful step that the patch addresses. So, I've applied this to next, thanks.
With kind regards,
Baurzhan.
next prev parent reply other threads:[~2020-05-07 20:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 17:29 Jan Kiszka
2020-04-28 16:00 ` Henning Schild
2020-04-28 16:01 ` Jan Kiszka
2020-04-29 5:54 ` Henning Schild
2020-04-29 6:10 ` Jan Kiszka
2020-04-29 6:27 ` Henning Schild
2020-04-29 6:37 ` Henning Schild
2020-04-29 6:51 ` Henning Schild
2020-06-05 17:46 ` Henning Schild
2020-06-05 17:55 ` Jan Kiszka
2020-06-06 8:10 ` Henning Schild
2020-06-06 8:37 ` Baurzhan Ismagulov
2020-06-08 7:59 ` Jan Kiszka
2020-05-07 20:09 ` Baurzhan Ismagulov [this message]
2020-05-08 6:05 ` Jan Kiszka
2020-05-08 6:13 ` Baurzhan Ismagulov
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=20200507200926.yht2a3eq2cvaoa7w@yssyq.m.ilbers.de \
--to=ibr@radix50.net \
--cc=isar-users@googlegroups.com \
/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