On 11/24/23 10:01 AM, Mark Hatle wrote:
On 11/24/23 3:27 AM, Michael Opdenacker via lists.openembedded.org wrote:
Alex, Bruce
On 23.11.23 at 14:54, Bruce Ashfield wrote:
On Thu, Nov 23, 2023 at 4:02 AM Alexander Kanavin
<[email protected]> wrote:
On Wed, 22 Nov 2023 at 21:04, Michael Opdenacker via
lists.openembedded.org
<[email protected]> wrote:
- Beginner use case: begin by fetching a binary image, ready to boot on a
target machine. Extend the system by installing extra applications
through
package feeds.
- Intermediate use case: tweak and rebuild existing packages, compile new
applications and modify images by using an eSDK and other binary
artifacts.
- Advanced use case: completely reorganize and optimize the system for a
specific target, switching to building from source
I would actually suggest that the esdk is skipped altogether: it
provides a restricted, locked down environment without access to
bitbake or possibility to modify the build. It's not a 'real yocto'.
The intent was to stay in between the binaries and full yocto, in particular
not having to directly jump to bitbake interactions. It's the gradual onramp
that we were looking for.
Rather, let's give the users the possibility to go directly to the
full yocto build that was used to produce the binary images. To that
end, I've proposed a prototype for making 'build bundles':
https://patchwork.yoctoproject.org/project/oe-core/patch/[email protected]/
It would need a corresponding user-facing piece, e.g. oe-setup that
would take and unpack and setup the bundle from the server, ensuring
it does match the binary image.
Agreed that your proposal and bundles are something that we'd want to
embrace with this effort, once they are merged and agreed upon. In
particular since devtool is definitely there for a similar interface as the
eSDK is providing (and what we were looking for). Preferable at that point,
the eSDK as it exists is replaced and the decision is simple.
Interesting idea, thanks! I added it to my notes, which will end up in
the YP wiki.
We could include the bundles in the deliverables along with the distro
binaries. This would make it easy to reproduce and then customize the
images.
This also reminds me that license compliance applies to us too, so as
soon as we ship binaries, we should ship the sources too (and not only
for the build system). I remember how annoyed I was at Angstrom when I
wanted to figure out how it made USB host work on the BeagleBoarg (yes,
a while ago). All Angstrom was shipping was free binaries and references
to the build system. I was forced to use the build system when all I
wanted was just the kernel sources and their configuration.
In the past, the statement was made that we would generate source packages that
would include the full source (as referenced in the ${S} directory of the
build), but there was no promise that a 'source package' would build, using the
tooling of the package manager.
This allowed us to clearly have a license compliance "source package", but the
reference back to the full build was ALWAYS "the build system". I'd say this
continues to be the model I would support. (The package beyond license
compliance is also needed for debugging things on the board.)
binary package(s)
source package
original build environment
The one thing that needs to be checked though, is the -src package complete?
For debugging purposes, I believe it is.. but I'm not sure what changed have
happened in it in the last 5 years or so when I was last involved in the code
base. The original (many many years ago) intention was that it would be a
complete copy of the ${S}, and like the source compliance work elsewhere
(archiver.bbclass) could get other bits and pieces embedded into it.
It may also be a completely reasonable behavior that -src stays as run-time
debug, and we point users at the archiver sources for license compliance. They
don't have to be done in packages (since we know a source package won't work
anyway!)
I just re-read what I wrote and realized I'm not awake.. there are TWO different
outputs.
-src package which is DEBUG centric
.src.rpm which was supposed to be equivalent of the archiver, but in RPM format.
(I assume a tarball for deb users.. I don't know about opkg.)
--Mark
--Mark
Thanks again
Michael.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1862):
https://lists.openembedded.org/g/openembedded-architecture/message/1862
Mute This Topic: https://lists.openembedded.org/mt/102755562/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
