Sending an 88.7MB kernel package just for a single wifi fix?

[Adam Conrad]

On Fri, Jun 07, 2013 at 03:29:05PM -0500, Ron Johnson wrote:
> 
> So making linux-meta generate more highly granular binary packages
> is not worth the effort?

I'm not sure what problem you think this would solve.  We're not going
to split the linux source package into dozens of tiny module source
packages, which means that even if we split it out into a big mess of
binary packages for every module, we'd still be building them all for
every small fix.

They can't be "individually-versioned" in any "the old version stays
the same" sense, because we can't upload foo_1.2.3-4.deb to the archive
twice with different contents, I suspect you see why that would be
madness.

So, while breaking out the kernel into a ton of binary packages would
give you the option to say "no, I don't want to update most of this"
by putting the packages on hold, you could have just as easily said
"no, I don't want this massive update that only gives me an iwl fix
I don't care about" and put one package on hold.

To reiterate, without splitting the kernel into a bazillion different
source packages, we can't update drivers individually, and given that
upstream development happens in a monolithic tree, such a split would
be a nightmare to maintain and keep track of.

We could split into a bunch of binary packages, but every one of those
binary packages would update with every upload ANYWAY, so I don't see
how that would be any different from the status quo, except that it
would take a tiny bit longer to download and install every new kernel
due to packaging overhead.

... Adam