On Wed, 2023-08-09 at 14:03 +0000, Peter Kjellerstedt wrote:
> > -----Original Message-----
> > From: openembedded-architecture@lists.openembedded.org
> > <openembedded-
> > architect...@lists.openembedded.org> On Behalf Of Richard Purdie
> > Sent: den 8 augusti 2023 11:11
> > To: openembedded-architecture <openembedded-
> > architect...@lists.openembedded.org>
> > Subject: [Openembedded-architecture] Workflow improvements -
> > incremental
> > source updates?
> >
> > There is a recent discussion about AUTOREV which has got me
> > thinking a
> > bit about the big picture and incremental development.
> >
> > Currently AUTOREV injects into PV. The reasons for that are
> > historical,
> > when OE was not taskhash based we had to do that to trigger
> > updates.
> > There are now different ways it could be done with the revision
> > just
> > needing injection into PKGPV for packaging purposes.
> >
> > I've also been looking at externalsrc bugs.
> >
> > This got me thinking, if we did make AUTOREV work without messing
> > with
> > PV, we could probably go a step further and allow the fetcher to
> > incrementally update an existing git checkout rather than remove
> > and
> > start again from scratch. Patches may or may not be an issue, we
> > could
> > mandate a clean single git:// srcuri to start with although the
> > patch
> > code can remove the patch stack already. This would need to hook in
> > to
> > disable some of the cleanup/removal code.
> >
> > The usecase would be to allow the developer to pull updates from a
> > remote repo, or even commit changes locally and then have the
> > system
> > "flow" the changes through from there. This would remove the
> > annoying
> > clean and re-checkout process which drives some developers crazy.
> > It
> > might also allow externalsrc to change to a new model with less
> > deviation from the normal workflow.
> >
> > Whilst on the subject, I have also been wondering about a new image
> > target, effectively one that would build a new image but then allow
> > an
> > rsync over to a running target. Obviously this may or may not be
> > advisable depending on what was actually running but for some
> > development, it could be useful.
> >
> > Anyway, just thinking out loud but wanted to document the idea. I
> > might
> > look into at least improving the way AUTOREV works...
> >
> > Cheers,
> >
> > Richard
>
> It sounds like there are a lot of good possibilities here.
>
> One question though: would any of this make it possible to use
> ${AUTOREV} together with BB_SRCREV_POLICY = "cache"?
No, since those two things are mutually exclusive.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1729):
https://lists.openembedded.org/g/openembedded-architecture/message/1729
Mute This Topic: https://lists.openembedded.org/mt/100618420/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
