On Wed, Feb 26, 2025 at 1:13 PM NoisyCoil <noisyc...@disroot.org> wrote: > > As for the actual contents of the package, the Rust bits, they are > binary files (and include an actual shared library), so my reasoning was > that they should belong to a different package than > linux-headers-@abiname@@localversion@, and be installed under /usr/lib > instead of /usr/src. This is what's currently being done for the kbuild > files.
Yeah, there are different viewpoints. The `.rmeta` are binary, in that they cannot be easily read at all, but on the other hand they are not fully build object files either. They are acting here like C headers, i.e. containing the same sort of information from other TUs/dependencies, so in that sense it makes sense for them to be there. The `.so` is definitely a built binary, but it is also "like a header" in the sense that it contains macros that in the C world would have been in a header. So it depends on whether the important "part" is 1) how they are "encoded", 2) whether they are "generated artifacts" or not, 3) whether splitting things into more packages is better or worse (for end users, for maintenance...). For instance, if the `.rmeta` files were generated text files that you could inspect with a text editor, would you put them in the same or a separate package? Do you have packages for other Kbuild artifacts that are required during the build, whether they are text or binary? I am clueless about distribution details, but I hope that helps somehow... By the way, it is great to see this kind of discussion -- when I was writing the step to avoid cleaning those files in the kernel build system, I wondered where distributions would end up putting them. Ah, and by the way, there will likely be way more `.rmeta`s and `.so`s generated (and where they get placed will change) in the future, since the system will change, so please keep that in mind (e.g. perhaps try to avoid hardcoding details and/or overfitting on the current setup). Thanks for the Cc! Cheers, Miguel
