I see your point. Please drop this patch set from consideration. Taking a step back, my intention was to make it so that a "packagefeed" was a simple buildable target the way an image or packagegroup is. That is, I'd like it to be possible to just "bitbake packagefeed" and get all the packages and indexes. I think the non-deterministic problem exists today too since someone could run "bitbake packagegroup package-index" and nothing is stopping them from doing that other than noticing it doesn't work.
I can see a couple of potential options: 1. Come up with a way to ensure that the do_package_index task is only run once per bitbake invocation after all other packaging tasks. As far as I can tell, there's not a way to enforce this with my current design. It also doesn't address the problem of packages already in the deploy directories. 2. Add more scaffolding to create a packagefeed class with potentially its own deploy directory and which only includes index files for its dependencies. That seems like a lot more effort than my change but might address the concerns more completely. Any feedback or thoughts on those ideas? Thanks, Charlie On Thu, May 25, 2023 at 11:11 AM, Alexander Kanavin wrote: > > It would not be the same thing done twice. It is not clear how the > rpm/dep/opkg-specific tooling would behave if there's two or more > instances of it indexing the files at the same time, or one starts > earlier than the other, and the later ones see incomplete index files > or half-deployed packages etc. It's well possible such situations are > not handled well, and you still need to somehow ensure the indexing > indeed runs once, and only after everything else. How would you ensure > that? I worry this change opens the door to misuse, and cryptic, hard > to reproduce or diagnose errors. > > The output would also be non-deterministic: it would contain > everything from the packagegroup and an unknown amount of additional > packages, depending on what else happened to be in deploy directory at > the time. > > Alex > > On Thu, 25 May 2023 at 17:55, Charlie Johnston <[email protected]> > wrote: > >> >> Yes, having two recipes that inherit this running at the same time would >> potentially write the same index files. I'm not sure that's actually a >> problem other than the same thing being done twice. >> As long as at least one of the package index steps runs after all packages >> have been written, the index files will be up-to-date. Since I've made the >> task recursively depend on the tasks that create packages, I think it's >> fine. >> >> That being said, if there's a way to both add it to recipes and ensure >> that the task only runs once per bitbake command I would be open to moving >> towards that. Is there anything like that? >> >> Thanks, >> Charlie >> >> On Thu, May 25, 2023 at 03:47 AM, Alexander Kanavin wrote: >> >> What happens if several recipes inherit this class, and are processed >> at the same time? Won't they step on each other, writing the same >> index files into the deploy directory? I think package-index recipe is >> deliberately standalone for that reason: you have to build it in a >> separate step. >> >> Alex >> >> On Wed, 24 May 2023 at 23:55, Charlie Johnston <[email protected]> >> wrote: >> >> >> Added a new packagefeed class that contains both a >> packagegroup and the package index builds. This allows a >> one-line bitbake for a packagegroup that defines a feed >> without explicitly needing to run the package-index recipe. >> >> Signed-off-by: Charlie Johnston <[email protected]> >> --- >> meta/classes/packagefeed.bbclass | 5 +++++ >> 1 file changed, 5 insertions(+) >> create mode 100644 meta/classes/packagefeed.bbclass >> >> diff --git a/meta/classes/packagefeed.bbclass >> b/meta/classes/packagefeed.bbclass >> new file mode 100644 >> index 0000000000..b83ac54f21 >> --- /dev/null >> +++ b/meta/classes/packagefeed.bbclass >> @@ -0,0 +1,5 @@ >> +# >> +# Special case of packagegroup that includes package index builds. >> +# >> + >> +inherit packagegroup package_index >> -- >> 2.30.2 >> >> >> >> >> >> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181724): https://lists.openembedded.org/g/openembedded-core/message/181724 Mute This Topic: https://lists.openembedded.org/mt/99118888/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
