On 01/15/2016 01:18 PM, Josh Boyer wrote:
On Fri, Jan 15, 2016 at 8:06 AM, Jóhann B. Guðmundsson
<johannbg@xxxxxxxxx> wrote:
On 01/15/2016 07:37 AM, Peter Robinson wrote:
Hi All,
This is a small series of changes to the filtering of kernel modules from
core. Each patch is a mostly self contained subject like usb/drm/network
protocols. I split them out to separate patches just to make each one easier
to see the bits that were changing.
If I can recall correctly, one of the modular kernel packaging changes was
that you could only have kernel-core installed so I have to ask wont this
break running systems for users that are relying on things being in
kernel-core since then?
Not exactly. The work was done to reduce the size of the kernel
needed for cloud installations and it was extended to include the set
of modules needed to boot KVM guests. There has never been the
guarantee that kernel-core alone would work on any particularly subset
of physical hardware.
No but the change proposal implied you could just install kernel-core
and get away with it as long the included modules worked.
And since the kernel modular change was aimed to achieve the smallest as
well as the most flexible footprint I have to ask is there something
preventing putting every kernel module in it's own sub package (
kernel-module-<module> ) to prevent ( potential ) breakage in the future as
people go smaller and smaller which will eventually lead to what I have
described here.
Time, and packaging pain is what is preventing it.
Contribute time to an community is work in one form or another with the
only prevention being people themselves.
Also, the 80%
solution as it exists today is sufficient for everyone's needs at the
moment, so investing further to split everything up like that isn't
really worthwhile.
Sorry this does not make any sense to me and throwing some arbitrary
percentage number even less so since instability in package management (
that includes kernel splits and merges repeat through history ) and ui
is what's driving people away from the community.
To me this basically says that it's worthwhile to cause breakage and end
users frustration which eventually lead to less contribution to the
community ( which means less hours in total in the contributed time pool
) but that has no meaningful end result in the long term so that's
probably not what you are hinting at even if it was we live in an ever
changing environment ( IoT, ARM,Servers,
Cloud,Containers,Phones,Tablets,Desktops which are all things Fedora is
currently trying to support for example ) and the only way to adapt to
that is to precisely to be as modular as possible with package
expressing correct dependency since that's the only effectively way to
combine what ever mixture of components put together to reflects that
environment in any given point in time.
To be able to get there ( assuming people want to actually fix what's
broken ) it first and for most takes time even thou some people may
subjectively view that task at hand based on their emotion or
perspective and categories them as hard or easy while I personally dont
see things that way since an task is just an task to me nor easy nor
hard. and to be there we have to begin on the core/baseOS and the first
component there with kernel to start working on ( by completely
splitting it ) then fix the failure of the fundamental task of fesco/fps
of providing and ensuring components express correct package dependency.
Fixing that will probably be the most time consuming task since I know
for fact after crawling through around 500 - 1000 components with the
most troublesome being those that dont express any. It's like package
maintainers of those components seem to have magically expected
core/baseOS in the distribution to be frozen in time since FC1 o_O.
Those components are the one that will be the most likely the cause most
breakage as well.
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
