On 09/03/2009 03:22 PM, Tom "spot" Callaway wrote:
On 09/03/2009 02:25 PM, Hans de Goede wrote:
> Note that we have the same problem with any package which does static
> linking against an lgpl library (such as glibc).
This is (one of the big reasons) why we only permit static linking with
explicit approval from FESCo.
I'm really very uncomfortable with the generic initrd not including
matching sources in the corresponding SRPM (whether that is kernel or
some dedicated "generic-dracut" package is immaterial). The answer of
"the sources are in the Fedora lookaside cache, somewhere, go track it
down yourself" isn't really sufficient for me.
Unfortunately, I can't think of a good way to package up a generic
initrd in a way that we can provide source properly. I'm open to
suggestions though.
~spot
The problem is how we associate objects in rpmbuild/koji. You can look at RPM building as
transitioning between 3 types of objects:
1) We begin with a pile of SOURCES for a package.
2) We compile those sources into a collection of ARTIFACTS
3) We cpio, compress, and tag those artifacts into one or more PACKAGES (typically one.
More if we have sub-packages).
The problem here is that the ARTIFACTS phase isn't really represented. We relate
packages to sources and that's that. If we tracked the results of the build process
independently of the RPM itself, we could track much more complicated relationships
between packages (for example, the kernel borrowing bits of the output from the last glibc
build to make its initrd).
I believe there are package managers that do this. RPM isn't well suited to it though.
It would take a lot of muscle.
--CJD