1:48 p.m.
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
2:19 p.m.
New subject: kernel-module packaging (was Re: Re: DKMS into Fedora Extras)
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!
10:51 p.m.
New subject: kernel-module packaging (was Re: Re: DKMS into Fedora Extras)
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
1:34 a.m.
New subject: kernel-module packaging (was Re: Re: DKMS into Fedora Extras)
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
7:28 a.m.
New subject: kernel-module packaging (was Re: Re: DKMS into Fedora Extras)
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!
1:17 a.m.
New subject: kernel-module packaging (was Re: Re: DKMS into Fedora Extras)
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 -
1:24 a.m.
New subject: kernel-module packaging (was Re: Re: DKMS into Fedora Extras)
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
2:42 p.m.
New subject: kernel-module packaging (was Re: Re: DKMS into Fedora Extras)
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:
1. confusing to users wanting to install the kernel-module
2. 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.
2:41 p.m.
New subject: DKMS into Fedora Extras
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?
2:48 p.m.
New subject: DKMS into Fedora Extras
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!
6:47 p.m.
New subject: DKMS into Fedora Extras
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.
8:44 p.m.
New subject: DKMS into Fedora Extras
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!
10:01 p.m.
New subject: DKMS into Fedora Extras
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
10:20 p.m.
New subject: DKMS into Fedora Extras
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!
10:28 p.m.
New subject: DKMS into Fedora Extras
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
12:20 a.m.
New subject: DKMS into Fedora Extras
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 -
12:26 a.m.
New subject: DKMS into Fedora Extras
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
8:11 a.m.
New subject: DKMS into Fedora Extras
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.
9 a.m.
New subject: DKMS into Fedora Extras
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
9:18 a.m.
New subject: DKMS into Fedora Extras
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!
9:57 a.m.
New subject: DKMS into Fedora Extras
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.
10:10 a.m.
New subject: DKMS into Fedora Extras
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 ;-)
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
10:17 a.m.
New subject: DKMS into Fedora Extras
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.
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
10:31 a.m.
New subject: DKMS into Fedora Extras
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!
9:25 a.m.
New subject: DKMS into Fedora Extras
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 -
10:02 a.m.
New subject: DKMS into Fedora Extras
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.
10:35 a.m.
New subject: DKMS into Fedora Extras
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
1:10 a.m.
New subject: DKMS into Fedora Extras
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 -
1:19 a.m.
New subject: DKMS into Fedora Extras
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
6:30 a.m.
New subject: DKMS into Fedora Extras
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
10:45 p.m.
New subject: DKMS into Fedora Extras
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
2:47 p.m.
New subject: DKMS into Fedora Extras
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 :)
1:13 a.m.
New subject: DKMS into Fedora Extras
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.
6995
days inactive
6998
days old
packaging@lists.fedoraproject.org
33 comments
7 participants
participants (7)
-
Chuck Anderson -
Panu Matilainen -
Paul Nasrat -
seth vidal -
Thorsten Leemhuis -
Tom Callaway -
Ville Skyttä