On Mon, Aug 14, 2006 at 05:33:14PM -0700, Toshio Kuratomi wrote:
> On Tue, 2006-08-15 at 01:57 +0200, Axel Thimm wrote:
> > On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote:
> > > /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko
> >
> > We already discussed that last week. You are moving the versioning
> > problem of the modules away from rpm to module-init-tools.
> >
> Yes and no. He's moving it to /sbin/weak-modules which seems like a
> logical place. weak-modules has to understand how to place kernel
> modules (or links to them) into the tree for depmod and friends to find
> them. Right now it does this for kabi. It's not a big conceptual
> stretch to think that it could do this for kmod as well.
>
> > You need to encode evr into the path and then teach depmod or any
> > helper application to order according to rpm's evr scheme.
> >
> Not necessarily. The helper application has to support a versioning
> scheme. We can make the ondisk directory layout match the helper's
> versioning scheme independent of the rpm evr. Certain versioning
> schemes on the part of the helper would be easier for us to work with,
> of course :-)
Then what use would the evr be at all? yum is taught to ignore it and
module-init-tools will ignore it, too. So if I issue a new release of
the module it get's either coinstalled, or if there really is no 1-1
mapping it may even start overwrite the previous module.
> > It's not an improvement, it's outsourcing a packaging/versioning
> > problem to the wrong domain.
>
> module-init-tools has to start supporting some sort of versioning scheme
> in order to support kabi. I'd argue that even without kabi, the tools
> should support a defined order in which they will choose what kernel
> modules to load. Leaving it undefined is a drawback for more than
> package managers.
>
>
> Axel, do you see any reason Thorsten's proposal wouldn't work?
Inability to replace a broken module? Ignoring evrs on modules?
E.g. I can never go back to a previous version if 3w-9xxx turns out to
be broken? Solving a problem by moving it to another domain?
kabi makes no sense for Fedora. It is soemthing for people wishing
there existed a kernel abi like ISV/IHVs with mostly closed source
content. Upstream kernel development has clearly stated that even due
to political reasons there will not be a kernel api, it's documented
in every kernel source and on every Fedora system in kernel-docs.
Vendors that will keep their kernels stable, e.g. only apply security
bugfixes, can say that their have some kind of kernel abi and even
give it a vendor-specfic name/value. Like RHEL4 was exporting kabi =
4.0 or similar. This makes only sense for RHEL and SLES, Fedora's kabi
changes with every kernel release. Even RHEL5 will change it's "kabi"
with every quaterly release, just like RHEL4U4 shows us. There is no
other way to support new drivers and introducing kernel abi *metrics*
is not introducing a kernel api/abi, which only the kernel developers
could introduce, which they deliberately won't.
So kabi is of use only to ISV/IHVs with potentially closed source (or
at least not commited upstream) of RHEL kernels within a quater of a
year. For Fedora it's only an obstruction, and kernel modules falling
under this category would not even make it into Fedora.
Don't get me wrong, I'n neither arguing against RHEL, ISVs, closed
source or anything, I'm just showing what the use is for to show that
we can't expect much.
What you can expect is indeed some limited recycling of kernel modules
of previous kernel/kernel module installations especially on RHEL. But
that's an orthogonal project to packaging them. weak-updates should
check wherever kernel modules of the kernel package and the external
kernel modules is placed and see whether the module is reusable.
--
Axel.Thimm at ATrpms.net
Attachment:
pgprJQF9VYFFp.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
