[arch-dev-public] AUFS Patches in Kernel

[Paul Mattal]

Tom K wrote:
> Paul Mattal wrote:
>> Tom K 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 
>> 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