From: Paul Eggleton <paul.eggleton@intel.com>
To: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Cc: Leonardo Sandoval <leonardo.sandoval.gonzalez@intel.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: automatic recipe upgrades - making them better and sweeter
Date: Tue, 07 Nov 2017 09:04:30 +1300 [thread overview]
Message-ID: <14953303.KfuyF98Oh2@peggleto-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <499138bd-32cc-1487-e36e-fc4e5aceb4b2@linux.intel.com>
Hi Alex,
On Tuesday, 7 November 2017 12:50:05 AM NZDT Alexander Kanavin wrote:
> I've been asked by RP to look into making automatic package upgrades
> work better, so here's what I'd like to improve:
>
> 1) when using 'devtool upgrade', remove the need to specify version and
> source revision on the command line, if we want to upgrade to the latest
> release. There is now distrodata/checkpkg code in place to determine
> both, so 'devtool upgrade <recipe>' could simply default to that.
You could certainly have it dynamically inherit distrodata for the recipe (via
the workspace bbappend) and then use that to get the required information. I'd
avoided that extra complexity earlier but it may be that now it's actually
easier than it was before. The only thing I would say is we need to produce
clear error messages if we don't have the needed information to automatically
figure out what the upgrade version should be.
> 2) help with LICENSE checksum changes a bit more; both devtool and AUH
> have some code for this, so I want to review what they do, and
> consolidate it in a single place. Maintainers should be able to see a
> diff of what the changes are.
Agreed. For everyone else's benefit, Alex filed a bug for this a while ago:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10801
I am keeping an eye on this one.
> 3) 'devtool finish' currently does not handle the recipe upgrade
> situation well: the new recipe and patches are placed side by side with
> the current recipe. The old stuff should be removed, and a tentative
> commit should be created. So maybe add a 'devtool finish-upgrade'.
That's not what's supposed to happen - it should already be deleting the
original files (it takes a record of the copied files when you run devtool
upgrade, and then when you run devtool finish it deletes those and moves the
new ones across from the workspace). If that's not working it's a bug and I
would appreciate a reproducer. I'd certainly prefer that we keep to one finish
command that does its best to "do the right thing" depending on the situation.
> 4) AUH should be stripped to its core business: sending useful emails to
> maintainers, and leave the rest to devtool. If 'devtool upgrade'
> succeeded, then corresponding patches should be attached, otherwise (if
> patch rebase failed, or a fetch issue), at least it could tell what
> happened and suggest a devtool upgrade command to get started. Any
> duplicate functionality for upgrading (stuff that is also in devtool)
> should be removed.
Agreed. There's a bug open for this one too:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10598
BTW, you have impeccable timing as I am currently in the middle of preparing a
fairly substantial changeset for devtool including implementing a dry-run mode
for devtool finish (so you can see what it's going to do) and fixing the
following bugs, among others:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10939
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11948
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11516
Current WIP is on paule/devtool31 in poky-contrib.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2017-11-06 20:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-06 11:50 automatic recipe upgrades - making them better and sweeter Alexander Kanavin
2017-11-06 20:04 ` Paul Eggleton [this message]
2017-11-07 15:20 ` Alexander Kanavin
2017-11-07 20:17 ` Paul Eggleton
2017-11-08 13:09 ` Alexander Kanavin
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=14953303.KfuyF98Oh2@peggleto-mobl.ger.corp.intel.com \
--to=paul.eggleton@intel.com \
--cc=alexander.kanavin@linux.intel.com \
--cc=leonardo.sandoval.gonzalez@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox