On Fri, Aug 18, 2006 at 04:08:49PM +0100, Jon Masters wrote:
> On Thu, 2006-08-17 at 09:01 +0200, Axel Thimm wrote:
>
> > The suggestion Thorsten is implying is that you should try under
> >
> > /lib/modules/*/foo/1/1.2.3/2
> > /lib/modules/*/foo/1/1.2.3/1
> > /lib/modules/*/foo/1/1.2.2/1
> > /lib/modules/*/foo/0/10/1
> >
> > in that order for several coinstalled versions of foo *for the same
> > kernel* (the folder names are epoch/version/release), and you would
> > have to use rpmvercmp to compare the folder names.
> >
> > That's a package problem that is being pushed to the wrong domain. For
> > the same kernel (or kabi) the module should have one version
> > installed. Otherwise the argument of having multiple versions of
> > anything, not only kernel modules applies.
>
> That's a problem. Some people genuinely want to have more than one
> version of a module installed - I think in the longer run that this
> would be a good thing to be able to support, though I much prefer using
> modinfo meta-data to solve it rather than the file location.
>
> We should compel people to use module versions properly in their source
^^^^^^
That's kernel module authors. Convincing them to use proper versioning
is even more difficult than convincing any other upstream author to do
the same. Just consider that every module get's its own versioning and
some even go back and forth, real-life examples: madwifi and 3w-9xxx.
Before you get them to do a proper versioning, we'll have rpm rewritten.
Furthermore: Even if the versioning of kernel modules was as "good" as
other conventional upstream versioning, you still have the same needs
for epochs and releases like for conventional packages:
o epoch for when the version seems to go backwards in time in whatever
versioning metrics
o release for fixing bugs/patching up kernel modules that won't
change their version.
E.g. if I repackage foo-1.2.3-1 with a fix in foo-1.2.3-2, I don't
want to see them both installed at the users' systems and hope m-i-t
select the proper one.
So when you think about coinstalling modules *for the same
kernel/kabi*, you will inevitably both need to introduce full evr
semantics on m-i-t level and will have to have rpmvercmp semantics in
place. That means coding the evr into the path, since there is no
place in the module's metadata *and* the different modules for the
same kernel should not overlap.
It is wrong to shift rpm's (or the depsolver's) work to m-i-t. We just
lose the overview in keeping the packages managed at one place and the
problem still needs to be solved.
> code IMO since it's deliberately designed to support what we need from
> it - and it's trivial enough to warn on build/load of non-kernel
> provided modules that they don't have good version info inside.
--
Axel.Thimm at ATrpms.net
Attachment:
pgpoGPvcHdHog.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
