Re: Attention kernel module project packagers!
by Axel Thimm
On Tue, Aug 15, 2006 at 07:51:48AM -0500, Josh Boyer wrote:
> > An argument against adopting kmdls presented by Thorsten Leemhuis is
> > that
> >
> > * it's too late now to fix it, we should live on with kmod bugs for
> > RHEL5's life-cycle (ending 2012 ...)
>
> Fedora is _not_ RHEL. Period. If they happen to use the same packaging
> scheme for modules, fine. That doesn't mean that Fedora cannot change
> it's standards during a particular RHEL's lifetime.
I agree that Fedora is not RHEL and vice versa. But once any idiom is
adopted into one of the two the other will have a very hard time to
get by, the bar is raised quite a bit.
Whether we like it or not (BTW I like it) the two distributions are
closely related and influence each-other.
> Therefore, I see no urgency in getting this changed. If kmdls is truly
> a better way, then it can be adapted when it has been fully discussed.
GFS is in FC6, too. Only the life-span of FC6 is shorter. Furthermore
yum developers want to know what scheme will need to be supported. As
argued in the wiki yum support for the current scheme is an endless
story, while the new proposed scheme already has it's fully working
plugin submitted.
Do you really want to see developers burn more time in a lost cause?
We could be using that developer time elsewhere.
--
Axel.Thimm at ATrpms.net
17 years, 7 months
Re: Attention kernel module project packagers!
by Axel Thimm
On Tue, Aug 15, 2006 at 01:48:05PM +0100, David Woodhouse wrote:
> On Tue, 2006-08-15 at 14:34 +0200, Axel Thimm wrote:
> > An argument against adopting kmdls presented by Thorsten Leemhuis is
> > that
> >
> > * it's too late now to fix it, we should live on with kmod bugs for
> > RHEL5's life-cycle (ending 2012 ...)
> >
> > * too many packages for kmod are written (but actually there is only one
> > in Fedora Extras 5, the rest is pending or in other repos and if
> > other repos count, then ATrpms has several dozens of kmdls :)
>
> I think this argument is invalid. We should ban _all_ module packages
> from Core and Extras anyway.
That's a valid viewpoint. Assuming Fedora Core/Extras indeed bans all
external kernel module packages, does it have the authority/interest
to maintain a kernel module packaging guide? If not who should?
--
Axel.Thimm at ATrpms.net
17 years, 7 months
Attention kernel module project packagers!
by Axel Thimm
Hi all,
there is currently a discussion about replacing the current kernel
module scheme ("kmod") with a new one ("kmdls"). This is because the
current scheme has some unfixable flaws. The proposed new scheme is
the one used at ATrpms, so if you ever used a kernel module package
from there you know how it is setup.
The kmdl approach has several nice features other than being resistant
to the design issues of the current setup.
* It is an interface/implementation design that can actually even be
used for the current (broken) setup. The specfile remains invariant.
* It uses one specfile/src.rpm for both userland and kernel modules,
e.g. one set of sources/patches/changelogs/bugzilla entries/owners.
* It is kernel and kernel-flavour agnostic, the same specfile/src.rpm
can be used for any kernel/flavour combination, even for such that
are yet to come.
* Has full yum-support with a 99-line python plugin, works even w/o
the plugin with a couple more keystrokes.
* Is field-proven for several years and managed to never have to
change the interface!
More details are on http://fedoraproject.org/wiki/AxelThimm/kmdls
It is important for FC6 and RHEL5 to make a decision on adopting
it. Currently GFS is being packaged in the old scheme which is known
to exhibit several flaws.
An argument against adopting kmdls presented by Thorsten Leemhuis is
that
* it's too late now to fix it, we should live on with kmod bugs for
RHEL5's life-cycle (ending 2012 ...)
* too many packages for kmod are written (but actually there is only one
in Fedora Extras 5, the rest is pending or in other repos and if
other repos count, then ATrpms has several dozens of kmdls :)
I think the flaws are severe enough to immediate block the current
kmod standard especially it's propagation into RHEL. The wiki above
shows that the design flaws propagate throughout any attemt to "fix"
yum (note: yum is not broken, there the quotes in "fix") and finally
end with the requirement that only one kernel can be supported in any
point of time. This is neither acceptable by Fedora, and even less be
RHEL.
The number of packages following the kmod standard are quite few and I
hope that the authors will not mind using the kmdl standard, but
that's for you to say.
Especially if you are a kernel module package author or want to become
one: Please check the wiki and if you care about it join the
discussion at fedora-packaging - reply-to set to that list, please
don't scatter the discussion on fedora-extras and fedora-devel, I'm
only calling for participation in the discussion to get this nailed
once and for all. Thanks!
--
Axel.Thimm at ATrpms.net
17 years, 7 months
get further rid of uname -r in the kmod stuff and solve the remaining kmod problem
by Thorsten Leemhuis
Hi!
As promised two hours ago a solution to solve the remaining problem with
the current kmod standard.
== Problem ==
So the *only* (*1) remaining problem of the current kmod standard IMHO
and AFAICS is this case:
Installed are:
kernel-2.6.17-1.2157_FC5
kmod-foo-1.2.2.6.17-1.2157_FC5
kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed
to the repo
Yum will install:
kernel-2.6.17-1.2171_FC5
kmod-foo-1.2.2.6.17-1.2171_FC5
kmod-foo-1.3.2.6.17-1.2171_FC5 is pushed to the repo
Yum will install:
kmod-foo-1.3.2.6.17-1.2171_FC5
*and remove*
kmod-foo-1.2.2.6.17-1.2157_FC5
kmod-foo-1.2.2.6.17-1.2171_FC5
in the same transaction because the module location of
kmod-foo-1.2.2.6.17-1.2171_FC5 and kmod-foo-1.3.2.6.17-1.2171_FC5 would
conflict. *This remove is the problem Axel complains about.*
Okay. This can be solved by having "uname -r" in the name and removing
the "Provides: kernel-module". But this creates other problems, e.g. at
least
- "new kernel-modules don't get installed without sepcial plugin"
- "uname -r is meaningless with the kabi stuff in RHEL".
A special yum-plugin could handle this two, but I prefer a different
solution.
(*1) -- if I missed anything please tell me
== Proposed solution ==
Install the kernel-module to
/lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko
and remove the
"Requires: kernel<?kernel-flavour>-<?kernel-version>
Details:
We avoid the file conflicts noted in "Problem" above due to the
"VERSION-RELEASE" in the path. So yum will always install the module and
there won't be any conflicts.
But how will the kernel find the module there? "/sbin/weak-modules", the
script from the kabi stuff can create links to the proper places. It
does this already for modules installed in the proper place and kernels
that have the compatible kabi. It would be needed to adjust some
pathnames in the script, but that shouldn't be to hard.
And why remove the Requires? Well, with the kabi stuff it might happen
(not that often in Fedora, but on RHEL often) that a module runs fine on
a newer kernel. We wouldn't have to build a new module in that case.
*But* this requires would fire back because the kmod will get removed by
the depsolver when the kernel is was build for gets uninstalled.
Therefor it needs to be removed.
== Remaining problem ==
When do old kmods get removed from the system? Yes, that's a remaining
problem (that's why it's listed here (-; ). I'll talk to jcmasters and
jeremy and will work out a solution if we agree to work further on this
idea. I'm sure we'll find a solution. The installonlyn-plugin maybe
could handle that together with the kabi stuff. weak-modules could mark
a installed module as unused and the plugin (or another plugin) could
remove it later.
== EOF ==
CU
thl
17 years, 7 months
kmdl proposal and kmod flaws
by Axel Thimm
I've created a wiki page outlining the kmdl design as well as showing
the flaws of the current kernel module scheme ("kmod"):
http://fedoraproject.org/wiki/AxelThimm/kmdls
It's focusing on the properties that are different in the two schemes
as such it is not a stand-alone specification.
The purpose of this write-up is to clarify the issues we're facing and
in light of this to stop further adoption of the current kernel module
scheme especially in GFS related parts in FC.
Please take some time to read it through, if I forgot some arguments I
will add them later to it. I would very much like to discuss it on
Thursday and vote on whether the kmod scheme should be blocked in
favour of adopting a kmdl scheme.
Beyond fedora-packaging's scope, e.g. hammering together a sane guide
for kernel modules, I'm willing to work with build infrastructure to
get the kmdl scheme firmly in place if this is approved and
ratified. I've done that in the past with ATrpms' buildsystem, so I
hope it will not be a too difficult task.
Furthermore I will work with upstream depsolver authors to get the
(trivial) kmdl support in all depsolvers. For yum and apt this can be
considered as already done, for smart I requested convenient hooks for
plugging in kmdl support which upstream already accepted. I will also
try to promote this scheme to the kmp/kerneldriver.org folks.
I think the kmdl scheme has a chance of becoming a wider-spread
standard that all rpm distros will benefit from.
Thanks.
--
Axel.Thimm at ATrpms.net
17 years, 7 months
Missing IRCs
by Ralf Corsepius
FYI,
I am currently moving and busy renovating our new home. Therefore, I'll
probably be only able to sporadically attend upcoming Packaging IRCs and
will probably miss some of them, at least though end of August.
Ralf
17 years, 7 months
missing this week's meetings
by Tom Callaway
Due to the fact that I will be on a plane somewhere between California
and Illinois on Thursday, I will not be able to attend this week's
Packaging or FESCo meetings.
~spot
--
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
17 years, 7 months
Fwd: When to use perl(:WITH_...) requires?
by Chris Weyl
Ok, maybe the third list is the charm :)
Could someone please explain to me -- or point me at a doc somewhere
-- what these provides are (I gather they indicate features perl was
built with), and, more importantly, when they should be used in a
spec? They seem as if they may be fairly important, but there's
nothing indicating when they should be used, if they're relevant to
noarch packages, etc etc, and neither the wiki nor google (oddly
enough) is shedding any light on it...
-Chris
---------- Forwarded message ----------
From: Chris Weyl <cweyl(a)alumni.drew.edu>
Date: Jul 31, 2006 8:15 AM
Subject: When to use perl(:WITH_...) requires?
To: Discussion related to Fedora Extras <fedora-extras-list(a)redhat.com>
Hey all --
Perl provides a number of provides flags, e.g.:
perl(:WITH_ITHREADS)
perl(:WITH_LARGEFILES)
perl(:WITH_PERLIO)
perl(:WITH_THREADS)
Most perl module spec files only deal with perl(:MODULE_COMPAT_5.8.8),
etc. But I see a number of them (arch-specific, typically), do use
these flags, along the lines of:
Requires: %(perl -MConfig -le 'if (defined $Config{useithreads}) {
print "perl(:WITH_ITHREADS)" } else { print "perl(:WITHOUT_ITHREADS)"
}')
etc, etc.
So, when should a packager use these? Should lines along the one
above be included for all flags in an arch-specific spec file? What's
a good rule of thumb here? (And, are these flags documented anywhere?
A cursory search of the wiki isn't turning up anything for me.)
-Chris
--
Chris Weyl
Ex astris, scientia
17 years, 8 months