Kernel module packages (was - Re: Pre-Review: Asterisk)

[Tom 'spot' Callaway]

On Sat, 2005-04-02 at 19:24 -0700, Michal Jaegermann wrote:
> On Sat, Apr 02, 2005 at 04:56:01PM -0600, Tom 'spot' Callaway wrote:
> > 
> > Yes. Let me expand on my example.
> > 
> > I have three kernel packages installed:
> > 
> > kernel-2.6.10-2
> > kernel-smp-2.6.10-2
> > kernel-2.6.10-3
> > 
> > Each of these has a kernel-module-foo package installed alongside it:
> > 
> > kernel-module-foo-2.6.10_2-1
> > kernel-module-foo-2.6.10_2smp-1
> > kernel-module-foo-2.6.10_3-1
> 
> So far so good.  The only thing is that you want this kernel
> version id squeeze into a package version part while as for
> now people doing that have to make it a part of a name.

I'm not sure I know what you're saying here, but I don't want to put
kernel versioning in %{name}.

> There is, of course, this problem that during development a module
> source code may have its own version as well but one can possibly
> overload a release part to get around the issue.

I don't think we care. Bump the release if a newer version of the module
comes out. :)

Either way, that issue is minor.

> > We need to teach rpm to perform the following transaction (ignoring
> > normal dependency checks):
> 
> That is this tricky step.  It is not only a question of various
> rpm releases which users will try to apply to that all over the
> world but also various releated more-or-less official tools which
> are widely used. 

Well, I never said it would be easy. The nice thing about Fedora Extras
is that we can lay new foundations and build off of them, rather than
making ugly hacks for backwards compatibility. We didn't do
kernel-module-* packages for FC3, FC4 would be a good place to start.

(And if we wanted to do it for FC3, we could always errata rpm and
Require that version of rpm).

Otherwise, we have to hack each and every possible tool. If we do it in
rpm, then the tools at least have a standardized method to perform the
operation in the future.

> You goals are clear but now you have to find a way to distinguish
> packages which require such special treatment from those who
> are handled as upto now.  Here we start into some twisty passages
> as far as I can tell.  A special tag?  Some extra part of a name?

Well, right now, yum has a list of packages which are "install-only". We
could add a list of packages that are "upgrade-special". When we make
the rpm changes, we add a new flag, say "-S" (and the corresponding
hooks). Then, any package in the upgrade-special list (which could
include a kernel-module-foo mask) would be handled with the rpm -S
operation. I'm sure the apt and smart folks would be able to adapt to
the new mechanism as well.

Then, if it doesn't work, instead of trying to figure out which hack
implementation isn't working right, we have one implementation to
troubleshoot: the one in rpm.

Seth, I'd be very interested in your opinion on this, as it relates to
yum.

~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!