10749 2016-11-30 20:11:28 +0000 Add a class to update package index automatically 2026-03-05 16:09:46 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 2.2 x86 Multiple NEW Medium enhancement 6.99 1 bluelightning unassigned bluelightning bruce.ashfield meta.mr.watcher meta.watcher randy.macleod --- --- No (bug/feature does not impact docs) oldest_to_newest 68756 0 bluelightning 2016-11-30 20:11:28 +0000 If you have a target machine with an image on it that has package management enabled pointing to a feed served from your build machine, you can install / update packages from it as they get built. However, you currently have to remember to explicitly run bitbake package-index every time so that the index is up-to-date before you run the package manager. It would be fairly easy to write a class that used a bb.event.BuildCompleted event handler to run the same thing that package-index does at the end of every build so that the index is always up-to-date - it could even try to be smart and only do it when it needs to, e.g. check if the mtime of any files under the package feed has changed. 69168 1 ross.burton 2016-12-15 17:01:29 +0000 I love it when "fairly easy" turns out to be otherwise. BuildComplete handlers can't have dependencies, so there's no way of saying that it needs apt-native etc to execute. We can't have the class add PACKAGEINDEXDEPS to DEPENDS as that introduces circular build dependencies. We need the dependencies in case packages are pulled in from sstate and the native tools are not. I'm now profiling the index generation and wonder if we should have an option to run it after every do_package_*... 69169 2 ross.burton 2016-12-15 17:18:19 +0000 Hm, package-index takes 10 seconds (just the generate_index_files call) after building a core-image-minimal, so that's way too heavy for every do_package. 74578 3 brian.avery 2017-06-27 16:19:16 +0000 Is there a way to schedule this after all rpm's are done rather than for each one by looking at all the targets, maybe? It might also be nice to be able to turn this on and off with a variable as it is very frustrating to forget to run the package-index and have the dnf install on the target fail. but if I'm not maintaining a package index. it is pretty useless to run it. 75120 4 brian.avery 2017-07-18 21:25:02 +0000 Paul's idea was to have it be a last run type operation like buildhistory, which is also controlled by a local.conf setting; which seems like a good fit to me. adding paul+henry to cc. 79604 5 robin.l.jordan 2018-02-26 20:35:35 +0000 Please provide a status on this. Will it make it into YP 2.5 M3? 79607 6 robin.l.jordan 2018-02-26 20:41:27 +0000 Appologies...I see that it has been pushed. 86142 7 ross.burton 2020-01-29 16:31:58 +0000 poky-contrib:ross/index has a prototype of this. 86159 8 ross.burton 2020-01-29 17:03:59 +0000 So it sort of works. Need to repeat the path generalising I did for opkg to rpm so it can find the binaries it needs. 86160 9 ross.burton 2020-01-29 17:04:50 +0000 I lie, it actually works. \o/ Needs to not spam the console with logging from the index. 86540 10 ross.burton 2020-02-21 12:06:21 +0000 Another note: the class should at least warn if PRSERV_HOST isn't set, as a feed without prserv isn't useful. 93208 11 ross.burton 2022-04-28 15:08:53 +0000 Bruce: is this something the binary distros working group is interested in? 93215 12 bruce.ashfield 2022-04-28 16:14:50 +0000 Yep, this is something that would be handy as part of a "getting started" guide to extending/generating the feeds. "inherit this class" (or we template it), and you are off to the races with a feed. I'd think we'd also want that same enable class to consider where the packages are hosted/served, so it could optionally rsync them AND make sure the on-target package manager has the details. But obviously, those are extensions / next steps. 95422 13 randy.macleod 2023-04-21 18:45:43 +0000 Moved en masse from 4.2 to 4.3 by Randy.