build-rootfs: install package from manifest after linux header

[Shoudi Li (shoudil)]

As part of requirement to integrate adreno packages on server distro, ensure linux header package installed before installation of kgsl dkms package.

[Bjordis Collaku (bjordiscollaku)]

Change looks good, ordering is right for the dkms install. Only ask is deleting the old block rather than leaving it commented out.

One edge case, not a blocker: if we ever pin an exact version in the manifest (pkg=1.2.3 instead of latest), this reorder breaks the local-debs override for that package. The manifest runs last now, so the pinned version displaces the local deb even when the local one is higher, since an explicit version request skips the highest-wins logic. It would fail quietly too, either a silent downgrade or apt refuses and the || true swallows it so the rest of the manifest never installs. That said, it may well be we never pin a version in the manifest, in which case it never comes up.

[Bjordis Collaku (bjordiscollaku)]

Separate from the edge case above, there's a bigger issue longer term.

This PR makes kgsl-dkms install work during rootfs creation by relying on local-debs being installed first, so the headers happen to be on disk before the dkms postinst runs. That holds today only because build-rootfs.sh runs local-debs and the manifest as two separate apt invocations. It stops holding the moment kernel packages are pulled from artifactory or debusine alongside everything else in package-manifest.json: that becomes a single apt transaction, dpkg orders configuration by the dependency graph, and kgsl-dkms doesn't depend on linux headers. There is nothing to force headers first.

This is coming soon anyway. We will publish the kernel to an apt repo as well, and I am working on that for the Debian side of pkg-linux-qcom now.

To me this is the argument for bundling the dkms module with the kernel package rather than ordering installs. I have implemented and validated that approach in pkg-linux-qcom#54, with kgsl as the listed module, on both Debian trixie (pulling kgsl from the debusine apt repo) and Ubuntu resolute (using kgsl from artifactory). The module is built against the exact kernel in the same packaging run and shipped inside the kernel package, so there is no runtime dkms, no headers on the target, and no install order to get right.

None of this blocks this PR. The ordering fix is right for where we are today.

[Shoudi Li (shoudil)]

Separate from the edge case above, there's a bigger issue longer term.

This PR makes kgsl-dkms install work during rootfs creation by relying on local-debs being installed first, so the headers happen to be on disk before the dkms postinst runs. That holds today only because build-rootfs.sh runs local-debs and the manifest as two separate apt invocations. It stops holding the moment kernel packages are pulled from artifactory or debusine alongside everything else in package-manifest.json: that becomes a single apt transaction, dpkg orders configuration by the dependency graph, and kgsl-dkms doesn't depend on linux headers. There is nothing to force headers first.

This is coming soon anyway. We will publish the kernel to an apt repo as well, and I am working on that for the Debian side of pkg-linux-qcom now.

To me this is the argument for bundling the dkms module with the kernel package rather than ordering installs. I have implemented and validated that approach in pkg-linux-qcom#54, with kgsl as the listed module, on both Debian trixie (pulling kgsl from the debusine apt repo) and Ubuntu resolute (using kgsl from artifactory). The module is built against the exact kernel in the same packaging run and shipped inside the kernel package, so there is no runtime dkms, no headers on the target, and no install order to get right.

None of this blocks this PR. The ordering fix is right for where we are today.

For the dkms need to be integrated in rootfs by default, it's fine to bundle with kernel package. but DKMS (compiling on device) should also be supported as there are also tech area packages will be installed as per need (such as video dkms pkg), and end user or OEM customer may also install dkms pkgs (compile there kernel modules) on device.

[Bjordis Collaku (bjordiscollaku)]

Separate from the edge case above, there's a bigger issue longer term.
This PR makes kgsl-dkms install work during rootfs creation by relying on local-debs being installed first, so the headers happen to be on disk before the dkms postinst runs. That holds today only because build-rootfs.sh runs local-debs and the manifest as two separate apt invocations. It stops holding the moment kernel packages are pulled from artifactory or debusine alongside everything else in package-manifest.json: that becomes a single apt transaction, dpkg orders configuration by the dependency graph, and kgsl-dkms doesn't depend on linux headers. There is nothing to force headers first.
This is coming soon anyway. We will publish the kernel to an apt repo as well, and I am working on that for the Debian side of pkg-linux-qcom now.
To me this is the argument for bundling the dkms module with the kernel package rather than ordering installs. I have implemented and validated that approach in pkg-linux-qcom#54, with kgsl as the listed module, on both Debian trixie (pulling kgsl from the debusine apt repo) and Ubuntu resolute (using kgsl from artifactory). The module is built against the exact kernel in the same packaging run and shipped inside the kernel package, so there is no runtime dkms, no headers on the target, and no install order to get right.
None of this blocks this PR. The ordering fix is right for where we are today.

For the dkms need to be integrated in rootfs by default, it's fine to bundle with kernel package. but DKMS (compiling on device) should also be supported as there are also tech area packages will be installed as per need (such as video dkms pkg), and end user or OEM customer may also install dkms pkgs (compile there kernel modules) on device.

Shoudi Li (@shoudil), on device building + installation of dkms is supported by default out of the box, given we provide the kernel headers with our nightly builds. In other words, DKMS package build time bundling mechanism and on-device support is not mutually exclusive.

Regardless, as I mentioned above, this PR is not blocked, the ordering fix is fine for where we are today, but we should keep in mind that very soon kernel packages will come from apt, so no control over ordering, hence either bundling mechanism, OR direct dkms package installation on running target, not during rootfs build.

[Bjordis Collaku (bjordiscollaku)]

For where we are today, its ok to merge and enable dkms package installation during rootfs build. I would not however consider this a solution to rely on, as the mechanism used to enforce ordering was not designed for this purpose, and the moment kernel packages (including headers) come from apt repo instead of local debs from bucket, this solution falls short.