On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones <rjo...@redhat.com> wrote:
> On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
>> On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
>> <mat...@fedoraproject.org> wrote:
>> > On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote:
>> >> > Basically: it's hard,
>> >> it is a mess.
>> >> > but the only way we're going to get to a
>> >> > reasonably-small minimal image,
>> >> not true.
>> >
>> > Given that the kernel is currently a full quarter of the current image, I
>> > think it has to be.
>>
>> No you could also use a different kernel image;
>> build your own kernel;
>
> [I'll treat these two the same, because they amount to the same thing]
No the one means we ship a kernel-foo (like kernel-minimal or whatever
we call it) and the other is you build your own kernel.
> It's a considerable amount of work for everyone if people building
> minimal images have to use a different kernel.
If it is all about using kernel-minimal (or whatever it is called)
instead of kernel there is no extra work for the ones that build
minimal images at all.
> By using the same kernel as everyone else, it means that bug reports
> against the normal kernel package are relevant, and it means that the
> regular kernel gets more testing.
They can be built from the same srpm (same version, same patches
applied just some modules stripped).
> Also it's a lot of work to compile another kernel, when we've already
> got a team of (apparently 3) people doing this.
I'd argue it is less work then building a subpackage for every kernel module.
>> use a compressed filesystem,
>
> Every minimal image I've ever seen has been compressed to the max.
The image itself might be the installed system isn't ... which is the
think I was talking about (i.e this would allow you to save disk space
after installation).
The smaller image would just save bandwidth for the initial download
and/or space on mirrors.
>> don't use a kernel at all and some
>> container based approach instead of full virt for your cloud instances
>
> Unfortunately containers don't work for every application out there.
> Obviously *if* you can use a container, then you should, and you
> probably are already.
That might be true but I can't think of such applications right now.
Couldn't the applications you have in mind be modified / fixed to work
in such an environment?
>> Outside of the cloud use case the disk space added by modules and
>> firmware does not matter a bit (so I am ignoring this cases).
>
> It's partly disk space, it's more often the time taken to copy these
> images over the network (eg. when users download minimal images, or
> when they are PXE-booted).
In that case you should place the image on your internal network. I
doubt anyone uses a cloud infrastructure where you download the images
over the internet using a 56k modem.
>> So there are lots of other ways to achieve what you want without
>> splitting the kernel into hundreds of sub packages.
>
> I don't think we're talking "hundreds" of sub packages. Most people
> seem to be discussing a split into between 2 and 5 packages.
People where talking about splitting each module ("driver") into its
own package. This are far more then 5.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
