| Message ID | 20250406180920.262141-1-quic_vkraleti@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | libinput: split udev rules into a separate package | expand |
On Sun, 6 Apr 2025 at 20:09, Viswanath Kraleti via lists.openembedded.org <quic_vkraleti=quicinc.com@lists.openembedded.org> wrote: > > Packaging udev rules separately would be helpful in case other packages > need only libinput udev rules but don't require the library itself. Can you give examples of such packages? I'm not sure I understand why someone would expect the rules to be present on target, but not the library, if libinput upstream always installs both. Alex
On Mon, Apr 07, 2025 at 12:04:15PM +0200, Alexander Kanavin wrote: > On Sun, 6 Apr 2025 at 20:09, Viswanath Kraleti via > lists.openembedded.org > <quic_vkraleti=quicinc.com@lists.openembedded.org> wrote: > > > > Packaging udev rules separately would be helpful in case other packages > > need only libinput udev rules but don't require the library itself. > > Can you give examples of such packages? I'm not sure I understand why > someone would expect the rules to be present on target, but not the > library, if libinput upstream always installs both. Basically, we wanted to have a packagegroup selecting libinput, but we can not select libinput from archall package since the libinput package gets renamed. It would be logical to make packagegroups / distro packages to depend on the libinput-udev and then let libinput-udev pull in libinput10 as a dependency.
On Thu, 10 Apr 2025 at 13:21, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote: > Basically, we wanted to have a packagegroup selecting libinput, but we > can not select libinput from archall package since the libinput package > gets renamed. It would be logical to make packagegroups / distro > packages to depend on the libinput-udev and then let libinput-udev pull > in libinput10 as a dependency. This sounds like a workaround for a different issue, so it helps if you come forward with the issue and show how to reproduce it, rather than hide behind vague terms like 'other packages'. Alex
On Thu, Apr 10, 2025 at 01:25:48PM +0200, Alexander Kanavin wrote: > On Thu, 10 Apr 2025 at 13:21, Dmitry Baryshkov > <dmitry.baryshkov@oss.qualcomm.com> wrote: > > Basically, we wanted to have a packagegroup selecting libinput, but we > > can not select libinput from archall package since the libinput package > > gets renamed. It would be logical to make packagegroups / distro > > packages to depend on the libinput-udev and then let libinput-udev pull > > in libinput10 as a dependency. > > This sounds like a workaround for a different issue, so it helps if > you come forward with the issue and show how to reproduce it, rather > than hide behind vague terms like 'other packages'. The commit message definitely needs to be improved. Anyway, here is an error that we've faced: ERROR: packagegroup-qcom-1.0-r0 do_package_write_ipk: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (libinput to libinput10)
On Thu, 10 Apr 2025 at 13:29, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote: > The commit message definitely needs to be improved. Anyway, here is an > error that we've faced: > > ERROR: packagegroup-qcom-1.0-r0 do_package_write_ipk: An allarch > packagegroup shouldn't depend on packages which are dynamically renamed > (libinput to libinput10) Can you provide a way to reproduce this with just oe-core/poky? Alex
On Thu, Apr 10, 2025 at 02:12:36PM +0200, Alexander Kanavin wrote: > On Thu, 10 Apr 2025 at 13:29, Dmitry Baryshkov > <dmitry.baryshkov@oss.qualcomm.com> wrote: > > The commit message definitely needs to be improved. Anyway, here is an > > error that we've faced: > > > > ERROR: packagegroup-qcom-1.0-r0 do_package_write_ipk: An allarch > > packagegroup shouldn't depend on packages which are dynamically renamed > > (libinput to libinput10) > > Can you provide a way to reproduce this with just oe-core/poky? echo 'RDEPENDS:${PN} += "libinput"' >> ../meta/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb && bitbake bitbake packagegroup-core-weston ERROR: packagegroup-core-weston-1.0-r0 do_package_write_ipk: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (libinput to libinput10)
On Thu, 10 Apr 2025 at 20:36, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote: > > Can you provide a way to reproduce this with just oe-core/poky? > > echo 'RDEPENDS:${PN} += "libinput"' >> ../meta/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb && bitbake bitbake packagegroup-core-weston > > ERROR: packagegroup-core-weston-1.0-r0 do_package_write_ipk: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (libinput to libinput10) Yes, I can see it. The reasoning still doesn't hold water though - "we can't put a library package into a packagegroup for <reasons>, but fortunately it has some stuff that can be split into its own package, and then that can be used as a proxy". What's the original reason for wanting to add libinput to a packagegroup? Alex
On 11/04/2025 13:12, Alexander Kanavin wrote: > On Thu, 10 Apr 2025 at 20:36, Dmitry Baryshkov > <dmitry.baryshkov@oss.qualcomm.com> wrote: >>> Can you provide a way to reproduce this with just oe-core/poky? >> >> echo 'RDEPENDS:${PN} += "libinput"' >> ../meta/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb && bitbake bitbake packagegroup-core-weston >> >> ERROR: packagegroup-core-weston-1.0-r0 do_package_write_ipk: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (libinput to libinput10) > > Yes, I can see it. The reasoning still doesn't hold water though - "we > can't put a library package into a packagegroup for <reasons>, but > fortunately it has some stuff that can be split into its own package, > and then that can be used as a proxy". > > What's the original reason for wanting to add libinput to a packagegroup? To let libinput setup & handle input devices. But probably I see your point. I have checked my Debian system and libinput-bin (rules & quirks) is being pulled by libinput10 (which in turn is being pulled by xserver-xorg-input-libinput, libmutter-16-0, etc). We will verify that in our distro libinput gets pulled in by the actual packages that depend on input even processing rather than pulling in the lib itself.
On 11/04/2025 13:12, Alexander Kanavin wrote: > On Thu, 10 Apr 2025 at 20:36, Dmitry Baryshkov > <dmitry.baryshkov@oss.qualcomm.com> wrote: >>> Can you provide a way to reproduce this with just oe-core/poky? >> >> echo 'RDEPENDS:${PN} += "libinput"' >> ../meta/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb && bitbake bitbake packagegroup-core-weston >> >> ERROR: packagegroup-core-weston-1.0-r0 do_package_write_ipk: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (libinput to libinput10) > > Yes, I can see it. The reasoning still doesn't hold water though - "we > can't put a library package into a packagegroup for <reasons>, but > fortunately it has some stuff that can be split into its own package, > and then that can be used as a proxy". > > What's the original reason for wanting to add libinput to a packagegroup? To let libinput setup & handle input devices. But probably I see your point. I have checked my Debian system and libinput-bin (rules & quirks) is being pulled by libinput10 (which in turn is being pulled by xserver-xorg-input-libinput, libmutter-16-0, etc). We will verify that in our distro libinput gets pulled in by the actual packages that depend on input even processing rather than pulling in the lib on its own.
On Fri, 11 Apr 2025 at 12:27, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote: > To let libinput setup & handle input devices. > > But probably I see your point. I have checked my Debian system and > libinput-bin (rules & quirks) is being pulled by libinput10 (which in > turn is being pulled by xserver-xorg-input-libinput, libmutter-16-0, > etc). We will verify that in our distro libinput gets pulled in by the > actual packages that depend on input even processing rather than pulling > in the lib on its own. Libinput package contains only the library and the rules. If you install it on the system, that in itself will not result in setting up of input devices, because there is nothing in that package that can be executed. Alex
diff --git a/meta/recipes-graphics/wayland/libinput_1.28.1.bb b/meta/recipes-graphics/wayland/libinput_1.28.1.bb index c10422bf9b..42d2c861a9 100644 --- a/meta/recipes-graphics/wayland/libinput_1.28.1.bb +++ b/meta/recipes-graphics/wayland/libinput_1.28.1.bb @@ -46,4 +46,9 @@ RPROVIDES:${PN} = "libinput" RREPLACES:${PN} = "libinput" RCONFLICTS:${PN} = "libinput" +# split udev rules into seperate package +PACKAGE_BEFORE_PN += "${PN}-udevrules" +RDEPENDS:${PN} += "${PN}-udevrules" +FILES:${PN}-udevrules = "${nonarch_base_libdir}/udev/rules.d" + FILES:${PN}-ptest += "${libexecdir}/libinput/libinput-test-suite"
Packaging udev rules separately would be helpful in case other packages need only libinput udev rules but don't require the library itself. Let libinput RDEPENDS on this udev rules package to ensure build consistency. Signed-off-by: Viswanath Kraleti <quic_vkraleti@quicinc.com> --- meta/recipes-graphics/wayland/libinput_1.28.1.bb | 5 +++++ 1 file changed, 5 insertions(+)