Am Donnerstag, den 29.09.2005, 11:31 -0400 schrieb seth vidal:
> > #######################
> > Adding a repo with
> >
> > > ndiswrapper-1.1-1.i386.rpm
> > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm
> > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm
> >
> > in it and typing
> >
> > ># yum --disablerepo=updates-released --enablerepo=step_1 install 'kernel-module-ndiswrapper'
> >
> > will result in:
> >
> > [...]
> >
> > Seems yum prefers to install the kernel-module for the smp kernel and
> > therefor also installs that kernel even when a UP-Kernel is installed
> > already. Not very nice :-(
>
> how should yum have known which of those two you wanted? what are the
> clues it should use to know which of those to install? They're both
> named the same thing.
>[...]
> #######################
> > Okay, next test; Both UP- and SMP-Kernel are installed now (as it
> > normally is the case on SMP-Systems). typing
> > [...]
> > In and ideal world yum would install modules for both up and smp in that
> > case.
>
> okay but HOW can it know? You've described what you see as problem but
> you haven't described any way yum can know about what's you think
> _should_ be going on.
But it is a problem and we should (read: need to) solve it imho. How?
I'm not sure. We could
- package modules for all kernels in one package (I don't really like
this idea, but if this is the only solution we need to go it imho)
- fix our proposal so it works better with yum (hint's from you are
greatly appreciated)
- add support for yum somehow so it can resolve the dep correctly. I
unfortunately don't know neither yum nor python enough to fix that
myself :-|
> > #######################
> > Next test (only with SMP-kernel): New Ndiswrapper-Version. This is in
> > the repo now:
> >
> > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm
> > > kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4smp.i686.rpm
> > > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4.i686.rpm
> > > kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp.i686.rpm
> > > ndiswrapper-1.1-1.i386.rpm
> > > ndiswrapper-1.1-2.i386.rpm
> >
> > Works now! Did not with older yum version. Problem was: kernel-modules
> > normally are installed, not updated. But in this case the pgk needs to
> > be updated cause the files in the package would conflict otherwise.
>
> is this item marked as provided 'kernel-module'?
Yes, both 'kernel-module' and 'kernel-modules'. But while at it: What of
those two is the correct one? I see both in different areas of yum:
$ grep kernel-module $(rpm -ql yum | grep -v -e ChangeLog -e '.pyc$' )
/usr/lib/python2.4/site-packages/yum/config.py: 'kernel-modules',
/usr/lib/python2.4/site-packages/yum/depsolve.py: if txmbr.po.name.startswith("kernel-module-"):
> > Yum installs the new kernel, new ndiswrapper and new
> > kernel-module-ndiswrapper (as it should). But here we hit a problem with
> > our proposal. Older kernel-module-versions stay installed, but they
> > probably won't work with the new ndiswrapper-utils-package (maybe not in
> > the case of ndiswrapper, but ati-fglrx, nvidia-glx, qemu and other pkg.
> > likely will have this problem). I thought a Obsoletes in the
> > kernel-module-ndiswraper.spec like the following might help:
>
> so you think yum should remove other, older kernel modules even though
> it doesn't have the info available to know to do that?
If there is something like
Obsoletes: kernel-module-%{mainpkgname} < %{version}-%{release}
then IMHO yes. This (or something similar) afaics is needed when for
example
kernel-module-ndiswrapper-1.1-1.2.6.11_1.1369_FC4.i686.rpm
works with this
ndiswrapper-1.1-2.i386.rpm
userland package. But after a kernel update and a pgk-update this might
be installed:
kernel-module-ndiswrapper-1.1-2.2.6.12_1.1447_FC4.i686.rpm
ndiswrapper-1.2-1.i386.rpm
But ndiswrapper-1.2 might not work with the kernel-module from
ndiswrapper-1.1 (in case you boot 2.6.11_1.1369_FC4 now)
One solution to avoid this would be to rebuild the kernel-module for all
kernels ever released. But yum needs to install all those
kenrel-module-pgk. for all kernels then, too.
> > But huuuh, why are they still installed? afterwards?
> I'm not sure I understand the case you're describing here.
Look, it works if you use just rpm:
> [thl@localhost step_5]$ rpm -qa '*ndiswrapper*'
> [thl@localhost step_5]$ sudo rpm -Uvh ndiswrapper-1.1-2.i386.rpm kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp.i686.rpm
> Preparing... ########################################### [100%]
> 1:kernel-module-ndiswrapp########################################### [ 50%]
> WARNING: Module /lib/modules/2.6.11-1.1369_FC4smp/extra/ndiswrapper/ndiswrapper.ko is not an elf object
> 2:ndiswrapper ########################################### [100%]
> [thl@localhost step_5]$ rpm -qa '*ndiswrapper*'
> kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp
> ndiswrapper-1.1-2
> [thl@localhost step_5]$ sudo rpm -Uvh ndiswrapper-1.2-1.i386.rpm kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp.i686.rpm
> Preparing... ########################################### [100%]
> 1:kernel-module-ndiswrapp########################################### [ 50%]
> 2:ndiswrapper ########################################### [100%]
> [thl@localhost step_5]$ rpm -qa '*ndiswrapper*'
> kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp
> ndiswrapper-1.2-1
> [thl@localhost step_5]$ rpm -qp --obsoletes kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp.i686.rpm
> kernel-module-ndiswrapper < 1.2-1
> [thl@localhost step_5]$
But not in yum (even if it says it removes the old stuff):
> [thl@localhost step_5]$ rpm -qa '*ndiswrapper*'
> kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp
> ndiswrapper-1.1-2
> [thl@localhost step_5]$ sudo yum --disablerepo=updates-released --enablerepo=step_5 update
> Setting up Update Process
> Setting up repositories
> step_5 100% |=========================| 951 B 00:00
> extras 100% |=========================| 1.1 kB 00:00
> base 100% |=========================| 1.0 kB 00:00
> Reading repository metadata in from local files
> Resolving Dependencies
> --> Populating transaction set with selected packages. Please wait.
> ---> Package kernel-module-ndiswrapper.i686 0:1.2-1.2.6.12_1.1456_FC4smp set to be installed
> ---> Package ndiswrapper.i386 0:1.2-1 set to be updated
> --> Running transaction check
>
> Dependencies Resolved
>
> =============================================================================
> Package Arch Version Repository Size
> =============================================================================
> Installing:
> kernel-module-ndiswrapper i686 1.2-1.2.6.12_1.1456_FC4smp step_5 3.4 k
> replacing kernel-module-ndiswrapper.i686 1.1-2.2.6.11_1.1369_FC4smp
^^^^^^^^ <-- ???
> Updating:
> ndiswrapper i386 1.2-1 step_5 21 k
>
> Transaction Summary
> =============================================================================
> Install 1 Package(s)
> Update 1 Package(s)
> Remove 0 Package(s)
> Total download size: 25 k
> Is this ok [y/N]: y
> Downloading Packages:
> Running Transaction Test
> Finished Transaction Test
> Transaction Test Succeeded
> Running Transaction
> Installing: kernel-module-ndiswrapper ######################### [1/3]
> Updating : ndiswrapper ######################### [2/3]
> Cleanup : ndiswrapper ######################### [3/3]
>
> Installed: kernel-module-ndiswrapper.i686 0:1.2-1.2.6.12_1.1456_FC4smp
> Updated: ndiswrapper.i386 0:1.2-1
> Replaced: kernel-module-ndiswrapper.i686 0:1.1-2.2.6.11_1.1369_FC4smp
^^^^^^^^ <-- ???
> Complete!
> [thl@localhost step_5]$ rpm -qa '*ndiswrapper*'
> kernel-module-ndiswrapper-1.1-2.2.6.11_1.1369_FC4smp
still there ???
> kernel-module-ndiswrapper-1.2-1.2.6.12_1.1456_FC4smp
> ndiswrapper-1.2-1
> [thl@localhost step_5]$
Hope this makes things clearer.
> the biggest problem with the kernel-module packaging discussion is that
> all of the solutions y'all have come up with have been excruciatingly
> complex. We've discussed them on the yum-devel list and the result is
> 'ugh, these are painful' both to implement the code for and to develop
> the packages themselves. I'm not sure any solution will match up to
> everyone's concept of 'correct'.
Sure -- afaics everyone involved in this endless
kernel-module-proposal-discussion for fedora-extras had to accept some
things that he did not (and still does not) like (me, too). But we came
to no end. And I'd like to get this resolved even if I have to accept
more things I don't like -- as long as they work. I'm open for
suggestions.
So
--
Thorsten Leemhuis <fedora@xxxxxxxxxxxxx>
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
