Josh Boyer writes:
> It's not simple. It's not easy. It buys you very very little and it
> leaves the maintainers having to continuously guess which package a
> module goes into. Then there's the requests to move them from one to
> the other.
I certainly buy those arguments. The whole thing m
On Thu, Oct 18, 2012 at 10:56:21AM -0500, Justin M. Forbes wrote:
> > I'm really against splitting the modules up into more subpackages,
> > regardless of how many it is. I will not spend any time looking at how
> > to do that. I won't spend time discussing further plans to do something
> > I don
On Thu, Oct 18, 2012 at 11:34:00AM -0400, Josh Boyer wrote:
> On Thu, Oct 18, 2012 at 11:15 AM, Matthew Miller
> wrote:
> > On Thu, Oct 18, 2012 at 10:44:58AM -0400, Josh Boyer wrote:
>
> >> At the moment though, all of this is just talk anyway. If something
> >> like this is to happen, someone
On Thu, Oct 18, 2012 at 11:15 AM, Matthew Miller
wrote:
> On Thu, Oct 18, 2012 at 10:44:58AM -0400, Josh Boyer wrote:
>> > I'm open to this idea, but I think it's nicer if one can go from the
>> > reduced
>> > selection to the full just by adding in the right package, not changing or
>> > removin
On Thu, Oct 18, 2012 at 11:10:11AM -0400, Josh Boyer wrote:
> Your definition of core modules is going to differ from mine, and the
> next persons, and the next.
Again: proposed definition is modules that get a functional system running
in some agreed-on list of virt and cloud providers. We decide
On Thu, Oct 18, 2012 at 10:44:58AM -0400, Josh Boyer wrote:
> > I'm open to this idea, but I think it's nicer if one can go from the reduced
> > selection to the full just by adding in the right package, not changing or
> > removing things. Unlike PAE or etc., I don't think we'd actually build
> >
On Thu, Oct 18, 2012 at 11:02 AM, Benny Amorsen wrote:
> Josh Boyer writes:
>
>> Of course we would. The entire point is to reduce the size, and the
>> only way to reduce the size is to build it with different config
>> options.
>
> Just splitting off most modules would do the job I would think.
Josh Boyer writes:
> Of course we would. The entire point is to reduce the size, and the
> only way to reduce the size is to build it with different config
> options.
Just splitting off most modules would do the job I would think... Of
course you can go smaller if you change config options, but
On Thu, Oct 18, 2012 at 10:39 AM, Matthew Miller
wrote:
> On Thu, Oct 18, 2012 at 10:33:27AM -0400, Bill Nottingham wrote:
>> > All of this can probably already be done with a new 'flavor' in the
>> > existing kernel.spec. I really wouldn't do the common/minimal split
>> > though. It just makes
On Thu, Oct 18, 2012 at 10:33:27AM -0400, Bill Nottingham wrote:
> > All of this can probably already be done with a new 'flavor' in the
> > existing kernel.spec. I really wouldn't do the common/minimal split
> > though. It just makes it more complicated for not a whole lot of gain.
> >
> > The
Josh Boyer (jwbo...@gmail.com) said:
> > You'd want to do it something like that.
> >
> > kernel-minimal as you say but with a Provides: kernel, kernel-common as you
> > say.
> >
> >
> > I'd introduce a third metapackage just "kernel" that requires both of those
> > and implicitly Provides: kernel
On Wed, Oct 17, 2012 at 3:43 PM, Reindl Harald wrote:
> Am 17.10.2012 18:52, schrieb Dave Jones:
>> With virtualised environments supporting pci/usb passthrough, where do you
>> draw the line on what hardware to support in a hypothetical kernel-cloud
>> package ?
>
> with vmxnet3, vmw_pvscsi, vmw
On Wed, Oct 17, 2012 at 2:38 PM, Jesse Keating wrote:
> On 10/17/2012 11:32 AM, Chris Adams wrote:
>>
>> I would think the only "sane" way would be to just change the packaing,
>> not actually build multiple kernels (or even multiple packages with
>> kernels).
We already build multiple kernels.
On 10/17/2012 01:46 PM, David Malcolm wrote:
Random worry about this: would this work OK with yum's "keep the last 3
kernels around" functionality?
That's obviously something that would have to be tested if this is
attempted.
I'm not signing up for this work, I was just making a suggestion
On Wed, 2012-10-17 at 11:38 -0700, Jesse Keating wrote:
> On 10/17/2012 11:32 AM, Chris Adams wrote:
> > I would think the only "sane" way would be to just change the packaing,
> > not actually build multiple kernels (or even multiple packages with
> > kernels).
> >
> > For example, a "kernel-minim
Am 17.10.2012 18:52, schrieb Dave Jones:
> With virtualised environments supporting pci/usb passthrough, where do you
> draw the line on what hardware to support in a hypothetical kernel-cloud
> package ?
with vmxnet3, vmw_pvscsi, vmw_balloon to support vSphere
(all included in the upstream ker
On Wed, 17 Oct 2012 14:40:39 -0400
Matthew Miller wrote:
> On Wed, Oct 17, 2012 at 11:38:13AM -0700, Jesse Keating wrote:
> > I'd introduce a third metapackage just "kernel" that requires both
> > of those and implicitly Provides: kernel. Most people would just
> > get the "kernel" metapackage w
On Wed, Oct 17, 2012 at 11:38:13AM -0700, Jesse Keating wrote:
> I'd introduce a third metapackage just "kernel" that requires both
> of those and implicitly Provides: kernel. Most people would just
> get the "kernel" metapackage when a transaction asks for something
> to provide "kernel", but if
On Wed, Oct 17, 2012 at 01:32:23PM -0500, Chris Adams wrote:
> There will always be requests to move modules from -common to -minimal,
> and it shouldn't be a big fight (I would bet most requests would be
> pretty obvious). That already exists some for -modules-extras.
That's why I suggest defini
On 10/17/2012 11:32 AM, Chris Adams wrote:
I would think the only "sane" way would be to just change the packaing,
not actually build multiple kernels (or even multiple packages with
kernels).
For example, a "kernel-minimal" that has the kernel and the "core"
modules loaded in most installs (e.g
Once upon a time, Richard W.M. Jones said:
> It really depends on what 'kernel-minimal' is. If it's the
> same kernel (identical vmlinuz) with groups of modules, then I'm
> assuming this is the same as what everyone else is proposing.
I would think the only "sane" way would be to just change the
On Wed, Oct 17, 2012 at 07:34:22PM +0200, drago01 wrote:
> 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.
It really depends on what 'kernel-minimal' is. If it's the
same kernel (identic
On Wed, Oct 17, 2012 at 6:34 PM, drago01 wrote:
> On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones wrote:
>> On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
>>> On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
>>> wrote:
>>> > On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote:
>
On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones wrote:
> On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
>> On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
>> wrote:
>> > On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote:
>> >> > Basically: it's hard,
>> >> it is a mess.
>> >>
On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
> On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
> 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 m
On Wed, 17 Oct 2012, Dave Jones wrote:
On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
> > 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;
> use a compressed
On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
> > 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;
> use a compressed filesystem, don't use a kernel at all a
On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
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 ful
On Wed, Oct 17, 2012 at 11:37:29AM -0400, Josh Boyer wrote:
> What the hell did you drink today, Bill? Basically what you're
> suggesting is that Fedora move to a kmod model for everything. Which
> means you'd have to install all of them by default anyway or the kernel
> team would be swamped wit
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.
> > so if t
On Wed, Oct 17, 2012 at 4:51 PM, Matthew Miller
wrote:
> On Wed, Oct 17, 2012 at 10:47:34AM -0400, Bill Nottingham wrote:
>>> If you're suggesting 1, I'd be really really opposed to that. It would
>>> make packaging in kernel.spec even more of a nightmare than it already
>>> is.
> [...]
>> Both -
On Wed, Oct 17, 2012 at 10:51 AM, Matthew Miller
wrote:
> On Wed, Oct 17, 2012 at 10:47:34AM -0400, Bill Nottingham wrote:
>>> If you're suggesting 1, I'd be really really opposed to that. It would
>>> make packaging in kernel.spec even more of a nightmare than it already
>>> is.
> [...]
>> Both
On Wed, Oct 17, 2012 at 10:47:34AM -0400, Bill Nottingham wrote:
>> If you're suggesting 1, I'd be really really opposed to that. It would
>> make packaging in kernel.spec even more of a nightmare than it already
>> is.
[...]
> Both - if people want firmware packages split out of linux-firmware, i
Josh Boyer (jwbo...@gmail.com) said:
> > However, if you go down that route, the kernel should be the same way,
> > the firmware should be separate subpackages, and requires should be done at
> > the module -> firmware level by generating it from the MODULE_FIRMWARE tags.
> > (Unless you're relyin
On Tue, Oct 16, 2012 at 9:07 AM, Bill Nottingham wrote:
> Peter Robinson (pbrobin...@gmail.com) said:
>> > I wonder... could we make linux-firmware optional?
>> >
>> > I would expect many virt env's don't need any firmware to work...
>> > (but of course I could be wrong).
>>
>> It use to be option
On Tue, Oct 16, 2012 at 09:07:56AM -0400, Bill Nottingham wrote:
> > > I wonder... could we make linux-firmware optional?
> However, if you go down that route, the kernel should be the same way,
> the firmware should be separate subpackages, and requires should be done at
> the module -> firmware l
Peter Robinson (pbrobin...@gmail.com) said:
> > I wonder... could we make linux-firmware optional?
> >
> > I would expect many virt env's don't need any firmware to work...
> > (but of course I could be wrong).
>
> It use to be optional, I know on the olpc xo-1 it use to be optional
> and there s
37 matches
Mail list logo
