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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
