Yocto: как удалить/занести в черный список некоторые зависимости от RDEPENDS пакета?

Question

У меня есть пользовательский уровень машины на основе https://github.com/jumpnow/meta-wandboard.

Я обновил ядро ​​до 4.8.6 и хочу добавить X11 к изображению. Я изменяю рецепт изображения (console-image.bb). Поскольку wandboard основан на i.MX6, я хочу включить пакет xf86-video-imxfb-vivante от meta-fsl-arm. Однако он не жалуется на невозможность построить kernel-module-imx-gpu-viv. Я считаю, что это происходит из-за того, что xf86-video-imxfb-vivante ЗАВИСИТ ОТ imx-gpu-viv, который, в свою очередь, выключает kernel-module-imx-gpu-viv.

Я понимаю, что эти зависимости были созданы с помощью мета-fsl-arm BSP и ванильного распределения Poky. Но эти вещи устарели для wandboard, поэтому я использую пользовательский машинный слой с современным ядром. Ядро настроено на включение модуля Vivante DRM, и я действительно не хочу, чтобы был создан пакет kernel-module-imx-gpu-viv.

Есть ли способ исключить его из RDEPENDS? Могу ли я как-то поклясться своим здоровьем в системе сборки, что сам позабочусь об этой конкретной зависимости от времени выполнения?

Я попытался ввести черный список «kernel-module-imx-gpu-viv» PNBLACKLIST[kernel-module-imx-gpu-viv] в свой local.conf, но это только часть решения. Это помогает избежать сбоев сборки, но процесс упаковки все еще не работает.

Answer 1

IIUC Вы проблема возникает из этих линий в img-gpu-viv recipe:

FILES_libgal-mx6 = "${libdir}/libGAL${SOLIBS} ${libdir}/libGAL_egl${SOLIBS}" 
FILES_libgal-mx6-dev = "${libdir}/libGAL${SOLIBSDEV} ${includedir}/HAL" 
RDEPENDS_libgal-mx6 += "kernel-module-imx-gpu-viv" 
INSANE_SKIP_libgal-mx6 += "build-deps" 

Я бы на самом деле квалифицировать этот RDEPENDS как ошибка, как правило, ядро ​​зависимостей модуля определяются как RRECOMMENDS, поскольку большинство модулей могут быть скомпилированы в ядро, таким образом, делая нет отдельного пакета, но при этом обеспечивается функциональность. Но это еще одна проблема.

Существует несколько способов устранить эту проблему, первый общий маршрут - настроить RDEPENDS для пакета. Это просто переменная bitbake, поэтому вы можете либо assign it some other value, либо remove some portion of it. В первом случае это будет выглядеть примерно так:

RDEPENDS_libgal-mx6 = "" 

Во втором:

RDEPENDS_libgal-mx6_remove = "kernel-module-imx-gpu-viv" 

Очевидно, что эти два варианта имеют различные последствия для вашей нынешней и будущей работы. В общем, я бы выбрал более мягкий, второй, потому что у него меньше возможностей для поломки, когда вы должны обновить слой meta-fsl-arm, который может изменить рецепт imx-gpu-viv любым способом. Но когда вы переопределяете более сложный рецепт с большими списками в переменных, и вы его сильно изменяете (не просто удаляя вещь или две), может быть проще поддерживать его с полным жестким назначением переменных.

У нас также есть вопрос , где, чтобы сделать эту переменную mangling. Основной вариант - .bbappend in your layer, для чего добавлены приложения, но вы также можете сделать это из конфигурации вашего дистрибутива (если вы поддерживаете свой собственный дистрибутив, может быть проще иметь все эти настройки в одном месте, а не распылять на многочисленные добавляет) или из вашего local.conf (что является хорошим местом, чтобы быстро попробовать его, но, вероятно, не использовать его в долгосрочной перспективе). Обычно я использую .bbappend.

Но есть и совершенно другой подход к этой проблеме, вместо того, чтобы фиксировать зависимости пакетов, вы также можете исправить то, что some other package provides. Если, например, у вас есть ядро, выполненное с возможностью иметь imx-gpu-viv модуль встроен прямо в основной zimage вы можете сделать

RPROVIDES_kernel-image += "kernel-module-imx-gpu-viv" 

(также в .bbappend, конфигурации дистрибутива или local.conf) и это все.

В любом случае ваш подход к устранению этой проблемы должен отражать разницу между настройками и рецептами. Если у вас есть модуль, но в другом пакете, то перейдите на RPROVIDES, если у вас есть другой модуль, обеспечивающий ту же функциональность, что и libgal-mx6, тогда исправьте libgal-mx6 зависимостей (и лучше исправить их, что означает не только отбросить что-то вам не нужно, но также добавьте вещи, которые имеют отношение к вашей настройке).