Tom K wrote:
Paul Mattal wrote:
A comment on the aufs package, now that it's in testing: Normally, for packages of this kind, we provide foo (the kernel module) and foo-utils (the userspace piece). This makes it easier for users to work with more than one kernel. I thought about this. If someone wants to maintain aufs for some other kernel, I'm willing to incur the overhead of splitting the
Tom K wrote: package, but otherwise not.
What are our list of supported kernels now? I know several went away recently.
We have two now - mind you, one of them is kernel26mm in unstable, and I believe that anyone who chooses to use it knows (or should know) what they're getting into. More to the point, my opinion on foo-utils separation is that it makes Arch more accommodating for people who want or need to build their own kernel, as well as allowing for new official kernel packages in the future.
I guess I have just never entirely understood the benefits of this convention-- and should point out that in my time as a dev we have tried about three different ways that were "the prevailing standard" for a while. Why split the package if the amount of "utils" is small? Can't the person who wants to build aufs for another kernel just make an "aufs-mm" package? How is that substantially worse? It's not immediately obvious to me that splitting kernel module packages in half creates more benefit than it costs-- having to track, upload, namcap, install, test, md5sum, etc. another package. It's one more place to make a mistake for every module package. What do others think? I'm generally in favor of treating package split for kernel modules the same way we treat it for other things.. try to do what the upstream distribution does, unless for efficiency's sake it makes a LOT more sense to split it (i.e. postgresql and postgresql-libs) - P