Yocto: Wie entfernt man eine Abhängigkeit von RDEPENDS eines Pakets?

Question

Ich habe eine benutzerdefinierte Maschinenschicht basierend auf .

Ich habe den Kernel auf 4.8.6 aktualisiert und möchte X11 zum Bild hinzufügen. Ich modifiziere Bildrezept (console-image.bb). Da Wandboard auf i.MX6 basiert, möchte ich das xf86-video-imxfb-vivante Paket von meta-fsl-arm enthalten. Allerdings scheitert es, sich über die Unfähigkeit zu beschweren, kernel-module-imx-gpu-viv zu bauen. Ich glaube, das passiert, weil xf86-video-imxfb-vivante auf imx-gpu-viv DEPENDS die wiederum RDEPENDS auf kernel-module-imx-gpu-viv.

Ich weiß, dass diese Abhängigkeiten mit Meta-FSL-Arm BSP und Vanille Poky-Verteilung erstellt wurden. Aber diese Dinge sind für Wandboard veraltet, daher verwende ich die benutzerdefinierte Maschinenebene mit modernem Kernel. Der Kernel ist so konfiguriert, dass er das Vivante DRM-Modul enthält, und ich möchte wirklich nicht, dass das kernel-module-imx-gpu-viv-Paket erstellt wird.

Gibt es eine Möglichkeit, es von RDEPENDS auszuschließen? Kann ich dem Buildsystem irgendwie meine Gesundheit beschwören, dass ich mich selbst um diese spezielle Laufzeitabhängigkeit kümmern werde?

Ich habe versucht, 'kernel-module-imx-gpu-viv' Einstellung PNBLACKLIST[kernel-module-imx-gpu-viv] in meiner local.conf Blacklisting, aber das ist nur ein Teil einer Lösung. Es hilft Build-Fehler zu vermeiden, aber der Verpackungsprozess schlägt immer noch fehl.

Answer 1

IIUC Sie Problem kommt von diesen Linien in 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" 

Ich würde diese RDEPENDS als Bug tatsächlich qualifizieren, in der Regel Kernel-Modul-Abhängigkeiten als RRECOMMENDS angegeben werden, da die meisten Module können so in den Kernel eingebunden werden machen kein separates Paket bei gleichzeitiger Bereitstellung der Funktionalität. Aber das ist ein anderes Problem.

Es gibt mehrere Möglichkeiten, dieses Problem zu beheben. Der erste allgemeine Weg besteht darin, RDEPENDS für das Paket zu optimieren. Es ist nur eine Bitbake-Variable, also können Sie entweder assign it some other value oder remove some portion of it. Im ersten Fall, es wird ein wenig wie folgt aussehen:

RDEPENDS_libgal-mx6 = "" 

Im zweiten:

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

Offensichtlich sind diese beiden Optionen haben unterschiedliche Auswirkungen auf Ihre Gegenwart und Zukunft der Arbeit. Im Allgemeinen würde ich für das weichere wählen, das das zweite ist, weil es weniger Potential für Bruch hat, wenn Sie Schicht meta-fsl-arm aktualisieren, die imx-gpu-viv Rezept in irgendeiner Art und Weise ändern kann. Aber wenn Sie ein komplexeres Rezept mit großen Listen in Variablen überschreiben und es stark modifizieren (nicht nur ein oder zwei Dinge entfernen), könnte es einfacher sein, es mit einer vollständigen harten Zuweisung von Variablen zu verwalten.

Jetzt gibt es auch eine Frage von wo diese variable Mangling zu tun. Die Hauptoption ist .bbappend in your layer, für die die Anhänge erstellt wurden, aber Sie können dies auch aus Ihrer Distro-Konfiguration heraus tun (wenn Sie Ihre eigene Distribution beibehalten, ist es vielleicht einfacher, all diese Optimierungen an einem Ort zu haben, anstatt in zahlreiche zu sprühen hängt) oder von Ihrem(was ein schöner Ort ist, um es schnell auszuprobieren, aber wahrscheinlich nicht etwas, das längerfristig verwendet werden kann). Ich verwende normalerweise .bbappend.

Aber es gibt auch einen ganz anderen Ansatz für dieses Problem, anstatt Paketabhängigkeiten zu beheben, können Sie auch reparieren, was some other package provides. Wenn Sie zum Beispiel einen Kernel konfiguriert haben imx-gpu-viv Modul direkt in die Haupt zimage gebaut haben, können Sie

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

(auch in .bbappend, Distro Konfiguration oder local.conf) tun und das ist es.

In jedem Fall sollte Ihr Ansatz zur Behebung dieses Problems den Unterschied zwischen Ihren Setup- und Rezeptannahmen widerspiegeln. Wenn Sie das Modul haben, aber in einem anderen Paket, dann gehen Sie für , wenn Sie ein anderes Modul mit der gleichen Funktionalität zu libgal-mx6 Paket haben dann beheben Sie libgal-mx6 Abhängigkeiten (und es ist besser zu fix sie, was bedeutet nicht nur etwas fallen Sie brauchen nicht, sondern fügen auch Dinge hinzu, die für Ihre Einrichtung relevant sind).