7:16 p.m.
After weeks of discourse on IRC and mailing list discussions, we seem to
be unable to make progress toward an amicable agreement.
What seems to be the issue is that RPM does not allow any clean solution
to the kernel module packaging problem. Both kmod and kmdl are
comprised of ugly hacks in order to overcome the design limitations of
RPM. Both kmod and kmdl have pros and cons, and neither is a clearly
agreed by all parties as being technically superior.
The FESCO side is disconcerted by this situation because a great deal of
effort over years was put into making and ratifying today's kmod
standard. On the other hand, there is some hope for middle-ground
because of stated willingness to further revise kmod to overcome
remaining limitations.
It is the decision of me, Max, and Spot, to put a hold on publishing any
further kmod modules pending the result the Kernel Module Packaging
Standard conference call. Time/date of this call is to be determined,
but we are aiming for this Friday, August 18th at a time that is
workable for both American EDT and Europe. Perhaps 1PM EDT would work,
the usual timeslot of FESCO meetings? Perhaps this timeslot wont work.
If you feel it is important to attend but you are unable to make this
time, please make it known in this thread.
In order to make this meeting manageable, we must limit the number of
attendees. Invited are the existing members of the Fedora Packaging
Committee, Thorsten Leemhuis and certain Red Hat employees relevant to
this discussion. Please talk to me directly if you have been an active
contributor to this in the past but are not included in this invitee list.
My personal feeling is that it is way too late to throw out kmod, OTOH
it is important that we discuss each point to see if kmod can be improved.
If the packaging committee cannot come to key agreements, then the
matter will be escalated to the Fedora Project Board who will make the
key decisions.
Warren Togami
wtogami(a)redhat.com
11:47 p.m.
Warren Togami schrieb:
After weeks of discourse on IRC and mailing list discussions,
[...]
In order to make this meeting manageable, we must limit the number
of
attendees. Invited are the existing members of the Fedora Packaging
Committee, Thorsten Leemhuis and certain Red Hat employees relevant to
this discussion. Please talk to me directly if you have been an active
contributor to this in the past but are not included in this invitee list.
There were no discussions on IRC (Axel invited me once but I couldn't
join it -- private matters were blocking, sorry). I really would prefer
a IRC disussion over a Teleconference -- that's IMHO the better to
coordinate and a lot easier for those of us that don't speak english
that often.
CU
thl
1:11 a.m.
Thorsten Leemhuis wrote:
Warren Togami schrieb:
> After weeks of discourse on IRC and mailing list discussions,
[...]
> In order to make this meeting manageable, we must limit the number of
> attendees. Invited are the existing members of the Fedora Packaging
> Committee, Thorsten Leemhuis and certain Red Hat employees relevant to
> this discussion. Please talk to me directly if you have been an
> active contributor to this in the past but are not included in this
> invitee list.
There were no discussions on IRC (Axel invited me once but I couldn't
join it -- private matters were blocking, sorry). I really would prefer
a IRC disussion over a Teleconference -- that's IMHO the better to
coordinate and a lot easier for those of us that don't speak english
that often.
Hmm, good point about English, it could very well make it difficult for
us to communicate. The idea of the teleconference was our crazy
American idea. That's how we often do things...
The important thing is for someone neutral to drive the process,
hopefully Spot can do it. The driver of this meeting must act as
mediator. We must all stay away from recriminations and stick to the
technical points. Go down all questions and concerns and discuss each
point. If someone doesn't understand then implications must be explained.
Then matters must come down to a vote after context is understood.
Perhaps given this format, IRC may work better. We can think about this
a bit more as we also figure out if all of the key players are available
at that time on Friday. We'll see.
Warren Togami
wtogami(a)redhat.com
1:35 a.m.
Warren Togami schrieb:
Thorsten Leemhuis wrote:
> Warren Togami schrieb:
>> After weeks of discourse on IRC and mailing list discussions,
> [...]
>> In order to make this meeting manageable, we must limit the number of
>> attendees. Invited are the existing members of the Fedora Packaging
>> Committee, Thorsten Leemhuis and certain Red Hat employees relevant
>> to this discussion. Please talk to me directly if you have been an
>> active contributor to this in the past but are not included in this
>> invitee list.
> There were no discussions on IRC (Axel invited me once but I couldn't
> join it -- private matters were blocking, sorry). I really would
> prefer a IRC disussion over a Teleconference -- that's IMHO the better
> to coordinate and a lot easier for those of us that don't speak
> english that often.
Hmm, good point about English, it could very well make it difficult for
us to communicate.
IRC IMHO has even one more benefit that would help in this especially in
this case: You can paste URLs to mails in the archive or on the web.
Further: multiple people can write in parallel (that's a advantage and a
disadvantage at the same time). A disadvantage of telephone conferences:
they often consume all of your attention -- in an IRC-Meeing you can go
afk for one minute if there is a need to and read what happened in between
The important thing is for someone neutral to drive the process,
hopefully Spot can do it. The driver of this meeting must act as
mediator. We must all stay away from recriminations and stick to the
technical points. Go down all questions and concerns and discuss each
point. If someone doesn't understand then implications must be explained.
Agreed.
Then matters must come down to a vote after context is understood.
Just to make sure: One vote per "technical point"?
Perhaps given this format, IRC may work better.
+1
We can think about this
a bit more as we also figure out if all of the key players are available
at that time on Friday. We'll see.
k
CU
thl
4:26 a.m.
On Wed, Aug 16, 2006 at 08:35:18AM +0200, Thorsten Leemhuis wrote:
Warren Togami schrieb:
>Thorsten Leemhuis wrote:
>>Warren Togami schrieb:
>>>After weeks of discourse on IRC and mailing list discussions,
>> [...]
>>>In order to make this meeting manageable, we must limit the number of
>>>attendees. Invited are the existing members of the Fedora Packaging
>>>Committee, Thorsten Leemhuis and certain Red Hat employees relevant
>>>to this discussion. Please talk to me directly if you have been an
>>>active contributor to this in the past but are not included in this
>>>invitee list.
>>There were no discussions on IRC (Axel invited me once but I couldn't
>>join it -- private matters were blocking, sorry). I really would
>>prefer a IRC disussion over a Teleconference -- that's IMHO the better
>>to coordinate and a lot easier for those of us that don't speak
>>english that often.
>
>Hmm, good point about English, it could very well make it difficult for
>us to communicate.
I wouldn't mind and the main disputants here are non-English natives
both. It would be probably the rest not understanding our
pronounciation ;)
IRC IMHO has even one more benefit that would help in this especially
in
this case: You can paste URLs to mails in the archive or on the web.
We can fire up an IRC session in parallel to paste in things.
Further: multiple people can write in parallel (that's a
advantage and a
disadvantage at the same time). A disadvantage of telephone conferences:
they often consume all of your attention -- in an IRC-Meeing you can go
afk for one minute if there is a need to and read what happened in between
That's the real disadvantage of IRC: You wait for someone's reply who
went on doing other things and while waiting you decide to do other
stuff yourself. In a typical IRC session there is a round-about in
dialogs of 5/minute while voice gets up to 15/minute.
I'm in for any form, IRC sessions have the big advantage of being
archivable and searchable.
--
Axel.Thimm at ATrpms.net
3:08 a.m.
On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote:
After weeks of discourse on IRC and mailing list discussions, we seem
to
be unable to make progress toward an amicable agreement.
What seems to be the issue is that RPM does not allow any clean solution
to the kernel module packaging problem. Both kmod and kmdl are
comprised of ugly hacks in order to overcome the design limitations of
RPM. Both kmod and kmdl have pros and cons, and neither is a clearly
agreed by all parties as being technically superior.
The FESCO side is disconcerted by this situation because a great deal of
effort over years was put into making and ratifying today's kmod
standard. On the other hand, there is some hope for middle-ground
because of stated willingness to further revise kmod to overcome
remaining limitations.
As I didn't have the time to follow all these discussions and threads,
and to have a basis for such an IRC-conference, I would appreciate if
Axel and Thorsten could write up a "my proposal at one glance" outline.
I would be particularly interested in their proposals's macroscopic
behavior and interaction with rpmbuild, mock, rpm -U|-I, the impact on
yum/apt/smart.
If the packaging committee cannot come to key agreements, then the
matter will be escalated to the Fedora Project Board who will make the
key decisions.
"Order di Mufti" as we call this in German, the worst of
all management
principles :(
Ralf
5:43 a.m.
On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote:
On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote:
As I didn't have the time to follow all these discussions and threads,
and to have a basis for such an IRC-conference, I would appreciate if
Axel and Thorsten could write up a "my proposal at one glance" outline.
I setup an executive summary of the comparison for you and for other
people external to the discussion until now who would like to join in
on Friday:
http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
and the details remain under
http://fedoraproject.org/wiki/AxelThimm/kmdls
So if something looks unclear in the tabular summary please check the
second link for a more verbose version.
I would be particularly interested in their proposals's
macroscopic
behavior and interaction with rpmbuild, mock, rpm -U|-I, the impact on
yum/apt/smart.
I tried to add every issue that has been raised to date.
And I have even rated the issues in an objective and fair manner as
possible (I added all arguments against kmdls and even rated them
negative). I invite anyone to add his ratings, too. While the single
items are all factually correct (nobody really denies the technical
background anymore) the differences between kmdl and kmod opponents
are in the personal weighing of consequences.
--
Axel.Thimm at ATrpms.net
8:46 a.m.
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
I setup an executive summary of the comparison for you and for other
people external to the discussion until now who would like to join in
on Friday:
http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
I'm almost certainly unable to join any meeting before next week
(including tomorrow's packaging and fesco meetings) and will have only
very limited access to mail during that time too. It's unlikely that my
general opinion about this stuff would change, so it's not really
necessary for me to attend the meeting -- don't postpone it for me.
To reiterate: if consensus says change is needed, and there's competent
manpower available to take care of things *soon*, so be it. The only
things I feel strongly about are that rejecting module packages from
FC/FE altogether would be profoundly odd at this point, and that the
scope of the discussion needs to be limited to whether uname-r gets
moved to the packages' names and its direct unavoidable consequences --
the only real technical design issue. Everything else in the "kmdl"
proposal is more or less cosmetics and implementation details, and
adopting it would mean throwing away quite a bit of work (reinventing
the wheel from the POV of the current scheme and its adopters) from
several parties for questionable gain.
http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName
This draft has potential.
If it comes down to a vote, mine can be registered as:
* -1 for rejecting module packages
* +0.5 for moving uname-r *if* there is strong evidence that it will be
acceptable for all major stakeholders (Fedora, RHEL, kerneldrivers.org
in particular), -0.5 otherwise
* -1 to other kmdl change suggestions
(BTW, this is off topic, but if this discussion fails to produce useful
widely accepted results, I wouldn't outright reject DKMS or DKMS-like
mechanisms as an alternative; while these don't meet everyone's
requirements, they'd be vastly better than nothing at all.)
While the single items are all factually correct
Strong words. The above summary and the detailed doc contains several
inaccuracies and omissions (eg. about agnosticity, flexibility, buildsys
support, kabi, support(ability) in other distros etc), luckily mostly in
the less important parts. I guess this is due to not understanding all
aspects of the current scheme and the environment it is designed to work
in. I won't spend time detailing those because I don't have time to do
that right now, and even if I had, IMO there are no real reasons to
consider/discuss its adoption besides the uname-r move bit. (Yes, sucky
statement, but shrug, it's the best I can do in the time I have
available for this at the moment.)
9:18 a.m.
Ville Skyttä schrieb:
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
and that the
scope of the discussion needs to be limited to whether uname-r gets
moved to the packages' names and its direct unavoidable consequences --
the only real technical design issue.
I agree that this is the only "only real technical design issue" of the
current standard. But I'd don't think that we hastily should change this
detail. Two weeks should be enough to look at this precise problem
closer and work out and test the solutions (one solution of course is
uname-r, but I *currently* think it's not the best one -- especially not
for RHEL, where the uname -r might be confusing). I roughly another way
how this might be fixed in
https://www.redhat.com/archives/fedora-packaging/2006-August/msg00086.html
already.
Everything else in the "kmdl"
proposal is more or less cosmetics and implementation details, and
adopting it would mean throwing away quite a bit of
s/a bit/a lot of/ IMHO -- it were probably around 15 to 20 IRC meetings
IIRC (probably even more) and a lot of traffic on the mailinglists where
FESCo (including jeremy and spot) discussed each and every detail in
depth. We even evaluated most of the stuff that's made different in the
kmdl scheme during that phase. We for example looked at a debuginfo
solution similar to the one in Axels kmdls and chose not to use it; we
looked at a one srpm approach for both userland and kernel-module and
decided to split. That are -- as scop outlined above -- implementation
details that are already used in some packages in Extras, under Review
for Extras and another repo that's using the same scheme. We IMHO
shouldn't change them without a good reason.
work (reinventing
the wheel from the POV of the current scheme and its adopters) from
several parties for questionable gain.
Otherwise I'm strongly in agreement with that paragraph.
[...]
CU
thl
12:16 p.m.
On Wed, Aug 16, 2006 at 04:46:10PM +0300, Ville Skyttä wrote:
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
* +0.5 for moving uname-r *if* there is strong evidence that it will be
acceptable for all major stakeholders (Fedora, RHEL, kerneldrivers.org
in particular), -0.5 otherwise
chicken and egg problem?
> While the single items are all factually correct
Strong words. The above summary and the detailed doc contains several
inaccuracies and omissions (eg. about agnosticity, flexibility, buildsys
support, kabi, support(ability) in other distros etc), luckily mostly in
the less important parts. I guess this is due to not understanding all
aspects of the current scheme and the environment it is designed to work
in. I won't spend time detailing those because I don't have time to do
that right now, and even if I had, IMO there are no real reasons to
consider/discuss its adoption besides the uname-r move bit. (Yes, sucky
statement, but shrug, it's the best I can do in the time I have
available for this at the moment.)
Yes, it's quite lame. If you accuse the write-up of inaccuracies/ommisions
you have to go into details. Even defusing that it's not about the
important parts is not enough.
No, really, I don't have time to waste myself, still I deliver for
every statement I make. If you don't people may consider it FUD.
--
Axel.Thimm at ATrpms.net
9:02 p.m.
On Wed, 2006-08-16 at 16:46 +0300, Ville Skyttä wrote:
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
> I setup an executive summary of the comparison for you and for other
> people external to the discussion until now who would like to join in
> on Friday:
>
> http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
I'm almost certainly unable to join any meeting before next week
Similar
applies to me. I'll probably be unable to join any meeting
before mid Sept. unless it takes place late at night CET.
To reiterate: if consensus says change is needed, and there's
competent
manpower available to take care of things *soon*, so be it. The only
things I feel strongly about are that rejecting module packages from
FC/FE altogether would be profoundly odd at this point, and that the
scope of the discussion needs to be limited to whether uname-r gets
moved to the packages' names and its direct unavoidable consequences --
the only real technical design issue. Everything else in the "kmdl"
proposal is more or less cosmetics and implementation details, and
adopting it would mean throwing away quite a bit of work (reinventing
the wheel from the POV of the current scheme and its adopters) from
several parties for questionable gain.
http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName
This draft has potential.
I disagree on this. It is way too narrowly focused on
implementation details of kmod.
What we needed is strict and narrow conventions on kernel-module NEVRs
to assure proper interaction with installers.
All the rest is implementation details. Forcing a specific template to
me is actionism, because kernel-module rpms are NOT really different
from other RPMs, IMO. They are more complex and require strict
conventions on their "rpm API", that's all.
/me ducks
Ralf
11:23 p.m.
>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> I disagree on this. It is way too narrowly focused on
RC> implementation details of kmod.
To some degree I agree with this.
RC> What we needed is strict and narrow conventions on kernel-module
RC> NEVRs to assure proper interaction with installers.
Well, it's more than that; we have to ensure proper interaction with
the buildsys and there may be restrictions on file locations and such.
But beyond those things I agree that a bit of leeway is reasonable.
Of course, this stuff is _hard_, and the templates are a great idea
because it allows packagers to just plug the details in. But that's
different from saying that the spec MUST conform to that template.
So perhaps we could approach this issue from the other direction: what
NEVR convention(s) and file locations are required so that rpm, yum
and the like will properly handle the modules, including parallel
installs without conflict? What do the spec(s) need to have so that
the buildsys can build them for all supported kernel versions and
variants?
- J<
11:41 p.m.
On Wed, 2006-08-16 at 23:23 -0500, Jason L Tibbitts III wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> I disagree on this. It is way too narrowly focused on
RC> implementation details of kmod.
To some degree I agree with this.
RC> What we needed is strict and narrow conventions on kernel-module
RC> NEVRs to assure proper interaction with installers.
Well, it's more than that; we have to ensure proper interaction with
the buildsys and there may be restrictions on file locations and such.
Agreed, like
we agree upon "apps go to %{_bindir}", "libs go to
%{_libdir}", we need a clear and strict convention on where
kernel-modules need to be installed.
How to handle accompanying userspace libs/apps, whether to use split or
unified srpms/specs, how many kernel-modules to build simultaneously
from one spec are implementation details, each with different pros and
cons.
But beyond those things I agree that a bit of leeway is reasonable.
Of course, this stuff is _hard_, and the templates are a great idea
because it allows packagers to just plug the details in. But that's
different from saying that the spec MUST conform to that template.
Exactly.
It's a particular rpm's macroscopic behavior as viewed by the
installers that matters.
So perhaps we could approach this issue from the other direction:
what
NEVR convention(s) and file locations are required so that rpm, yum
and the like will properly handle the modules, including parallel
installs without conflict? What do the spec(s) need to have so that
the buildsys can build them for all supported kernel versions and
variants?
Fully agreed, sounds very reasonable to me.
Ralf
4:45 a.m.
On Thu, 2006-08-17 at 06:41 +0200, Ralf Corsepius wrote:
On Wed, 2006-08-16 at 23:23 -0500, Jason L Tibbitts III wrote:
> So perhaps we could approach this issue from the other
direction: what
> NEVR convention(s) and file locations are required so that rpm, yum
> and the like will properly handle the modules, including parallel
> installs without conflict? What do the spec(s) need to have so that
> the buildsys can build them for all supported kernel versions and
> variants?
Fully agreed, sounds very reasonable to me.
I think this pretty much just another way of saying the same thing I
posted in
https://www.redhat.com/archives/fedora-packaging/2006-August/msg00170.html : focus on the
only real technical design issue now, and just reuse the implementation work which is
already done as much as possible.
Also, the packaging draft linked to in the above message and the current
"standard" doc from which it is derived from should already contain all
the above info. Maybe it just needs some restructuring and
clarifications in order to prominently specify what part of it is the
interface and what is the supporting reference implementation that makes
it possible to ship such packages with the current infrastructure.
9:51 a.m.
On Thu, 2006-08-17 at 06:41 +0200, Ralf Corsepius wrote:
Agreed, like we agree upon "apps go to %{_bindir}",
"libs go to
%{_libdir}", we need a clear and strict convention on where
kernel-modules need to be installed.
There is *no need* for kernel modules to go in /lib/modules/kver at all
- that's just a convention for built-in kernel modules and I see no
reason why we can't have m-i-t pick up modules from other sane locations
too. If we can persuade people to use proper MODULE_VERSION()s then we
can also sanely decide about which of several versions to use.
Here's one random (not thought it all through) idea:
* Install modules in %{_moduledir}/modulename/kver
Then an RPM provides just the module for whatever kernel versions it
wants. But we still need to solve the issue of compatible modules. I
quite like the idea of insmod/depmod no longer basing its decisions on
data available from depmod using the location of the module, but the
compatibility of the module (kABI checks). So we say this:
* m-i-t tries to load %{_moduledir/modulename/this_kver
* m-i-t falls back on %{_moduledir/modulename/configured_ordering
* m-i-t falls back on /lib/modules/this_kernel
And weak-modules goes byebye because we don't need symlinks any more. We
make depmod and insmod/modprobe much more configurable and ship a def.
config with some sane options, but allow anyone to have old behavior or
more configurable and flexible behavior depending on their config.
What I'm saying is that I'm happy to try out some pretty radical
solutions to this problem now that I'm maintaining m-i-t. If we can have
a serious discussion about what we *want* from a "perfect system" then
we can make it happen properly upstream and get other folks involved -
we're not the only people who want to package up modules and agree on
standardized locations and mechanisms for choosing updated drivers.
I have spoken to the folks at SuSE/Novell and Ubuntu about driver
packaging - though not all the interested parties. I would /really/ like
it if some of these non-RPM-specific issues could get solved generally
or at least involve the other players who actually use the tools.
I am however /very/ sure that I don't want to try radical stuff ahead of
lots of community involvement. In Fedora terms, that means my own
personal view is it's way too late to be changing things for FC6 (unless
it's decided it's not). I would like us to get somewhere today/this
week/whenever towards sensible discussion of ways to fix the problems we
have in FC7/etc. and beyond - where IMO we have the time to spend on it.
Jon.
--
Jon Masters Phone: +44 7776 131337
Red Hat UK, Ltd. Email: jcm(a)redhat.com
6:22 a.m.
New subject: flexibility of kmdl interface (was: Kernel Module Packaging Standard Teleconference)
On Thu, Aug 17, 2006 at 04:02:04AM +0200, Ralf Corsepius wrote:
>
http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName
> This draft has potential.
I disagree on this. It is way too narrowly focused on implementation details of kmod.
What we needed is strict and narrow conventions on kernel-module NEVRs
to assure proper interaction with installers.
All the rest is implementation details. Forcing a specific template to
me is actionism, because kernel-module rpms are NOT really different
from other RPMs, IMO. They are more complex and require strict
conventions on their "rpm API", that's all.
Very nice! :)
Please check out the kmdl interface in the wiki. It is that abstract
and flexible that it could even be used with the buggy kmod scheme. It
is alse rather free-floating syntax, so you can bolster your rpms just
the way you are used to, you just need to make use of a couple macros
(like declaring that this package contains kmdls, or a macro that
points to the kernel source). No further helper applications/scripts
are needed.
The kmdl interface even allows a complete transparent switch to any
kabi scheme. E.g. if all of Fedora Extras uses kmdls and a
uname-r-in-name, and suddenly the RHEL folks want to reuse all of
these kmdls, but with a kabi-version-in-name, they can use the same
specfile/src.rpm unchanged! And someone in the future trying to test
the kmod scheme bugs, can even also just modify a couple of macros in
the kmdl implementation and suddenly the kmdls are named/versioned
like kmods!
And even though there is so much flexibility in the kmdl interface
scheme it still remains extremely KISS and distro-agnostic.
If you like the kmdl proposal is two-fold
o kmdl interface proposal
o kmdl implementation proposal
It's all hidden in the largish wiki text and in the piles of mails.
--
Axel.Thimm at ATrpms.net
11:46 a.m.
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote:
> On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote:
> As I didn't have the time to follow all these discussions and threads,
> and to have a basis for such an IRC-conference, I would appreciate if
> Axel and Thorsten could write up a "my proposal at one glance" outline.
I setup an executive summary of the comparison for you and for other
people external to the discussion until now who would like to join in
on Friday:
http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
and the details remain under
May I suggest comparing kmdls to thl's revised kmods? As it stands
there are bugs with the kmod standard that should be addressed so I'd
vote +1 for changing the standard. But I'm not understanding the
problems with thl's revisions that you are seeing so I'd vote -1 for
kmdls and +1 for the revised kmods. A comparison against the revised
kmod proposal would help to clarify that portion.
-Toshio
12:09 p.m.
On Wed, Aug 16, 2006 at 09:46:51AM -0700, Toshio Kuratomi wrote:
On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
> On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote:
> > On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote:
> > As I didn't have the time to follow all these discussions and threads,
> > and to have a basis for such an IRC-conference, I would appreciate if
> > Axel and Thorsten could write up a "my proposal at one glance"
outline.
>
> I setup an executive summary of the comparison for you and for other
> people external to the discussion until now who would like to join in
> on Friday:
>
> http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
>
> and the details remain under
May I suggest comparing kmdls to thl's revised kmods?
I already commented to the new suggestion by Thorsten in the
appropriate thread. I won't start writing a wiki page for each new
suggestion, maybe the people tosing them should invest some time and
write wiki docs comparing to kmdls.
--
Axel.Thimm at ATrpms.net
12:29 p.m.
On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 09:46:51AM -0700, Toshio Kuratomi wrote:
> On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote:
> > On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote:
> > > On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote:
> > > As I didn't have the time to follow all these discussions and
threads,
> > > and to have a basis for such an IRC-conference, I would appreciate if
> > > Axel and Thorsten could write up a "my proposal at one glance"
outline.
> >
> > I setup an executive summary of the comparison for you and for other
> > people external to the discussion until now who would like to join in
> > on Friday:
> >
> > http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
> >
> > and the details remain under
>
> May I suggest comparing kmdls to thl's revised kmods?
I already commented to the new suggestion by Thorsten in the
appropriate thread. I won't start writing a wiki page for each new
suggestion, maybe the people tosing them should invest some time and
write wiki docs comparing to kmdls.
I dislike rejecting people, so I looked again at the new proposal ...
Just to make it clear the actual changes wrt kmod are:
o use kabi-version instead of uname-r
o disambiguate the file paths of the modules, so modules of different
module versions are coinstallable *for the same kernel/kabi*!!!
In fact this scheme is far more broken than the old kmod scheme:
o The 'only-last-kernel-supported' simply becomes
'only-last-kabi-supported'. For Fedora it's the same anyway.
So you still have issues with
- no (security) updates for old kernels (or kabis)
- old kernels/kabis can get their module nuked or effectively
disabled.
o Currently there is a file conflicst guard of not having different
modules for the same kernel coinstalled. The disambiguation in the
file path lifts this safety pin and suddenly we can end up with
several different module versions for the same kernel!!!
The kabi stuff is for using modules built for different kernels/kabis,
not to have several modules of different versions coinstalled for the
same kernel/kabi. We certainly want to have foo-2 kernel modules for
kernel/kabi X to replace foo-1 for the same kernel/kabi and not
coinstall.
So that's not going to lead anywhere. We'd better stay with kmod
scheme than doing that.
And please stop throwing new kernel modules schemes to me :=)
--
Axel.Thimm at ATrpms.net
1:09 p.m.
Axel Thimm schrieb:
On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote:
o The 'only-last-kernel-supported' simply becomes
'only-last-kabi-supported'. For Fedora it's the same anyway.
So you still have issues with
- no (security) updates for old kernels (or kabis)
I was one of those that wanted to build stuff for older kernels in the
past. But a lot of people disliked that idea (I can look it up in the
archives if someone is interested who that was; most were from RH iirc)
and only wanted to support the latest shipped kernel.
If we really want to support older kernels then we need "uname -r" (or
kabi, or another identifier) in the %{NAME} *or* a plugin that handles
the stuff manually. I think I prefer the "uname -r/kabi" approach in
that case.
The question is: do we want to build new kernel modules for old kernels
that might have known security problems? Old kernels also get deleted
from the servers normally soon and thus aren't all available for the
buildsys anymore (only the current one and the one before that are on
the servers in the update repo). Building modules for all the kernels we
ever shipped would take a lot of build time and space on the servers. A
middle way -- build for all kernels still available wold be an
compromise if we want to build for more that kernel-current.
Axel, sorry, I'm not sure if I understand that "security" reference
above. I understood this currently like this: problem in module -> push
out a updated module and the latest kernel gets a fixed module, olders
remain unfixed. But hey, older kernels often (not always) had security
problems in any case -- that's why there was a new one. Or did I get
something wrong here?
- old kernels/kabis can get their module nuked or effectively
disabled.
Nope.
o Currently there is a file conflicst guard of not having different
modules for the same kernel coinstalled. The disambiguation in the
file path lifts this safety pin and suddenly we can end up with
several different module versions for the same kernel!!!
Nope, /sbin/weak-modules {cs}hould handle this.
CU
thl
1:19 p.m.
On Wednesday 16 August 2006 14:09, Thorsten Leemhuis wrote:
If we really want to support older kernels then we need "uname
-r" (or
kabi, or another identifier) in the %{NAME} *or* a plugin that handles
the stuff manually. I think I prefer the "uname -r/kabi" approach in
that case.
Or you can make the package available in the repo, but the end user who is
stuck on an old kernel can by hand yum install the specific version they
need. Not exactly pretty, but functional, and is just one more part of the
pain that is dealing with external modules and pinning to a given kernel.
--
Jesse Keating
Release Engineer: Fedora
2:57 p.m.
New subject: Kernel Module Packaging Standard Teleconference
Thorsten Leemhuis schrieb:
Axel Thimm schrieb:
> On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote:
> - old kernels/kabis can get their module nuked or effectively
> disabled.
Nope.
Correction: effectively disabled is correct.
CU
thl
3:36 p.m.
On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
> On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote:
> o The 'only-last-kernel-supported' simply becomes
> 'only-last-kabi-supported'. For Fedora it's the same anyway.
> So you still have issues with
> - no (security) updates for old kernels (or kabis)
If we really want to support older kernels then we need "uname -r" (or
kabi, or another identifier) in the %{NAME} *or* a plugin that handles
the stuff manually. I think I prefer the "uname -r/kabi" approach in
that case.
The question is: do we want to build new kernel modules for old kernels
that might have known security problems?
Do we want to keep those kernels in the repo? Whatever the policy for
kernels it mirrors to the kernel module support. If a kernel is not
worth installing, remove it from the repo and the associated kmdls.
Building modules for all the kernels we ever shipped
No, that's not the idea. Only what is considered a sane transition
time from kernel to kernel.
Axel, sorry, I'm not sure if I understand that
"security" reference
above. I understood this currently like this: problem in module -> push
out a updated module and the latest kernel gets a fixed module, olders
remain unfixed. But hey, older kernels often (not always) had security
problems in any case -- that's why there was a new one. Or did I get
something wrong here?
In Fedora??? 30% of kernel updates are not security related, and often
some kernels are brown bag releases, so many people back up to the
previous kernel. Supporting the last kernel is important.
> - old kernels/kabis can get their module nuked or effectively
> disabled.
Nope.
Yep.
> o Currently there is a file conflicst guard of not having
different
> modules for the same kernel coinstalled. The disambiguation in the
> file path lifts this safety pin and suddenly we can end up with
> several different module versions for the same kernel!!!
Nope, /sbin/weak-modules {cs}hould handle this.
So adding evr semantics to module-init-tools? BTW where is the epoch
in your file path suggestion? ...
Gotcha! :)
--
Axel.Thimm at ATrpms.net
5:04 p.m.
On Wed, 2006-08-16 at 22:36 +0200, Axel Thimm wrote:
On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote:
> Axel Thimm schrieb:
> Nope, /sbin/weak-modules {cs}hould handle this.
So adding evr semantics to module-init-tools? BTW where is the epoch
in your file path suggestion? ...
Gotcha! :)
I'm already adding a conf.d to m-i-t (but still toying with the exact
implementation to be figured out over this week) so you can specify the
priorities for individual /lib/modules directories. This is actually to
solve another problem, which is that sometimes you might want to use
kmods to override the built in kernel modules, sometimes not but you
might also want to *explicitly* set behavior in the module RPM.
You could (a)buse this to override the ordering of modules if we
switched to a new packaging system. Right now, the ordering of
directories in our m-i-t is:
* Try /lib/modules/*/updates - if there, the admin did it.
* Try /lib/modules/*/extra - if there, it's in a current kmod.
* Try /lib/modules/* - if in the kernel, cool.
* Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it
when looking to find compatible modules on kmod remove/install.
With kabi checking enabled (if you package with kABI deps) then you get
for free the compatibility links automatically added/removed on module
install/remove so older kernels can use a more recent kmod. You will be
able to ultimately instruct module-init-tools to always use the version
of a module in weak-updates over the built-in kernel and thereby get a
given module to always be available to all compatible installed kernels.
My personal opinion is that it's too late to change kmods drastically in
FC6. I think now we're all starting to think about the overall packaging
process again that we should have discussions this week about what to do
in FC7 and beyond - unless there's a major flaw in kmods (and I don't
think we can count any of the existing arguments as sufficient reason to
rip out the current status quo at T2 stage) we should leave it for FC6.
Jon.
--
Jon Masters Phone: +44 7776 131337
Red Hat UK, Ltd. Email: jcm(a)redhat.com
2:01 a.m.
On Wed, Aug 16, 2006 at 11:04:31PM +0100, Jon Masters wrote:
> So adding evr semantics to module-init-tools? BTW where is the
epoch
> in your file path suggestion? ...
> Gotcha! :)
I'm already adding a conf.d to m-i-t (but still toying with the exact
implementation to be figured out over this week) so you can specify the
priorities for individual /lib/modules directories. This is actually to
solve another problem, which is that sometimes you might want to use
kmods to override the built in kernel modules, sometimes not but you
might also want to *explicitly* set behavior in the module RPM.
You could (a)buse this to override the ordering of modules if we
switched to a new packaging system. Right now, the ordering of
directories in our m-i-t is:
* Try /lib/modules/*/updates - if there, the admin did it.
Or any of 67 kmdls from ATrpms.
* Try /lib/modules/*/extra - if there, it's in a current kmod.
* Try /lib/modules/* - if in the kernel, cool.
* Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it
when looking to find compatible modules on kmod remove/install.
The suggestion Thorsten is implying is that you should try under
/lib/modules/*/foo/1/1.2.3/2
/lib/modules/*/foo/1/1.2.3/1
/lib/modules/*/foo/1/1.2.2/1
/lib/modules/*/foo/0/10/1
in that order for several coinstalled versions of foo *for the same
kernel* (the folder names are epoch/version/release), and you would
have to use rpmvercmp to compare the folder names.
That's a package problem that is being pushed to the wrong domain. For
the same kernel (or kabi) the module should have one version
installed. Otherwise the argument of having multiple versions of
anything, not only kernel modules applies.
With kabi checking enabled (if you package with kABI deps) then you
get
for free the compatibility links automatically added/removed on module
install/remove so older kernels can use a more recent kmod. You will be
able to ultimately instruct module-init-tools to always use the version
of a module in weak-updates over the built-in kernel and thereby get a
given module to always be available to all compatible installed kernels.
The relation is different between what you and Thorsten think. It's
many kernel modules *for* the same kernel vs many kernel modules *from
different* kernels/kabis.
The kabi solution tries to recycle kernel modules from foreign kernels
where possible as given by kabi metrics, it hs nothing to do with
kernel module upgrades within the same kernel (as going from
foo-1.2.2-1 to foo-1.2.3-1 in the example above). Using the kabi
mechanisms for that would be wrong. Just to make it clearer: These
pile of kernel modules would share the same kernel abi, e.g. their
value for recycling is the same, if foo-1.2.2-1 for kernel X can be
recycled, so can foo-1.2.3-1 for the same kernel, so why pick the old
package at all?
If the argument is because the newer package might be broken, then the
same applies to any other non-kernel related package and we're not
going to allow several coinstallations of gcc/glibc/openoffice etc and
have the PATH/linker decide on evr semantics.
If the newer pakcage is broken, downgrade to the previous is the
typical solution, not coinstall all under the sun :)
My personal opinion is that it's too late to change kmods
drastically in
FC6.
I agree, my suggestion is not to change, but to dump :)
--
Axel.Thimm at ATrpms.net
10:08 a.m.
On Thu, 2006-08-17 at 09:01 +0200, Axel Thimm wrote:
The suggestion Thorsten is implying is that you should try under
/lib/modules/*/foo/1/1.2.3/2
/lib/modules/*/foo/1/1.2.3/1
/lib/modules/*/foo/1/1.2.2/1
/lib/modules/*/foo/0/10/1
in that order for several coinstalled versions of foo *for the same
kernel* (the folder names are epoch/version/release), and you would
have to use rpmvercmp to compare the folder names.
That's a package problem that is being pushed to the wrong domain. For
the same kernel (or kabi) the module should have one version
installed. Otherwise the argument of having multiple versions of
anything, not only kernel modules applies.
That's a problem. Some people genuinely want to have more than one
version of a module installed - I think in the longer run that this
would be a good thing to be able to support, though I much prefer using
modinfo meta-data to solve it rather than the file location.
We should compel people to use module versions properly in their source
code IMO since it's deliberately designed to support what we need from
it - and it's trivial enough to warn on build/load of non-kernel
provided modules that they don't have good version info inside.
> With kabi checking enabled (if you package with kABI deps) then
you get
> for free the compatibility links automatically added/removed on module
> install/remove so older kernels can use a more recent kmod. You will be
> able to ultimately instruct module-init-tools to always use the version
> of a module in weak-updates over the built-in kernel and thereby get a
> given module to always be available to all compatible installed kernels.
The relation is different between what you and Thorsten think. It's
many kernel modules *for* the same kernel vs many kernel modules *from
different* kernels/kabis.
*** The following is for explanatory purposes, not part of thread ***
Yeah. We're talking about different things here - I'm just trying to
clarify what I've done with the kABI stuff because I didn't really get
at this part of the problem before. Let's say this happens (this is more
of a RHEL-type problem but *not exclusively* so I mention it here):
* Fedora kernel provides module foo.
* Module is upgraded with kmod to bar with different compile options.
Now, if we upgrade the kernel then we might upgrade to a newer and more
improved module that happens also to make my root device unavailable
because it broke on hardware X. So in that case we want to supply a
depmod configuration file along with the kmod files that tells depmod to
*always* use the kmod rather than the built-in driver from a newer
kernel - i.e. override the weak-updates logic we're using which says
that newer kernels always contain better versions of the module.
This isn't the OO problem. OpenOffice doesn't run the risk of breaking
your hardware on upgrade and people don't usually want to be able to use
different builds of OO from many different locations. With external
drivers not provided in Core we are *specifically allowing* people to
have several different builds of the same driver in different RPMs.
*** end of off-topic bit ***
If the newer pakcage is broken, downgrade to the previous is the
typical solution, not coinstall all under the sun :)
Indeed. Though there's the complication that we'd ideally like to not
prevent the system from booting when it's been upgraded remotely. This
is not something that is addressed at the moment :-)
> My personal opinion is that it's too late to change kmods
drastically in
> FC6.
I agree, my suggestion is not to change, but to dump :)
Dude. We're on T2 right now. In 6 months, there'll be another Fedora and
during that time we have plenty of scope to look at this some more. IMHO
you haven't shown *compelling* evidence for kmods to be dropped in FC6
but instead have highlighted some issues to be looked at for FC7.
Jon.
--
Jon Masters Phone: +44 7776 131337
Red Hat UK, Ltd. Email: jcm(a)redhat.com
3:29 p.m.
On Fri, Aug 18, 2006 at 04:08:49PM +0100, Jon Masters wrote:
On Thu, 2006-08-17 at 09:01 +0200, Axel Thimm wrote:
> The suggestion Thorsten is implying is that you should try under
>
> /lib/modules/*/foo/1/1.2.3/2
> /lib/modules/*/foo/1/1.2.3/1
> /lib/modules/*/foo/1/1.2.2/1
> /lib/modules/*/foo/0/10/1
>
> in that order for several coinstalled versions of foo *for the same
> kernel* (the folder names are epoch/version/release), and you would
> have to use rpmvercmp to compare the folder names.
>
> That's a package problem that is being pushed to the wrong domain. For
> the same kernel (or kabi) the module should have one version
> installed. Otherwise the argument of having multiple versions of
> anything, not only kernel modules applies.
That's a problem. Some people genuinely want to have more than one
version of a module installed - I think in the longer run that this
would be a good thing to be able to support, though I much prefer using
modinfo meta-data to solve it rather than the file location.
We should compel people to use module versions properly in their source
^^^^^^
That's kernel module authors. Convincing them to use proper versioning
is even more difficult than convincing any other upstream author to do
the same. Just consider that every module get's its own versioning and
some even go back and forth, real-life examples: madwifi and 3w-9xxx.
Before you get them to do a proper versioning, we'll have rpm rewritten.
Furthermore: Even if the versioning of kernel modules was as "good" as
other conventional upstream versioning, you still have the same needs
for epochs and releases like for conventional packages:
o epoch for when the version seems to go backwards in time in whatever
versioning metrics
o release for fixing bugs/patching up kernel modules that won't
change their version.
E.g. if I repackage foo-1.2.3-1 with a fix in foo-1.2.3-2, I don't
want to see them both installed at the users' systems and hope m-i-t
select the proper one.
So when you think about coinstalling modules *for the same
kernel/kabi*, you will inevitably both need to introduce full evr
semantics on m-i-t level and will have to have rpmvercmp semantics in
place. That means coding the evr into the path, since there is no
place in the module's metadata *and* the different modules for the
same kernel should not overlap.
It is wrong to shift rpm's (or the depsolver's) work to m-i-t. We just
lose the overview in keeping the packages managed at one place and the
problem still needs to be solved.
code IMO since it's deliberately designed to support what we need
from
it - and it's trivial enough to warn on build/load of non-kernel
provided modules that they don't have good version info inside.
--
Axel.Thimm at ATrpms.net
12:51 p.m.
On Wed, Aug 16, 2006 at 11:04:31PM +0100, Jon Masters wrote:
On Wed, 2006-08-16 at 22:36 +0200, Axel Thimm wrote:
> On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote:
> > Axel Thimm schrieb:
> > Nope, /sbin/weak-modules {cs}hould handle this.
> So adding evr semantics to module-init-tools? BTW where is the epoch
> in your file path suggestion? ...
> Gotcha! :)
I'm already adding a conf.d to m-i-t (but still toying with the exact
implementation to be figured out over this week) so you can specify the
priorities for individual /lib/modules directories. This is actually to
solve another problem, which is that sometimes you might want to use
kmods to override the built in kernel modules, sometimes not but you
might also want to *explicitly* set behavior in the module RPM.
You could (a)buse this to override the ordering of modules if we
switched to a new packaging system. Right now, the ordering of
directories in our m-i-t is:
* Try /lib/modules/*/updates - if there, the admin did it.
* Try /lib/modules/*/extra - if there, it's in a current kmod.
* Try /lib/modules/* - if in the kernel, cool.
* Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it
when looking to find compatible modules on kmod remove/install.
With kabi checking enabled (if you package with kABI deps) then you get
for free the compatibility links automatically added/removed on module
install/remove so older kernels can use a more recent kmod. You will be
able to ultimately instruct module-init-tools to always use the version
of a module in weak-updates over the built-in kernel and thereby get a
given module to always be available to all compatible installed kernels.
My personal opinion is that it's too late to change kmods drastically in
FC6. I think now we're all starting to think about the overall packaging
process again that we should have discussions this week about what to do
in FC7 and beyond - unless there's a major flaw in kmods (and I don't
think we can count any of the existing arguments as sufficient reason to
rip out the current status quo at T2 stage) we should leave it for FC6.
Jon.
--
Jon Masters Phone: +44 7776 131337
Red Hat UK, Ltd. Email: jcm(a)redhat.com
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
Jon,
Do I understand this correctly?
Grub doesn't know anything about RPM versioning but it knows what kernel
to boot because the kernel package / up2date / whatever runs a tool that
says make this the default kernel.
I've gleaned so far that the mit tool will be used similarly with kernel
module packages to say "use this module as the default in kernel version
foo." The user/admin can use the mit tool or whatever to adjust which
modules get used with his own packages or configuration management
tools as is needed by his requirements.
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
1:44 p.m.
On Wed, 2006-08-16 at 19:29 +0200, Axel Thimm wrote:
Just to make it clear the actual changes wrt kmod are:
o use kabi-version instead of uname-r
o disambiguate the file paths of the modules, so modules of different
module versions are coinstallable *for the same kernel/kabi*!!!
In fact this scheme is far more broken than the old kmod scheme:
o The 'only-last-kernel-supported' simply becomes
'only-last-kabi-supported'. For Fedora it's the same anyway.
So you still have issues with
- no (security) updates for old kernels (or kabis)
Okay. I haven't seen anything to contradict this yet, only a conflict
over whether this is a problem or not. (If I'm wrong, somebody point me
to the archives or restate the rebuttal)
Even if kmdls were accepted, are we planning on having the buildsystem
build for multiple kernels?
- old kernels/kabis can get their module nuked or effectively
disabled.
How?
Will not get overwritten (which is how I think the term "nuked" has been
used in this thread.)
Effectively disabled: What leads you to that conclusion?
o Currently there is a file conflicst guard of not having different
modules for the same kernel coinstalled. The disambiguation in the
file path lifts this safety pin and suddenly we can end up with
several different module versions for the same kernel!!!
But they are not being used. If we treat the kernel modules the same as
the kernel itself, then this is expected. It could even be considered
desirable: Upgraded modules doesn't work? Re-symlink the old module and
you're set.
The kabi stuff is for using modules built for different
kernels/kabis,
not to have several modules of different versions coinstalled for the
same kernel/kabi. We certainly want to have foo-2 kernel modules for
kernel/kabi X to replace foo-1 for the same kernel/kabi and not
coinstall.
I don't think that's a given. If I installed a new module from source,
I'd like the option to coinstall with whatever I had on the system
before so I could recover the system if I had to. With packaging it's
not as important because I could download the old package and reinstall.
Although I think we are removing old packages from the repository. What
if the module from January is the last one that worked for me and the
next ten do not? (Of course, I may be stuck with an old kernel then, as
well... Like I said, I'm not sold either way.)
Also, if I'm rebuilding my kernels from fedora source with some local
changes to the kernel.config, a plan that places all external modules
into a common directory and then makes symlinks to the relative kernel
directories would help me use prebuilt kernel modules.
And please stop throwing new kernel modules schemes to me :=)
The problem is we're here debating 1) Can kmods be saved and 2) if they
can't be saved, do we want kmdls to replace them verbatim?
So as you throw problems at the new proposals, people are going to
update the proposals to try to fix those problems. In the end we'll all
agree that there is an actual problem that no amount of fixing can
actually solve, or we'll look at the two proposals and say this pile of
hacks is less appealing to me than this one for [insert arbitrary reason
here].
-Toshio
3:30 p.m.
On Wed, Aug 16, 2006 at 11:44:56AM -0700, Toshio Kuratomi wrote:
On Wed, 2006-08-16 at 19:29 +0200, Axel Thimm wrote:
> o The 'only-last-kernel-supported' simply becomes
> 'only-last-kabi-supported'. For Fedora it's the same anyway.
> So you still have issues with
> - no (security) updates for old kernels (or kabis)
Okay. I haven't seen anything to contradict this yet, only a conflict
over whether this is a problem or not. (If I'm wrong, somebody point me
to the archives or restate the rebuttal)
Even if kmdls were accepted, are we planning on having the buildsystem
build for multiple kernels?
> - old kernels/kabis can get their module nuked or effectively
> disabled.
>
How?
Will not get overwritten (which is how I think the term "nuked" has been
used in this thread.)
I answered to this on fedora-devel. I also added this to the wiki. But
still let's give an example (versions are faked and simplified, I
don't want to go hunting them, but the example is bitter real):
ipw2200-1 requires userland package ipw2200-firmware-1
We have two kernels, "a" the old one, "b" the new one. So kmod would
deliver something like
ipw2200-kmod-1-a and
ipw2200-kmod-1-b
For the two kernels before the module upgrade. Now the following three
packages hit the repo
ipw2200-kmod-2-a and
ipw2200-kmod-2-b
ipw2200-firmware-2
And the kmods require the new firmware.
In the kmdl scheme they would both get installed and the old ones
uninstalled (same for the firmware). %post %postun would also perform
the proper install/upgrade distinction (another thing kmods fail, you
cannot know whether this is an upgrade of install in the specfile, but
that's another story).
yum + the current yum plugn support will only try to install/upgrade
ipw2200-kmod-2-b and ipw2200-firmware-2, kernel "a" became invisible
to the upgrade.
But ipw2200-kmod-1-a has a hard dependency on ipw2200-firmware-1 which
is just being upgraded to a new version. Therefore the only way out is
to uninstall ipw2200-kmod-1-a.
So you have your old kernel's kmdo nuked.
Effectively disabled: What leads you to that conclusion?
If the dependency was (wrongly) not strict, then the kmod is not
nuked, but does not work anymore due to the new firmware
=> effectively disabled.
> o Currently there is a file conflicst guard of not having
different
> modules for the same kernel coinstalled. The disambiguation in the
> file path lifts this safety pin and suddenly we can end up with
> several different module versions for the same kernel!!!
But they are not being used. If we treat the kernel modules the same
as
the kernel itself, then this is expected.
No, you're fallen for the dual nature of kernel modules. They carry a
kernel evr and need to be coinstallable wrt that, but they carry their
own evr, too, which needs to be in upgrade-mode like all other
packages.
Any argument to not do so would propagate to all other packages, too
(hey, what if ipw2200-2 is broken, I want a fallback to ipw2200-1 vs
hey, what if openoffice-3.0.1 is borken, I want a fallback to
openoffice-3.0.0).
> And please stop throwing new kernel modules schemes to me :=)
The problem is we're here debating 1) Can kmods be saved and 2) if they
can't be saved, do we want kmdls to replace them verbatim?
So as you throw problems at the new proposals, people are going to
update the proposals to try to fix those problems. In the end we'll all
agree that there is an actual problem that no amount of fixing can
actually solve, or we'll look at the two proposals and say this pile of
hacks is less appealing to me than this one for [insert arbitrary reason
here].
Agreed, but I expect some more homework being done before throwing it
out. I usually spend more time in writing an analysis of those hourly
proposals than it took the author to think about them.
--
Axel.Thimm at ATrpms.net
12:31 a.m.
New subject: Kernel Module Packaging Standard Teleconference
Axel Thimm schrieb:
[...]
I answered to this on fedora-devel. I also added this to the wiki. But
still let's give an example (versions are faked and simplified, I
don't want to go hunting them, but the example is bitter real):
ipw2200-1 requires userland package ipw2200-firmware-1
We have two kernels, "a" the old one, "b" the new one. So kmod would
deliver something like
ipw2200-kmod-1-a and
ipw2200-kmod-1-b
For the two kernels before the module upgrade. Now the following three
packages hit the repo
ipw2200-kmod-2-a and
ipw2200-kmod-2-b
ipw2200-firmware-2
And the kmods require the new firmware.
You can package both the old and the new firmware in one package. We did
it in livna for ipw2200 because people might still run older Fedora
Kernels that requires the new firmware, while the up2date kernel
requires the new firmware.
CU
thl
2:09 a.m.
New subject: Kernel Module Packaging Standard Teleconference
On Thu, Aug 17, 2006 at 07:31:59AM +0200, Thorsten Leemhuis wrote:
Axel Thimm schrieb:
>[...]
>I answered to this on fedora-devel. I also added this to the wiki. But
>still let's give an example (versions are faked and simplified, I
>don't want to go hunting them, but the example is bitter real):
>
>ipw2200-1 requires userland package ipw2200-firmware-1
>
>We have two kernels, "a" the old one, "b" the new one. So kmod
would
>deliver something like
>
>ipw2200-kmod-1-a and
>ipw2200-kmod-1-b
>
>For the two kernels before the module upgrade. Now the following three
>packages hit the repo
>
>ipw2200-kmod-2-a and
>ipw2200-kmod-2-b
>ipw2200-firmware-2
>
>And the kmods require the new firmware.
You can package both the old and the new firmware in one package. We did
it in livna for ipw2200 because people might still run older Fedora
Kernels that requires the new firmware, while the up2date kernel
requires the new firmware.
What if the package's files shares the same names? Like for instance
ipw3945 and ipw3945d (I love real-life examples)?
What if the kmdl is dependend on the exact version of the userland
(like nvidia)? Don't we suggest to any decent packager to do have
sane versioning in his subpackaging for a good reason?
Bundling packages into one is a bad thing, especially when they are
the same package of a different version!!!
That's the problem with pandora's box (see the wiki): You have piles
and piles of workarounds/hacks to fix previous bugs of the basic
design problems and evey new "fix" is generating more bugs. Maybe it's
not pandora's box, but more like a Hydra. ;)
--
Axel.Thimm at ATrpms.net
6:40 a.m.
New subject: kmod: $1 in %post and firends broken (was: Kernel Module Packaging Standard Teleconference)
On Wed, Aug 16, 2006 at 10:30:54PM +0200, Axel Thimm wrote:
In the kmdl scheme they would both get installed and the old ones
uninstalled (same for the firmware). %post %postun would also perform
the proper install/upgrade distinction (another thing kmods fail, you
cannot know whether this is an upgrade of install in the specfile, but
that's another story).
The argument is rather obvious, but before people ask:
$1 is the number of packages with the same name existing after this
rpm operation and is used in scriplets to decide whether this package
is a first-time install, an upgrade or a final deletion.
For kmdls this is the number of kmdls for this kernel/kabi, for kmods
it for all kernels, therefore the kmod can never know whether it's a
first time install/upgrade/deletion for the kernel it's being
installed in. E.g. usage of $1 in kmods'scriplets is broken.
--
Axel.Thimm at ATrpms.net
5:58 a.m.
New subject: kmod: $1 in %post and firends broken (was: Kernel Module Packaging Standard Teleconference)
On Fri, Aug 18, 2006 at 01:17:22PM +0300, Ville Skyttä wrote:
On Thu, 2006-08-17 at 13:40 +0200, Axel Thimm wrote:
> usage of $1 in kmods'scriplets is broken.
Why would it be necessary to use it in the first place?
Don't you see any neccessity in having kmdls able to distinguish
between being first time installed/upgraded/removed?
I'm not making use of $1 in kmdls, but I can very well think of some
use cases:
o storage drivers that need to place themselves in initrd (actually
that is a missing feature often reported on qla modules at ATrpms)
o creating device drivers for systems w/o dynamic /dev (like RHEL3)
o signaling a daemon to either start/reload firmware/stop like the
case with ipw3945 & daemon - additionally needs a check whether the
operation is for the running kernel. This is also an unfinshed item
of ATrpms' kmdls for ipw3945 (there is additionally a racing during
installation of kmdls and the daemon and needs to be addressed
upstream, but that's off-topic)
You can think of other situations where you do want to know whether
this package is upgrade/first-time installed/removed. But to be fair
exactly because $1 is not in present use I rated this bug low in the
ratings column.
Dropping mechanisms to support a broken scheme just because you
don't yet have a current need for that mechanism is wrong.
--
Axel.Thimm at ATrpms.net
4:20 a.m.
Hi Warren,
On Tue, Aug 15, 2006 at 08:16:26PM -0400, Warren Togami wrote:
After weeks of discourse on IRC and mailing list discussions, we
seem to be unable to make progress toward an amicable agreement.
[...] If the packaging committee cannot come to key agreements,
then the matter will be escalated to the Fedora Project Board who
will make the key decisions.
there was a staged unbundled voting proposal last week:
https://www.redhat.com/archives/fedora-packaging/2006-August/msg00061.html
and there are three people that voted (2 in favor, one against), then
Thorsten has strongly voiced concerns about the investment into the
old scheme and people stopped voting while the discussions were up
again.
I'm in favor of anything that will speed up the voting process or
bring in any decision, I think the idea of bringing together all
relevant parties is a very good one.
In order to make this meeting manageable, we must limit the number
of
attendees. Invited are the existing members of the Fedora Packaging
Committee, Thorsten Leemhuis and certain Red Hat employees relevant to
this discussion. Please talk to me directly if you have been an active
contributor to this in the past but are not included in this invitee list.
I would like to suggest Jack Neely and Seth Vital. The latter as a
neutral authority on yum and friends to judge on the technical issues
raised and the former as the author of the yum support for kmod which
IMHO is not working and connot be made to work as well as a big
opponent of the new scheme. A working yum is a key point and it would
be good to have a fast return of feedback. If they can be convinced
that the kmod scheme is unsupportable from yum's POV we're already
almost done.
--
Axel.Thimm at ATrpms.net
7:51 a.m.
On Wed, 2006-08-16 at 11:20 +0200, Axel Thimm wrote:
I would like to suggest Jack Neely and Seth Vital. The latter as a
neutral authority on yum and friends to judge on the technical issues
raised and the former as the author of the yum support for kmod which
IMHO is not working and connot be made to work as well as a big
opponent of the new scheme. A working yum is a key point and it would
be good to have a fast return of feedback. If they can be convinced
that the kmod scheme is unsupportable from yum's POV we're already
almost done.
umm, no. I'm not getting dragged into this.
What the kmod plugin does is what it does and it has worked for me for
the cases I have (which is only openafs).
But I'm not going to be a judge of anything. I'm not on the packaging
committee, anyway.
-sv
-sv
11:54 a.m.
On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote:
It is the decision of me, Max, and Spot, to put a hold on publishing
any
further kmod modules pending the result the Kernel Module Packaging
Standard conference call. Time/date of this call is to be determined,
but we are aiming for this Friday, August 18th at a time that is
workable for both American EDT and Europe. Perhaps 1PM EDT would work,
the usual timeslot of FESCO meetings? Perhaps this timeslot wont work.
If you feel it is important to attend but you are unable to make this
time, please make it known in this thread.
I'm not able to make a teleconference during business hours
(17:00-01:00UTC). I can make an IRC meeting during that time on Friday,
though.
I'd say you could tie my vote to Ville's in this case but I see he's not
going to be available for the meeting on Friday so I'd rather attend if
possible.
-Toshio
6454
days inactive
6456
days old
packaging@lists.fedoraproject.org
37 comments
11 participants
participants (11)
-
Axel Thimm -
Jack Neely -
Jason L Tibbitts III -
Jesse Keating -
Jon Masters -
Ralf Corsepius -
seth vidal -
Thorsten Leemhuis -
Toshio Kuratomi -
Ville Skyttä -
Warren Togami