On Wed, Oct 17, 2012 at 6:34 PM, drago01 <drago01@xxxxxxxxx> wrote:
> On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:
>> On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
>>> On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
>>> <mattdm@xxxxxxxxxxxxxxxxx> 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.
Not necessarily, I was the person wanting it split down and only to
groups of packages like "usb" for usb devices, "arm" for arm only
firmware, "storage" for enterprise storage, "wifi" etc.
Peter
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
