Dne 6.6.2017 v 20:06 Andreas Färber napsal(a):
Am 06.06.2017 um 10:33 schrieb Michal Marek:
Anyway, we drifted away from the topic a bit. I
posted the RFC to ask if
it is an acceptable trade off to have a shared mkspec-dtb script at the
cost of occasionally having empty dtb-* packages.
Could you give us a verbose explanation of what the RFC is doing?
It generates the %files sections for subpackages during rpm build, as
opposed to the mkspec-dtb script generating them. So the mkspec-dtb can
live in the packaging branch and contain the union of all the dtb
subpackage definitions from master, linux-next, vanilla, SLE15 and the
spec file will produce empty subpackages if the kernel does not have a
given dts file.
For arm64 I would be fine with an auto-generated list
Every vendor directory arch/arm64/boot/dts/foo/ should get its own
dtb-foo subpackage. That requires access to an expanded source tree,
which I miss in mkspec-dtb. Lua script in the .spec might be a solution?
This sounds interesting, but the RFC patch is not doing this. And I'm
afraid not even lua will help, because the spec file is parsed and all
macros evaluated before any of the build scriptlets is executed. We
would have to unpack the linux tarball and apply all patches inside the
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org