On Mon, 2005-02-21 at 13:19 -0600, Tom 'spot' Callaway wrote:
On Mon, 2005-02-21 at 14:05 -0500, seth vidal wrote:
we might be able to do something like: if two kernel modules have the same name but different versions then it's an update.
that would require:
- kernel-version-in-module-package-name
- provides: kernel-module in the header
- consistent use.
I think that's doable. Lets take this thread over here: https://www.redhat.com/mailman/listinfo/fedora-packaging
Right now yum does the following:
if it is a kernel or kernel module (ie provides kernel or provides kernel-modules) then the package is installed not updated.
if we can come up with a consistent pattern for when a kernel-module will be updated but not installed then I can add it into the function that determines that sort of stuff.
Right now I'm thinking: kernel modules must have kernel-version-release in the package name for the kernel module - this makes for irritating package naming and cvs naming but <shrug>
if a kernel-module has a new version available then it should be updated, not installed. else - kernel modules are installed.
Now - how do we go about getting kernel modules pulled in when new kernels come out. Clearly it can't be via an update b/c the package name will change, so yum won't notice it as an update. Doing it via obsoletes is just yucky. We need something like a kernel-module registry. So we can track kernel-modules you have installed by something OTHER than package name.
Thoughts?
-sv
For clarity sake, let me state the problem as I see it first:
PROBLEM: Kernel modules not in Fedora Core's kernel packages are difficult to package, track, and upgrade, due to dependency issues and the assumption of multiple kernels.
To repeat Seth, right now, if it is a kernel or kernel module (ie provides kernel or provides kernel-modules) then the package is installed not updated. If we can come up with a consistent pattern for when a kernel-module will be updated but not installed then yum can get the added logic to deal with this case.
So, what should happen with all of these cases?
Case 1: kernel-2.6.10-3_FC3 installed. User runs: "yum install kernel-module-unionfs" to get the unionfs module RPM for kernel-2.6.10-3_FC3.
Case 2: kernel-2.6.10-3_FC3, kernel-2.6.10-4_FC3, and kernel-2.6.10-5_FC3 are installed. User runs: "yum install kernel-module-unionfs" to get the unionfs module RPM for all installed kernels. (I think it is safe to assume that if a user has multiple kernels installed that they would like an addon kernel module to be installed for all of them)
Case 3: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 are installed. User runs: "yum update kernel-module-unionfs" (either implicitly, or as part of a generic update all), and kernel-module-unionfs-2.6.10_3_FC3-2 exists in Fedora Extras.
Case 4: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 are installed. User runs: "yum update kernel" (either implicitly, or as part of a generic update all), and both kernel-2.6.10-4_FC3 kernel-module-unionfs-2.6.10_4_FC3-1 exists in Fedora Extras.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
A couple of items to mention:
new kernels in fc4 should have:
Provides: kernel-%{arch} = ver-rel
in them now.
so kernel-modules should definitely dep on: kernel-%{arch} so we don't get any arch mixups b/t kernels and kernel-modules.
-sv
Am Montag, den 21.02.2005, 14:19 -0600 schrieb Tom 'spot' Callaway:
For clarity sake, let me state the problem as I see it first:
So, what should happen with all of these cases?
[...]
Case 4: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 are installed. User runs: "yum update kernel" (either implicitly, or as part of a generic update all), and both kernel-2.6.10-4_FC3 kernel-module-unionfs-2.6.10_4_FC3-1 exists in Fedora Extras.
Case 4.1: What if kernel-module-unionfs-2.6.10_4_FC3-1 is released one/two days behind kernel-2.6.10-3_FC3? This can happen due to build errors that first need to get fixed. Or the build system or all that have access are sleeping. Or simply due due mirroring "problems" when core/updates/ is already mirrored, but extras/ not yet.
CU thl
On Tue, 2005-02-22 at 08:34 +0100, Thorsten Leemhuis wrote:
Case 4.1: What if kernel-module-unionfs-2.6.10_4_FC3-1 is released one/two days behind kernel-2.6.10-3_FC3? This can happen due to build errors that first need to get fixed. Or the build system or all that have access are sleeping. Or simply due due mirroring "problems" when core/updates/ is already mirrored, but extras/ not yet.
That's a valid point, since the kernel package doesn't depend on kernel-module-*. Anyone have any idea how to work around this in a sane manner?
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Tue, 22 Feb 2005, Tom 'spot' Callaway wrote:
On Tue, 2005-02-22 at 08:34 +0100, Thorsten Leemhuis wrote:
Case 4.1: What if kernel-module-unionfs-2.6.10_4_FC3-1 is released one/two days behind kernel-2.6.10-3_FC3? This can happen due to build errors that first need to get fixed. Or the build system or all that have access are sleeping. Or simply due due mirroring "problems" when core/updates/ is already mirrored, but extras/ not yet.
That's a valid point, since the kernel package doesn't depend on kernel-module-*. Anyone have any idea how to work around this in a sane manner?
The current apt implementation of the kernel-module handling prints out warnings if you have kernel modules installed which are not available for the new kernel you're about to install by doing some "fun" calculations with provides and versions. Alternatively it could hold back from installing the new kernel until all the modules are available for the new kernel as well.
So, it's possible (at least in the current uname-in-package-name scheme) but fun it is not.
- Panu -
The current apt implementation of the kernel-module handling prints out warnings if you have kernel modules installed which are not available for the new kernel you're about to install by doing some "fun" calculations with provides and versions. Alternatively it could hold back from installing the new kernel until all the modules are available for the new kernel as well.
So, it's possible (at least in the current uname-in-package-name scheme) but fun it is not.
My concern is not with it being fun but with it being: 1. confusing to users wanting to install the kernel-module 2. fragile
-sv
On Wed, 2005-02-23 at 02:24 -0500, seth vidal wrote:
The current apt implementation of the kernel-module handling prints out warnings if you have kernel modules installed which are not available for the new kernel you're about to install by doing some "fun" calculations with provides and versions. Alternatively it could hold back from installing the new kernel until all the modules are available for the new kernel as well.
So, it's possible (at least in the current uname-in-package-name scheme) but fun it is not.
My concern is not with it being fun but with it being:
- confusing to users wanting to install the kernel-module
- fragile
IMHO the minimum requirement is to get the above mentioned warnings. Auto-pulling them in is a nice feature too, and has worked for me with apt almost perfectly thus far.
On Mon, Feb 21, 2005 at 02:48:40PM -0500, seth vidal wrote:
Right now I'm thinking: kernel modules must have kernel-version-release in the package name for the kernel module - this makes for irritating package naming and cvs naming but <shrug>
if a kernel-module has a new version available then it should be updated, not installed. else - kernel modules are installed.
I think that adding the kernel version-release to the package name of the kernel-module-foo packages is a bad idea. I think it would be better to have the kernel-module-foo actual version-release tag be the same as the corresponding kernel version-release tag. Then you could just parallel install the kernel-module-foo packages in the same way that the kernel is parallel installed.
Now - how do we go about getting kernel modules pulled in when new kernels come out. Clearly it can't be via an update b/c the package name will change, so yum won't notice it as an update. Doing it via obsoletes is just yucky. We need something like a kernel-module registry. So we can track kernel-modules you have installed by something OTHER than package name.
Using a package name that never changes would avoid this problem...
Of course, then we have a problem if you want to update a kernel module without updating the corresponding kernel package. Would this happen that often?
On Mon, 2005-02-21 at 15:41 -0500, Chuck R. Anderson wrote:
I think that adding the kernel version-release to the package name of the kernel-module-foo packages is a bad idea. I think it would be better to have the kernel-module-foo actual version-release tag be the same as the corresponding kernel version-release tag. Then you could just parallel install the kernel-module-foo packages in the same way that the kernel is parallel installed.
Give me an example for both cases (the case you don't like and the case that you do)?
Using a package name that never changes would avoid this problem...
Package name? Or package version? These things exist to identify the package, not so we can work around gaps in our infrastructure.
Of course, then we have a problem if you want to update a kernel module without updating the corresponding kernel package. Would this happen that often?
Assume it will. :)
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Mon, Feb 21, 2005 at 02:48:44PM -0600, Tom 'spot' Callaway wrote:
I think that adding the kernel version-release to the package name of the kernel-module-foo packages is a bad idea. I think it would be better to have the kernel-module-foo actual version-release tag be the same as the corresponding kernel version-release tag. Then you could just parallel install the kernel-module-foo packages in the same way that the kernel is parallel installed.
Give me an example for both cases (the case you don't like and the case that you do)?
I don't like this:
Name: kernel-module-unionfs-2.6.10-3_FC3 Version: 1.0.9 Release: 15
because it requires special magic in the depsolver to pull in specially named packages when kernels get installed/erased. It is a bad idea to start parsing out parts of a package name. I would also think that it would require the user to do things like "yum install kernel-module-unionfs-2.6.10-3_FC3" which is ugly.
I was contemplating this:
Name: kernel-module-unionfs Version: 2.6.10 Release: 3_FC3
but that causes the problem below:
Of course, then we have a problem if you want to update a kernel module without updating the corresponding kernel package. Would this happen that often?
Assume it will. :)
So, how about we completely divorce the module version number from the kernel version number, since you basically want to be able to update, build, and evolve them separately, and the "version" of an external kernel module doesn't really have any relation to a kernel version-release anyway:
Name: kernel-module-unionfs Version: 1.0.9 Release: 15
But you probably still want to stick some info about which kernel each build of the kernel-module package is built against (purely cosmetic, NOT to be used programmatically by depsolvers). Usually the Release: field is used for this purpose. This also gets us unique EVR's which IIRC we need for parallel-installable packages:
Name: kernel-module-unionfs Version: 1.0.9 Release: 2.6.10_3_FC3.15
The depsolvers would rely solely on Provides/Requires deps:
Name: kernel-module-unionfs Version: 1.0.9 Release: 2.6.10_3_FC3.15 Requires: kernel = 2.6.10-3_FC3
exactarch's would have to be matched, of course. smp is fine, because kernel-smp provides kernel-smp:
Name: kernel-module-smp-unionfs Version: 1.0.9 Release: 2.6.10_3_FC3.15 Requires: kernel-smp = 2.6.10-3_FC3
So now lets go through the cases:
Case 1: kernel-2.6.10-3_FC3 installed. User runs: "yum install kernel-module-unionfs" to get the unionfs module RPM for kernel-2.6.10-3_FC3.
yum notices that kernel-module-unionfs is multiple-installable. It finds that it can only satisfy the deps with kernel-module-unionfs-1.0.9-2.6.10-3_FC3. Since kernel is i686, it installs kernel-module-unionfs-1.0.9-2.6.10-3_FC3.i686.
Case 2: kernel-2.6.10-3_FC3, kernel-2.6.10-4_FC3, and kernel-2.6.10-5_FC3 are installed. User runs: "yum install kernel-module-unionfs" to get the unionfs module RPM for all installed kernels. (I think it is safe to assume that if a user has multiple kernels installed that they would like an addon kernel module to be installed for all of them)
yum notices that kernel-module-unionfs is multiple-installable. It finds all the matching kernel-module-unionfs-* packages whose deps can be satisfied with the existing installed packages *that are multiple-installable*. If there are multiple install candidates within each Provides: N = E:V-R of installed multiple-installable packages, it picks the one with the highest EVR (to handle updated kernel-module-foo pacakges).
If the mechanism for signaling multiple-installable is the same as the current installonlypkgs= (would be advantageous to use pre-existing config statements wherever possible IMO), then one might think that this would make "yum install kernel" install all available kernels, too. If this is undesired, you can make yum require that there exist at least one Require: on another multiple-install package in order to invoke the special muliple-install behavior. Otherwise, standard install behavior is used.
Case 3: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 are installed. User runs: "yum update kernel-module-unionfs" (either implicitly, or as part of a generic update all), and kernel-module-unionfs-2.6.10_3_FC3-2 exists in Fedora Extras.
To clarify for my naming convention, if these are installed:
kernel-2.6.10-3_FC3 kernel-module-unionfs-1.0.9-2.6.10_3_FC3.15
And this exists in Extras:
kernel-module-unionfs-1.0.9-2.6.10_3_FC3.16 (Requires: kernel = 2.6.10-3_FC3)
yum notices that there is more than candidate that satisfies the dep kernel-module-unionfs Requires kernel = 2.6.10-3_FC3, where both "kernel-module-unionfs" and "kernel" are marked multiple-installable. It picks the highest EVR on the repo, in this case 1.0.9-2.6.10_3_FC3.16.
Case 4: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 are installed. User runs: "yum update kernel" (either implicitly, or as part of a generic update all), and both kernel-2.6.10-4_FC3 kernel-module-unionfs-2.6.10_4_FC3-1 exists in Fedora Extras.
If these are installed:
kernel-2.6.10-3_FC3 kernel-module-unionfs-1.0.9-2.6.10_3_FC3.15
And these exist in Extras:
kernel-2.6.10-4_FC3 kernel-module-unionfs-1.0.9-2.6.10_4_FC3.15 (Requires: kernel = 2.6.10-4_FC3)
yum notices that there are newer packages available that are multiple-installable. The first one, kernel, doesn't have any Requires: on any other multiple-installable packages, so it just installs (not updates) it as usual. The second one, kernel-module-unionfs, does have a Requires: on a multiple-installable package (kernel). yum proceeds as in Case 1 or Case 3.
How does this sound? I think this should just "do the right thing" without any more configuration than the existing "installonlypkgs=" we have today.
On Mon, 2005-02-21 at 19:47 -0500, Chuck R. Anderson wrote:
How does this sound? I think this should just "do the right thing" without any more configuration than the existing "installonlypkgs=" we have today.
It seems reasonable to me, Seth, what do you think?
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Mon, 2005-02-21 at 20:44 -0600, Tom 'spot' Callaway wrote:
On Mon, 2005-02-21 at 19:47 -0500, Chuck R. Anderson wrote:
How does this sound? I think this should just "do the right thing" without any more configuration than the existing "installonlypkgs=" we have today.
It seems reasonable to me, Seth, what do you think?
I think it still leaves in a bad place for when a kernel module is updated w/o changing kernel versions.
if you have: kernel-module ver=1.0.9 release=2.6.10-1ac-15
and an update which is: kernel-module ver=1.1.0 release=2.6.10-1ac-15
so the kernel module has changed version - but not kernel.
so it really, actually, needs to be updated.
which isn't a problem - except that b/c the pkg name is the same - an update will remove ALL the older versions for that package.
so if you have: kernel-module ver=1.0.9 release=2.6.9-1ac-15
installed - then that goes away on an update.
Maybe I missed it but I'm not sure how his proposal solves for that case.
-sv
On Mon, 2005-02-21 at 23:01 -0500, seth vidal wrote:
Maybe I missed it but I'm not sure how his proposal solves for that case.
Wouldn't this be true for kernel too? $name remains the same, yet older kernels are not removed on update.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Mon, 2005-02-21 at 22:20 -0600, Tom 'spot' Callaway wrote:
On Mon, 2005-02-21 at 23:01 -0500, seth vidal wrote:
Maybe I missed it but I'm not sure how his proposal solves for that case.
Wouldn't this be true for kernel too? $name remains the same, yet older kernels are not removed on update.
kernels are never updated.
ever. -sv
On Mon, 21 Feb 2005, seth vidal wrote:
I think it still leaves in a bad place for when a kernel module is updated w/o changing kernel versions.
if you have: kernel-module ver=1.0.9 release=2.6.10-1ac-15
and an update which is: kernel-module ver=1.1.0 release=2.6.10-1ac-15
so the kernel module has changed version - but not kernel.
so it really, actually, needs to be updated.
which isn't a problem - except that b/c the pkg name is the same - an update will remove ALL the older versions for that package.
so if you have: kernel-module ver=1.0.9 release=2.6.9-1ac-15
installed - then that goes away on an update.
Maybe I missed it but I'm not sure how his proposal solves for that case.
I don't see it solving that either. Nobody *likes* those kernel-module-foo-2.6.10-1.741_FC3 type names but nobody has come up with a solution which covers all the cases without the kernel version in package name. Oh and I think special name-based hacks are required for this anyway... and I seriously doubt you want those in yum proper.
If I understood correctly the Xtrigger-stuff should allow pushing the special kernel-module handling to a separate script/module and enabled only where needed, somewhat like my apt lua-script which handles (or at least tries to :) this mess.
- Panu -
I don't see it solving that either. Nobody *likes* those kernel-module-foo-2.6.10-1.741_FC3 type names but nobody has come up with a solution which covers all the cases without the kernel version in package name. Oh and I think special name-based hacks are required for this anyway... and I seriously doubt you want those in yum proper.
If I understood correctly the Xtrigger-stuff should allow pushing the special kernel-module handling to a separate script/module and enabled only where needed, somewhat like my apt lua-script which handles (or at least tries to :) this mess.
We could spawn things out of xtrigger -however xtrigger will play hell with a gui front end for output reasons.
thoughts? -sv
On Mon, Feb 21, 2005 at 11:01:05PM -0500, seth vidal wrote:
so the kernel module has changed version - but not kernel. so it really, actually, needs to be updated.
which isn't a problem - except that b/c the pkg name is the same - an update will remove ALL the older versions for that package.
so if you have: kernel-module ver=1.0.9 release=2.6.9-1ac-15
installed - then that goes away on an update.
Maybe I missed it but I'm not sure how his proposal solves for that case.
I think you missed my logic for this case. If there would be an update for a kernel-module, and the update has the same Requires: as an existing installed kernel-module of the same name, then replace the installed one with the new one, but don't touch any others that have Requires: for a different kernel. Repeat for each kernel version. In other words, you limit updates to within the universe of each distinct Requires: on another multiple-installable package, so that you don't wipe out the other parallel installations.
I think you missed my logic for this case. If there would be an update for a kernel-module, and the update has the same Requires: as an existing installed kernel-module of the same name, then replace the installed one with the new one, but don't touch any others that have Requires: for a different kernel.
and I think you missed my point: rpm can't do that.
it doesn't just update a single older version - it updates ALL older versions.
-sv
On Tue, 2005-02-22 at 10:00 -0500, seth vidal wrote:
I think you missed my logic for this case. If there would be an update for a kernel-module, and the update has the same Requires: as an existing installed kernel-module of the same name, then replace the installed one with the new one, but don't touch any others that have Requires: for a different kernel.
and I think you missed my point: rpm can't do that.
OK, so if rpm isn't smart enough to do that, can we teach yum to deal with this case?
If new package is of type "foo" (where foo is kernel-module in this case), check for existing installed package of the same name. If exists, rpm -e existing, then rpm -ivh new package. (yes, i realize this is a bit icky, but this case is nasty as is)
Hopefully, nothing is depending on a kernel-module package (we can always enforce this by saying anything that DOES depend on a kernel-module package should be packaged with it).
How many kernel-module packages are we really considering here?
openafs: include the tools and the kernel module in the same package unionfs: ditto
Now, assuming that livna wants to use the same mechanism, there are several other binary-only modules (ati & nvidia drivers), but no other packages should be depending on them.
And when we remove the kernel-module rpm, the driver is either loaded or not. If loaded, its resident in memory, and the user can rmmod it and reload if they want to avoid a reboot. If not, we're fine.
thoughts?
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Tue, Feb 22, 2005 at 09:18:32AM -0600, Tom 'spot' Callaway wrote:
OK, so if rpm isn't smart enough to do that, can we teach yum to deal with this case?
I think we can and should. Yum has already been taught to install certain packages instead of update them. This is just a slightly modified case, where you erase then install, instead of update.
Am Dienstag, den 22.02.2005, 09:18 -0600 schrieb Tom 'spot' Callaway:
Now, assuming that livna wants to use the same mechanism, there are several other binary-only modules (ati & nvidia drivers), but no other packages should be depending on them.
spot, just FYI. I'm also involved in livna also and maintain two out of three kernel-module-packages there (and got my hands dirty on the other one and two in QA also).
And yes, we (at least I) want to use the same mechanism in extras and livna-packages ;-)
Am Dienstag, den 22.02.2005, 09:18 -0600 schrieb Tom 'spot' Callaway:
On Tue, 2005-02-22 at 10:00 -0500, seth vidal wrote:
Hopefully, nothing is depending on a kernel-module package (we can always enforce this by saying anything that DOES depend on a kernel-module package should be packaged with it).
That is bad. Take the ati and nvidia drivers for example. They depend on a kernel-module. Packaging them together is no option there. It would be stupid to package a ~100k module together with a 3,5 MB (numbers from the ATI driver) graphics driver is stupid for kernel updates. Also parallel installation will make problems again.
How many kernel-module packages are we really considering here?
In extras we had ony a kerel module for a thinkpad-driver IIRC. We had als in the FC1 days.
And as I wrote yesterday already:
Also I'm wondering how we should deal with kernel-modules in extras in general. davej/Core refuses everything that is not upstream for a good reason. If we put everything in extras it looks a bit "odd" IMHO.
On Tue, 2005-02-22 at 17:17 +0100, Thorsten Leemhuis wrote:
Also I'm wondering how we should deal with kernel-modules in extras in general. davej/Core refuses everything that is not upstream for a good reason. If we put everything in extras it looks a bit "odd" IMHO.
Well, we could just push every kernel module addon package away, on the grounds that its not upstream, but that almost feels like passing the buck.
I could set policy as "if its licensed compatible with the kernel, it should go upstream, and if not, it goes to Livna." Then I'd be passing the problem to Thorsten.
openafs and unionfs are two cases that are valid today for FE, that people seem interested in.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Tue, 22 Feb 2005, seth vidal wrote:
I think you missed my logic for this case. If there would be an update for a kernel-module, and the update has the same Requires: as an existing installed kernel-module of the same name, then replace the installed one with the new one, but don't touch any others that have Requires: for a different kernel.
and I think you missed my point: rpm can't do that.
it doesn't just update a single older version - it updates ALL older versions.
Mm, you *could* do that by doing a "manual" update of erasing the specific older version of the package and installing the new, instead of using rpm's normal update procedure. Actually this has been brought up before on the subject of kernel-module packages, on freshrpms-list IIRC. I wasn't excited about doing such a "manual" update from apt for this special case then and I'm not now either :)
- Panu -
On Tue, Feb 22, 2005 at 05:25:15PM +0200, Panu Matilainen wrote:
Mm, you *could* do that by doing a "manual" update of erasing the specific older version of the package and installing the new, instead of using rpm's normal update procedure. Actually this has been brought up before on the subject of kernel-module packages, on freshrpms-list IIRC. I wasn't excited about doing such a "manual" update from apt for this special case then and I'm not now either :)
I'd rather see a special case of an erase/install manual update, rather than a special case of parsing package name tags, splitting off the kernel version, and matching that to installed kernel versions.
Mm, you *could* do that by doing a "manual" update of erasing the specific older version of the package and installing the new, instead of using rpm's normal update procedure. Actually this has been brought up before on the subject of kernel-module packages, on freshrpms-list IIRC. I wasn't excited about doing such a "manual" update from apt for this special case then and I'm not now either :)
<sigh> God this is going to be ugly.
Like really, really, really ugly.
-sv
On Tue, 22 Feb 2005, seth vidal wrote:
Mm, you *could* do that by doing a "manual" update of erasing the specific older version of the package and installing the new, instead of using rpm's normal update procedure. Actually this has been brought up before on the subject of kernel-module packages, on freshrpms-list IIRC. I wasn't excited about doing such a "manual" update from apt for this special case then and I'm not now either :)
<sigh> God this is going to be ugly.
Like really, really, really ugly.
No s**t. I think dealing with that should be possible from apt's lua-scripts just like the current "magic" is but I haven't given it much thought since the current scheme "just works" with the uname-in-package-name scheme which.. I don't like either but at least it works.
For your (and others') <cough> amusement, there's a long and lively discussion about kernel-module dependencies, naming schemes etc at http://lists.freshrpms.net/pipermail/freshrpms-list/2004-March/thread.html Something inside my head keeps saying there's a nice solution to this all but we're just too blind to see it. Most likely I've just been too much into mushrooms lately however... :P
- Panu -
No s**t. I think dealing with that should be possible from apt's lua-scripts just like the current "magic" is but I haven't given it much thought since the current scheme "just works" with the uname-in-package-name scheme which.. I don't like either but at least it works.
For your (and others') <cough> amusement, there's a long and lively discussion about kernel-module dependencies, naming schemes etc at http://lists.freshrpms.net/pipermail/freshrpms-list/2004-March/thread.html Something inside my head keeps saying there's a nice solution to this all but we're just too blind to see it. Most likely I've just been too much into mushrooms lately however... :P
One thing we could do. But I'm hesitant to do it.
We could ask if, as an option for adding a package into the ts as an update it takes an optional header of the package it is updating.
I'm not sure how ugly this would be for rpm but it would allow for the flexibility we'd need/want here.
is Paul on this list? any ideas?
-sv
On Wed, 2005-02-23 at 02:19 -0500, seth vidal wrote:
We could ask if, as an option for adding a package into the ts as an update it takes an optional header of the package it is updating.
I'm not sure how ugly this would be for rpm but it would allow for the flexibility we'd need/want here.
is Paul on this list? any ideas?
Yes, I'm here. Just playing catch up. I'll try and digest these things from an rpm/rpm-python point of view.
If I'm understanding it you want something ala:
ts.addReplacement(hdr1, hdr2)
which is equivalent to:
addInstall(hdr1, blah, 'i') addErase(hdr2)
or am I just on crack.
Paul
Yes, I'm here. Just playing catch up. I'll try and digest these things from an rpm/rpm-python point of view.
If I'm understanding it you want something ala:
ts.addReplacement(hdr1, hdr2)
which is equivalent to:
addInstall(hdr1, blah, 'i') addErase(hdr2)
or am I just on crack.
sorta. I was actually thinking of an extension to addInstall(hdr1, 'u')
so if you have multiple packages of the same name installed rpm would know to only update one of them - not all of them.
sorta like being able to set which package gets obsoleted out of a set of multiply installed packages.
-sv
On Wed, 2005-02-23 at 09:10 +0200, Panu Matilainen wrote:
Something inside my head keeps saying there's a nice solution to this all but we're just too blind to see it. Most likely I've just been too much into mushrooms lately however... :P
s/mushrooms/kernel module packaging/ This stuff is strong enough by itself :)
On Mon, 2005-02-21 at 14:48 -0500, seth vidal wrote:
Right now I'm thinking: kernel modules must have kernel-version-release in the package name for the kernel module - this makes for irritating package naming and cvs naming but <shrug>
I support this because I haven't seen a better solution. But IMO the CVS naming is a no go. There should be one dir per one module package in CVS, not one for each module package for a specific kernel, otherwise it's a major PITA to maintain. I imagine it isn't too hard to achieve that.
packaging@lists.fedoraproject.org
-
Chuck Anderson -
Panu Matilainen -
Paul Nasrat -
seth vidal -
Thorsten Leemhuis -
Tom Callaway -
Ville Skyttä