If a user finds that there are packages available in the official Debian distribution which they would like to add to their build, recipetool should attempt to create a recipe based on the source code. The tool could check to see if this recipe is already available. Perhaps this can be done by querying layers.openembedded.org. If nothing is found, use apt to find the source for the package, download, and generate a recipe.
Interesting but problematic given the inevitable mismatch in dependencies wrt glibc and a bunch of shared libraries. As an alternative, and since this tends to be desired for dev purposes rather than for shipping product (my opinion!), we could do the following as an exercise: 1)use sgw's trick detailed in https://wiki.yoctoproject.org/wiki/TipsAndTricks/Running_YP_binaries_on_Ubuntu_and_Vice_Versa to make the glibc issue tractable. 2) make a /debian/usr /debian/var ... etc and change the apt-get install to use it as a root. 3) prepop the dpkg repo with provides for our glibc and our shared libs. the shared libs would be nice but mostly just save space. 4) add the /debian/lib/ debian/usr ... into the library and executable paths --- this would let us do apt-get install <foo> and it would pull foo into /debian/XXX and you could then use it. Edge cases would definitely abound, and this is definitely for devs, but; it's not any different than the folks who grab a fedora binary and want to run it on debian. It will *usually* work assuming the aren't on a too old debian...
initially we will do this as an on target poc. There are 5 variations currently imagined to be explored: 1) Container version using meta-virtualization 2) debian chroot version pointint go /debian 3) dnf from Fedora to file system (not chroot) deposited in /Fedora leveraging rpm --relocate 4) dnf from Fedora to file system in place, installed into /. Faux rpm's created to prevent file collision (aka for gllibc , bash, etc.) 5) apt-get from ubuntu-16.04 to file system in place, installed into /. Faux dpkgs's created to prevent file collision (aka for gllibc , bash, etc.) ---- This is a poc to see if we get 20% success (mostly for 3,4,5 as 1 will work, and 2 should work) or 80%. 3, and especially 4/5 would allow devs to pull in pkgs needed for development quickly and easily, then once they are ready to slim down for product, they could apt-get/dnf remove pkg "duck" while simultaneously adding the YP/OE pkg duck they just built. ---- We will target distro releases that are as "close" as possible to what's in 2.4. This is hoped to make on target development easier and is not intended as a shippable solution, nor do I expect to get anywhere near 100% pkg success for anything outside of 1 and maybe 2. ---- Should any of 3-5 work at a sufficiently high success rate, further bugs could address how to go from poc to feature.
The only thing left here is Lua compatibility. Currently, if we want to point DNF at Fedora public repos, we'd need to compile RPM "--with-lua". This requires lua_compat_5.1 and 5.2 to be enabled. The other option is to fix RPM so that it no longer calls deprecated Lua functions, though that would require more time. Punting this to 2.5 since it is not urgent and is an enhancement.
rpm appears to now require lua >= 5.2 https://github.com/rpm-software-management/rpm/blob/45449d5acfb8f68eb841fef5eed912fd9d9dc48e/configure.ac#L804 The recipe would need to enable lua, optionally with a PACKAGECONFIG We have lua 5.3.5 in meta-oe (5.3.6 and 5.4.0 are newer releases) http://layers.openembedded.org/layerindex/recipe/23539/ http://www.lua.org/versions.html#5.4 Lua would need to move to oe-core
We do have lua 5.4.x or newer in oe-core: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=lua Not sure if there is additional work to do. -- YP bug triage
bulk change to add Saul's non-WR address.
Bulk change: Remove Saul's old WR address.