* John Kacur <jkacur@xxxxxxxxxx> wrote: > On Tue, 8 Nov 2011, Ted Ts'o wrote: > > > On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote: > > > I guess you can do well with a split project as well - my main > > > claim is that good compatibility comes *naturally* with > > > integration. > > > > Here I have to disagree; my main worry is that integration makes > > it *naturally* easy for people to skip the hard work needed to > > keep a stable kernel/userspace interface. > > > > The other worry which I've mentioned, but which I haven't seen > > addressed, is that the even if you can use a perf from a newer > > kernel with an older kernel, this causes distributions a huge > > amount of pain, since they have to package two different kernel > > source packages, and only compile perf from the newer kernel > > source package. This leads to all sorts of confusion from a > > distribution packaging point of view. > > > > For example, assume that RHEL 5, which is using 2.6.32 or > > something like that, wants to use a newer e2fsck that does a > > better job fixing file system corruptions. If it were bundled > > with the kernel, then they would have to package up the v3.1 > > kernel sources, and have a source RPM that isn't used for > > building kernel sources, but just to build a newer version of > > e2fsck. Fortunately, they don't have to do that. They just pull > > down a newer version of e2fsprogs, and package, build, test, and > > ship that. > > > > In addition, suppose Red Hat ships a security bug fix which means > > a new kernel-image RPM has to be shipped. Does that mean that > > Red Hat has to ship new binary RPM's for any and all tools/* > > programs that they have packaged as separate RPM's? Or should > > installing a new kernel RPM also imply dropping new binaries in > > /usr/bin/perf, et. al? There are all sorts of packaging questions > > that are raised integration, and from where I sit I don't think > > they've been adequately solved yet. > > > > This in practice is not a big deal. > > There are many approaches for how the RPM can be built, but basically > getting the perf source is just a matter of > make perf-tar-src-pkg or friends such as > make perf-tarbz2-src-pkg > which will create perf-3.2.0-rc1.tar, and perf-3.2.0-rc1.tar.bz2 > respectively which can be used for the src rpms. This tar ball can be used > as a separate package or subpackage. Great - the 'perf is impossible for distros' was a common counter argument early in the perf project's lifetime - i'm glad it turned out to be bogus in practice. Would it further simplify distro side life if all utilities deeply related to the kernel got built together and came in a single well working package? kutils-3.2.0-rc1.rpm or such. They would always upgrade together with the kernel so there would never be any forced backporting or separate errata pressure, beyond the existing flow of -stable fixes. We do -stable fixes for tools/perf/ as well, for stability/security fixes, naturally - other tools would have to follow the regular kernel maintenance process to manage high priority fixes. Basically distros could rely on the kernel and its utilities being a coherent whole, which is expected to work together, which is maintained and built together and which, if it regresses, is handled by the regular -stable kernel regressions process with high priority. I expect it would grow one by one - it's not like we can or want to force utilities to go into the kernel proper. I'd also expect that new tools would be added initially - not existing ones moved. My question to you would rather be, would it make the life of distro release engineers gradually easier if this space grew gradually over the years, adding more and more critical tool functionality? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
