[ATrpms-devel] Complaints about censoring and kmdl IRC session

[Axel Thimm]

Hi,

IMHO the IRC session today was a pure catastrophe.

Some - especially people not following the discussion closely - were
given the wrong picture and even accused me of being arrogant and what
not. I'd like to file in my view, since the IRC session turned that
badly.

Upon request I compiled a tabular list of pros and cons of kmods vs
kmdls derived from the longer writeup in the wiki. I've added all
points mentioned even the ones I personally do not pay that much
importance on and more importantly also these points that my proposal
isn't good at including negative personal ratings for kmdls! I
considered this a necessity out of fairness to everyone's
contributions.

W/o notice someone changed that list in a way I consider heavily
censoring and very biased. I complained to him in PM, but his spam
filter ate my mail and I didn't get a reply before the session (or by
now either FWIW). In any case at the end of this mail I summarize the
main changes [3].

Of course that new list wasn't really what I would consider a neutral,
unbiased approach. There were many errors either accidentially or due
to different understanding [1] which by happenstance *all* were
turning against kmdls, even typos and cut&paste errors. Also important
items were scratched (not the rating, but features and comparisons).

Later in the session it was told that the omitted items were dumped
because they were considered irrelevant, something which IMHO the
people in the session should be allowed to judge for themselves.

When the first difference was brought on discussion - namely that rpm
-i supposedly works with kmod - I objected and gave examples why this
is not the case. Independent of whether I were right or wrong [2], the
following "definition of rpm -i works for kmods" was topping the
censoring by itself.

I can understand that people are not as deep into kernel modules as
others, and that therefore some issues may look different. But
shouldn't these people be open to discussion in case they are missing
something (which in this case they are)?

Or is this just a fake discussion where the end result is already in
stone and we're just trying to justify it?

ATM I really disappointed as to how things evolve. I've put lots of
efforts and sweat over the last weeks into this with the target to fix
something broken for the benefits of all and I don't consider this the
proper reaction.

Please note that I'm very far from escalating this. I wrote this mail
with very careful wording, omitting on purpose all names and
refraining from any direct accusations, even though I'm extremely
alergic to censoring and misquoting in general. And I didn't reply on
personal insults either to avoid any flaming.

To get to the positive side: At least it was discussed at all (or an
attempt was made) and I'd like to thank all for their participation
and patience.

=====================================================================

[1] I use "different" as a very neutral wording of what I personally
    consider "wrong".

[2] IMHO I was and am correct in the statement that the kmod scheme
    can neither be used with rpm -U, nor rpm -i.

[3] Changes between original and censored list of items

http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance?action=diff&rev2=8&rev1=4

By order of importance:

o rpm & kmods:
  "breaks on rpm level" removed
  "rpm -i does not work" suddenly "works" ???

o kmod's need for further yum developend removed!!!

o yum w/ full plugin support
  kmod's "only one kernel supportable [...]" becomes "possible" ???
  kmdl's "full suport" becomes "possible" ???

  The difference is a working kmdl plugin today vs the shown issues of
  the fedorakmod.py, which were even admited by pro-kmod participants.

o kmods: kernel's evr "merged with the modules" becomes "available as
  provides"
  It is very important that the 2-dimensional evr space is mapped
  that way, it is in fact the root of most evil. Replacing it as done
  hides the issue.

o kmdls and low maintenance: "specfile/src.rpm/userland invariant"
  becomes "every new kernel/flavour needs full rebuild"

o kmdl's design flexibility/abstraction of interface/implementation removed

o infrastructure (bugzilla/cvs/owners) benefits removed

o custom kernel support removed

o other distribution benefits of kmdls removed

o cross-distribution standard benefits of kmdls removed

o Removed column rating (that by itself I would consider OK)

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
Conversation with #fedora-packaging at 2006-08-18 18:44:52 on thimm at irc.freenode.net (irc)
(18:44:53) : The topic for #fedora-packaging is: Channel for Fedora packaging related discussion | Next Meeting: Thursday, August 17th, 2006 16:00 UTC
(18:45:37) jcmasters: It's quiet in here.
(18:46:04) Jason L Tibbitts III (tibbs): I imagine it won't be in  fifteen minutes.
(18:46:21) Tom Callaway (spot): it will be if i have to set the channel +m
(18:46:36) ***Tom Callaway (spot) really hopes people can behave... :)
(18:47:04) Jason L Tibbitts III (tibbs): I don't really speak IRC so I've no idea what +m means.
(18:47:24) Jason L Tibbitts III (tibbs): But I sure hope someone has an outline they want to follow.  Otherwise it will be pretty pointless.
(18:47:27) Tom Callaway (spot): it means i moderate the channel.
(18:47:35) warren: spot, if we have votes on technical points, who is eligible?
(18:47:55) Tom Callaway (spot): packaging committee is eligible
(18:48:12) Axel Thimm: an agenda would be good
(18:48:36) ***Tom Callaway (spot) has a rough one
(18:49:00) Tom Callaway (spot): http://www.fedoraproject.org/wiki/spot/kernel-module-comparison
(18:49:01) Axel Thimm: Discussion should not be about whether kernel modules are wanted in Fedora or not
(18:49:23) Tom Callaway (spot): thimm: we can certainly start there
(18:49:47) Axel Thimm: Tom, did you read my complaints about that table?
(18:50:04) Jason L Tibbitts III (tibbs): spot: Thanks for what looks like an unbiased summary.
(18:50:10) ***jcmasters agress with thimm. The main point I want to make/ask is whether we're thinking about FC6 or beyond. IMO it's too late for FC6 to change this all now.
(18:50:27) warren: It is FPB's decision to decide whether we want kernel modules or not.
(18:50:29) Axel Thimm: FC6 should block kmods, nothing more
(18:50:41) warren: It is this group's decision to decide technically *how*.
(18:50:54) jcmasters: thimm: "block" kmods?
(18:51:02) Axel Thimm: yes
(18:51:10) Axel Thimm: Like already done from two days ago
(18:51:21) Tom Callaway (spot): thimm: no, i did not see your complaints
(18:51:28) Axel Thimm: Sent in mail
(18:51:37) Axel Thimm: About removing/changing importnt parts in the table
(18:52:16) ***Tom Callaway (spot) looks to see if his spam trap ate it
(18:52:35) Axel Thimm: Is "kmdls" now in your Bayes blacklist ;)
(18:52:38) Tom Callaway (spot): but honestly, your rating column confused the heck out of me and served no purpose other than to add bias.
(18:52:44) Rex Dieter (rdieter): everything with "kernel" in subject is spam, right? ;)
(18:52:48) Axel Thimm: No, you remove rows, not only columns
(18:52:57) Axel Thimm: And changed contents of columns
(18:53:03) Axel Thimm: Suddenly kmod works with rpm -i ????
(18:53:10) Axel Thimm: While we discussed for ages that it doesn't?
(18:53:13) Tom Callaway (spot): thimm: kmod has always worked with rpm -i
(18:53:18) Axel Thimm: No, it has not :)
(18:53:19) Tom Callaway (spot): same as kernel packages do.
(18:53:21) Axel Thimm: Nope
(18:53:23) Axel Thimm: Try it
(18:53:29) Tom Callaway (spot): i did. it worked for me.
(18:53:30) slack_: it depends on your definition of works...it works for me
(18:53:41) Axel Thimm: Then what is fedorakmod.py doing?
(18:53:49) Tom Callaway (spot): thimm: handling the -U case
(18:53:51) Axel Thimm: It's only pupose is to try to fix that rpm -i does not work
(18:53:53) slack_: yes
(18:54:00) Axel Thimm: No, the -U case is handled differntly
(18:54:08) Axel Thimm: It's hanleded by Provides: kernel-modules
(18:54:14) Axel Thimm: So the new table is wrong
(18:54:22) Axel Thimm: This is just one point I've seen
(18:54:31) Axel Thimm: I'd prefer starting with
(18:54:47) Axel Thimm: http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance
(18:54:55) Tom Callaway (spot): no, we're not going to use that.
(18:54:56) slack_: I'm reading the table now...so far it seems refreshing unbiased.
(18:55:07) Tom Callaway (spot): there's too much bias in that.
(18:55:11) slack_: thimm: indeed, we cannot start with your or my writeups/emails
(18:55:21) Tom Callaway (spot): i'm not against correcting my table for technical errors
(18:55:22) Axel Thimm: Who is slack?
(18:55:32) slack_: I'm jack
(18:55:38) jcmasters: ah!
(18:55:40) Axel Thimm: Sorry Tom, I could correct them, but not 4 Min. before the session???
(18:55:50) slack_: please do not
(18:55:57) Tom Callaway (spot): thimm: we'll talk through them line by line
(18:56:11) Axel Thimm: And what about the missing lines?
(18:56:28) Axel Thimm: Why am I going through all this trouble?
(18:56:29) Tom Callaway (spot): after we finish my lines, we can discuss the ones i removed
(18:56:32) Axel Thimm: Just to get censored?
(18:56:37) jcmasters: Are we saying that it's still open for debate whether the standard will change before FC6 final?
(18:56:39) Tom Callaway (spot): i removed them because they have 0 relevance to Fedora
(18:56:51) warren: jcmasters, yes
(18:56:56) Axel Thimm: Based on your opinion?
(18:57:12) Tom Callaway (spot): we don't ship custom kernels, nor do we have any control over other distributions
(18:57:18) jcmasters: warren: hmmm. okay, but I think that's a bad idea :-)
(18:57:19) Tom Callaway (spot): thus, that data is irrelevant
(18:57:36) Rex Dieter (rdieter): Well, *less* relavent anyway.
(18:57:54) Axel Thimm: You also removed parts about infrastructure/bugzilla/scm
(18:58:04) ***Tom Callaway (spot) looks
(18:58:09) Axel Thimm: Also removed parts about design
(18:58:12) Axel Thimm: and flexibility
(18:58:23) Axel Thimm: and kmdl iterface/implementation stuff
(18:58:31) Axel Thimm: future-proof design etc
(18:58:37) Tom Callaway (spot): ok, hold on.
(18:58:43) Tom Callaway (spot): i took out the custom kernel support line
(18:58:50) Tom Callaway (spot): all of the other flexibility items remained
(18:58:53) Axel Thimm: Some parts of the kmdl columns now refer to kmods ....
(18:59:13) Axel Thimm: You took out about 5 lines at least
(18:59:40) Axel Thimm: Some kmdls entries are lost (empty)
(18:59:48) Axel Thimm: It's really a mess, sorry to say that
(19:00:03) Tom Callaway (spot): thimm: which kmdl entries are lost (empty)?
(19:00:22) Tom Callaway (spot): because, i'm looking at the chart and every item has a value
(19:00:24) warren: Of the fedora packaging commitee voters, who are actually here today?
(19:00:41) Rex Dieter (rdieter): here.
(19:00:55) Axel Thimm: For example rpm -U
(19:01:09) warren: Hmm, this is not a voting quorum.
(19:01:10) Rex Dieter (rdieter): rpm -U isn't empty in my browser. ??
(19:01:21) Axel Thimm: It's not the kmdl value either ...
(19:01:24) Toshio Kuratomi (abadget1999): Here
(19:01:25) Axel Thimm: It's suddenly a kmod
(19:01:28) Jason L Tibbitts III (tibbs): Here.
(19:01:56) slack_: I think kmod is a generic term there...
(19:01:57) Toshio Kuratomi (abadget1999): scop placed a vote on the ml list.
(19:01:59) Axel Thimm: Please let's use the original list
(19:02:01) Tom Callaway (spot): thimm: i cut and pasted from your text.
(19:02:15) Tom Callaway (spot): and you were using the word "kmod" universally
(19:02:23) Axel Thimm: No, kmod vs kmdls
(19:02:32) warren: Might I suggest that we not attack each other and instead talk about each technical point, one at a time?
(19:02:49) Thorsten Leemhuis: warren, +1
(19:02:52) Axel Thimm: Yes, please let's use the original list and ignore my rating?
(19:03:14) Tom Callaway (spot): thimm: i'm opposed to this because even your original list is not accurate and quite biased in places
(19:03:14) Axel Thimm: People on the IRC can decide wherther some lines are important or not
(19:03:17) Jesse Keating (f13): I'm here.
(19:03:26) warren: spot, regarding eligible voting, might it be problematic that people with stakes in kernel module standards specifically, especially those who had been working on it for many months outside of this committee, have no vote?
(19:03:28) Axel Thimm: spot: I could say the same
(19:03:40) Jesse Keating (f13): I've got a great proposal since likely nothing will change for FC6
(19:03:41) Axel Thimm: warren: You mean me?
(19:03:58) warren: thimm, no, I meant thl.
(19:04:08) Axel Thimm: No, thl should stay please
(19:04:11) Jesse Keating (f13): lets not vote now and instead revisit this issue once FC6 is out the door and jon masters does his work on module-init-tool which could durasticaly change the concepts we're dealing with.
(19:04:16) warren: and Red Hat yum interests.
(19:04:19) Tom Callaway (spot): warren: fesco can effectively veto.
(19:04:30) warren: oh
(19:04:37) warren: ok, this is fine then.
(19:04:38) Axel Thimm: FC can veto, too
(19:04:48) Tom Callaway (spot): yep.
(19:04:53) warren: Let's just talk about the technical points then?
(19:04:59) slack_: please
(19:05:02) warren: focus on one point
(19:05:14) Axel Thimm: Yes, but not on the reduced list
(19:05:22) Axel Thimm: (with wrong entries)
(19:05:24) Thorsten Leemhuis: warren, one point after the other imho
(19:05:35) Thorsten Leemhuis: there are so many point that can be discussed
(19:05:38) Tom Callaway (spot): Then not on your bloated list (with wrong entries)
(19:05:56) Axel Thimm: show me one, I showed you two ;)
(19:06:00) Tom Callaway (spot): Looks like we're out of lists.
(19:06:04) Tom Callaway (spot): ;)
(19:06:16) Tom Callaway (spot): ok, so here is what i perceive to be the key points
(19:06:19) Tom Callaway (spot): let's start with rpm
(19:06:36) Tom Callaway (spot): specifically, rpm -ivh foo.rpm
(19:06:58) Tom Callaway (spot): under the kmod standard, this seems to work as well as rpm -ivh kernel-foo.rpm
(19:07:01) Axel Thimm: no
(19:07:09) Axel Thimm: slack_ please confirm
(19:07:14) Jesse Keating (f13): no?
(19:07:18) Tom Callaway (spot): thimm: can you provide a counter example of how this does not work?
(19:07:18) Axel Thimm: That's what the fedorakmod.py is fixing
(19:07:19) warren: btw, who is slack?
(19:07:20) ***Jesse Keating (f13) gets confused already.
(19:07:27) Thorsten Leemhuis: yeah, who is slack_ ?
(19:07:29) Tom Callaway (spot): very specifically, rpm -ivh foo.rpm
(19:07:29) Axel Thimm: slack=jack neely
(19:07:40) Tom Callaway (spot): i didn't say a WORD about yum.
(19:07:40) Thorsten Leemhuis: ohh, welcome slack_ :)
(19:07:41) Axel Thimm: The author of fedorakmod.y
(19:07:48) Jesse Keating (f13): crap.
(19:07:50) Axel Thimm: OK spot, example:
(19:07:51) slack_: thl: hi! :-)
(19:07:53) Jesse Keating (f13): I have to leave, stuff happening at new house.
(19:08:01) Axel Thimm: rpm -ihv kmod-foo-1.2.3-2.6.18
(19:08:11) Axel Thimm: rpm -ihv kmod-foo-2.3.4-2.6.18
(19:08:15) Axel Thimm: evr simplyified
(19:08:25) slack_: to me rpm -i works for the kmod standard
(19:08:33) Axel Thimm: See above
(19:08:36) Axel Thimm: Does not work
(19:08:42) Axel Thimm: package needs upgrade, not coinstall
(19:08:43) Thorsten Leemhuis: thimm, rpm -ihv kmod-foo-1.2.3-2.6.18 followed by rpm -ihv kmod-foo-2.3.4-2.6.18 work
(19:08:51) Thorsten Leemhuis: thimm, I just tried some minutes ago
(19:08:59) Axel Thimm: file conflict
(19:09:02) Thorsten Leemhuis: That confused me a bit myself
(19:09:03) Axel Thimm: same kernel
(19:09:04) jeremy [n=katzj at nat-pool-bos.redhat.com] entered the room.
(19:09:09) Thorsten Leemhuis: but it seems to work
(19:09:10) Axel Thimm: It can't work
(19:09:20) Thorsten Leemhuis: thimm, I have prepared a mail
(19:09:20) Axel Thimm: remember the dual nature of kernel modules?
(19:09:30) Axel Thimm: Upgarde within the kernel, coinstal accross kernels
(19:09:34) Thorsten Leemhuis: thimm, I just finished it 15 minutes ago
(19:09:42) Axel Thimm: (or replace kernel with kabi to please jon ;)
(19:10:03) Axel Thimm: Do we agree that kmod does work neither iwth rpm -i nor rpm -U?
(19:10:09) Thorsten Leemhuis: thimm, I don#t really know why
(19:10:12) Thorsten Leemhuis: but -i works
(19:10:14) Tom Callaway (spot): i don't know. seems like rpm -i works.
(19:10:17) Toshio Kuratomi (abadget1999): But coinstal is a feature not a bug :-)
(19:10:20) Axel Thimm: See exmaple above
(19:10:20) Thorsten Leemhuis: rpm ignores the file conflicts
(19:10:28) Axel Thimm: How can it work, if it is for the same kernel/kabi?
(19:10:35) Tom Callaway (spot): rpm -i on two packages does exactly what it is supposed to do
(19:10:39) Tom Callaway (spot): rpm -i should never upgrade
(19:10:46) Axel Thimm: rpm ignores not file conlficts
(19:10:49) slack_: Are we discussing *upgrading* or *installing* a kernel module?
(19:10:56) Tom Callaway (spot): slack_: rpm -ivh
(19:11:07) Axel Thimm: We are discussing general usaeg or rpm cli
(19:11:17) Thorsten Leemhuis: thimm, I just send you the mail I finished 15 minutes ago
(19:11:18) Axel Thimm: OK, an example where neither rpm -i nor rpm -U works?
(19:11:20) ***jcmasters has been testing with rpm -ivh and I confirm it works.
(19:11:21) Thorsten Leemhuis: I should send it to the list
(19:11:33) Thorsten Leemhuis: but I need t oread it once more before I can do that
(19:11:44) slack_: Its an install...kmods work like kernels, there are no conflicting paths
(19:11:51) Thorsten Leemhuis: slack_, correct
(19:11:52) Axel Thimm: kmod-foo-1.2.3-2.6.17
(19:11:52) Axel Thimm: kmod-foo-1.2.3-2.6.18
(19:11:52) Axel Thimm: installed
(19:11:55) jcmasters: thimm: kABI isn't a single thing that I can put in the name of a package :-)
(19:12:06) Axel Thimm: no what should we do with kmod-foo-1.2.4-2.6.18?
(19:12:19) Tom Callaway (spot): thimm: we're not talking about -U
(19:12:24) Axel Thimm: Try with -i
(19:12:29) Axel Thimm: both fail the exmaple above
(19:12:33) Tom Callaway (spot): you cannot upgrade with -i
(19:12:48) slack_: dito
(19:12:49) warren: but it does parallel?
(19:12:51) Tom Callaway (spot): thats why it is -i and not -U
(19:12:56) Axel Thimm: So try -i
(19:13:01) Axel Thimm: in the example above
(19:13:11) Axel Thimm: Conflicts with existzing module for the same kernel
(19:13:11) Tom Callaway (spot): you're trying to do an upgrade in the example above
(19:13:19) jcmasters: thimm: I have situations like that which work fine for me.
(19:13:31) Axel Thimm: Folks, just try it
(19:13:35) Tom Callaway (spot): lets just focus on doing new installs of kernel modules
(19:13:36) Axel Thimm: It will not work
(19:13:37) Tom Callaway (spot): NOT UPGRADES
(19:13:41) Thorsten Leemhuis: BTW: -U will work in the same way as it does for kernels -- only the latest one will survive
(19:13:58) Axel Thimm: nuking your current kernel module that is
(19:14:08) slack_: thl: that was the intended behavior for kmods
(19:14:09) Axel Thimm: rpm -i file conflicts with existing kernel modules
(19:14:16) Tom Callaway (spot): thimm: it does NOT
(19:14:16) Thorsten Leemhuis: thimm, did you try?
(19:14:19) Axel Thimm: spot: we cannot have a schem that only support first time instals
(19:14:25) Axel Thimm: of course!
(19:14:26) Tom Callaway (spot): we've just had several people point out that it does NOT
(19:14:27) Thorsten Leemhuis: thimm, I tried 30 minutes ago, it did not
(19:14:37) Axel Thimm: That's impossible, thl
(19:14:38) Thorsten Leemhuis: maybe I did something wrong
(19:14:39) ***jcmasters has tested this since I've got a rawhide box that just gets modules installed and removed.
(19:14:48) Axel Thimm: thl, we are talking about the same kernel
(19:14:52) Thorsten Leemhuis: thimm, yes
(19:14:58) Thorsten Leemhuis: seems there is something in rpm
(19:14:59) Axel Thimm: And the same file paths
(19:15:09) Thorsten Leemhuis: that ignores file conflicts in packages that have the same name
(19:15:14) jcmasters: thimm: I've installed 24 different versions of the same module over the last few weeks/months :-)
(19:15:15) Axel Thimm: thl: if the contents are identical, rpm won't conplain!
(19:15:27) Axel Thimm: You need different content of course
(19:15:28) Thorsten Leemhuis: thimm, that's why I used /dev/urandom as kernel module
(19:15:45) Axel Thimm: thl and all, it's a principle in rpm:
(19:15:53) Axel Thimm: If a file is shared between packages
(19:16:00) Axel Thimm: then it needs to be same md5sum
(19:16:17) Thorsten Leemhuis: thimm, agreed when it comes to packages with different names
(19:16:26) Thorsten Leemhuis: but it seems packages with the same name work fine
(19:16:31) Thorsten Leemhuis: the md5sum can differ
(19:16:33) jcmasters: thl: indeed.
(19:16:36) Axel Thimm: Then that's a bug
(19:16:40) Axel Thimm: Unrelated to the discussion
(19:16:47) Axel Thimm: becuiase you don't want that to happen
(19:16:51) warren: jeremy, any thoughts on this particular rpm behavior?
(19:16:52) Thorsten Leemhuis: thimm, I'm quite optimistic someone implemented that on purpose
(19:16:57) Thorsten Leemhuis: probably for multilib
(19:16:58) Axel Thimm: it is even worse, now the new kernel module partly ovewrites the old one
(19:17:04) Axel Thimm: instead of cleanly uninstaling it
(19:17:15) jcmasters: Can we just accept that (for whatever reason) it /is/ this way and move on?
(19:17:17) Rex Dieter (rdieter): thimm's got a point there.
(19:17:23) Axel Thimm: Well, whether on pupose or by accident it makes thing even worse for kmod
(19:17:30) Thorsten Leemhuis: yes, It looks a bit confusing
(19:17:31) Tom Callaway (spot): i don't see any way that rpm -i should ever be a valid upgrade mechanism
(19:17:44) Axel Thimm: jcmasters: this is an important part
(19:17:52) Axel Thimm: kmods cannot work in rpm semantics
(19:17:54) Tom Callaway (spot): but for installing new kmod packages for kernels, it DOES work
(19:17:59) jcmasters: spot: for installing two versions of the same kmod. Agreed though, you shouldn't use it for upgrades.
(19:18:02) Thorsten Leemhuis: thimm, seems they do
(19:18:05) slack_: spot: agreed.  If you are using rpm -i then it is assumed there is no other package with that name already installed
(19:18:25) Axel Thimm: spot: if we ignore upgrade paths and the rest any scheme works
(19:18:31) Tom Callaway (spot): thimm: PLEASE
(19:18:37) Tom Callaway (spot): lets focus on one minor point at a time
(19:18:40) Tom Callaway (spot): we will get to upgrades
(19:18:42) Tom Callaway (spot): i promise! :)
(19:18:55) Axel Thimm: We are talking about rpm client usage
(19:18:57) ***jcmasters suggests that installing kmods works, since we've all done it.
(19:19:03) Tom Callaway (spot): thimm: we're talking about rpmi
(19:19:05) Tom Callaway (spot): rpm -i
(19:19:07) Axel Thimm: and it's broken with kmod, why should I admit something different?
(19:19:13) Tom Callaway (spot): JUST RPM -i
(19:19:19) Axel Thimm: it borken
(19:19:24) Axel Thimm: What can I say?
(19:19:29) Tom Callaway (spot): listen for one moment
(19:19:32) Axel Thimm: You have a given system with packages inside
(19:19:33) Tom Callaway (spot): i have no package
(19:19:36) Tom Callaway (spot): i get a packag
(19:19:37) slack_: lets vote on it and update spots wiki page
(19:19:38) Tom Callaway (spot): i rpm -i
(19:19:40) Tom Callaway (spot): it works
(19:19:41) Axel Thimm: We're not talking about a minimal buildroot
(19:19:48) Axel Thimm: Agree on disagreeing?
(19:19:54) jcmasters: It works :-)
(19:20:29) jcmasters: thimm: I'm not anti-either packaging scheme. I have only a vested interest in getting a good solution with kABI etc. But rpm -i does work with kmods.
(19:20:29) Rex Dieter (rdieter): spot: even if it *does* work (no errors, no explicit conflicts), it at worst is overwriting (some of) previous kmod's contents.
(19:21:02) Tom Callaway (spot): rdieter: i don't think rpm -i should ever succeed with a previous package present that is different
(19:21:07) Tom Callaway (spot): if rpm -i does that, its a bug
(19:21:12) Toshio Kuratomi (abadget1999): But there's a proposal for modifying kmods to take care of file conflicts.
(19:21:13) Rex Dieter (rdieter): *bingo*
(19:21:25) slack_: rpm...bugs...heh
(19:21:32) Tom Callaway (spot): rpm -i is NOT FOR UPGRADES
(19:21:37) Axel Thimm: OK, we're not really getting forward
(19:21:49) Axel Thimm: Should we atteack the problem from a differnt POV?
(19:21:59) Axel Thimm: MAybe more high level?
(19:22:06) warren: What do we want to achieve?
(19:22:19) Axel Thimm: a) we all agree that we want a standard, right?
(19:22:25) slack_: we need to agree on a non-biased way to make decisions here
(19:22:29) Axel Thimm: (just because some voiced concerns to drop all)
(19:22:45) Tom Callaway (spot): Currently, we HAVE a standard.
(19:22:47) jcmasters: Can we just go through the points on spot's list?
(19:22:51) Axel Thimm: no
(19:22:58) Thorsten Leemhuis: thimm, that is IMHO a political discussion; that should be handled by the board IMHO
(19:23:00) Axel Thimm: Why not the complete unalteretd list
(19:23:23) jcmasters: rpm -i *works*. Ok it should not be used for upgrades and there might be an RPM bug, but it does install a kernel module.
(19:23:29) slack_: thimm: its biased...would you like me to write up a list and have to follow that one?
(19:23:29) Rex Dieter (rdieter): thimm: let's just use spot's list as a starting point... we can hit *missing* bits later (if need be)
(19:23:34) Axel Thimm: rpm -i works for all packages
(19:23:41) Tom Callaway (spot): thimm: exactly! :)
(19:23:43) Axel Thimm: OK, it may not be used if you have an installed system ...
(19:23:53) Axel Thimm: It may only be used on an emnpty chroot
(19:23:54) Thorsten Leemhuis: rdieter, got a URL to spot's latest list?
(19:23:59) Thorsten Leemhuis: I missed that
(19:24:03) Rex Dieter (rdieter): http://www.fedoraproject.org/wiki/spot/kernel-module-comparison
(19:24:20) Thorsten Leemhuis: rdieter, thx
(19:24:48) Axel Thimm: Changes made by spot:
(19:24:48) Axel Thimm: http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance?action=diff&rev2=8&rev1=4
(19:24:57) Tom Callaway (spot): ok, so rpm -i works on a new system with no kernel module packages present
(19:25:03) jcmasters: thimm: I understand your point, but let's just accept that on some level rpm -i works.
(19:25:16) Axel Thimm: I won't accept that, becasue it is wrong
(19:25:37) Tom Callaway (spot): thimm: i think we'll have to let you disagree and move on
(19:25:37) Axel Thimm: Do you accept that rpm -i works with firefox?
(19:25:51) jcmasters: spot: +1
(19:26:10) Rex Dieter (rdieter): count me as disagreeing too, but let's move on.
(19:26:16) Tom Callaway (spot): rpm -U
(19:26:25) Tom Callaway (spot): upgrading an existing kernel module package
(19:26:29) Tom Callaway (spot): on the commandline with rpm
(19:26:34) Tom Callaway (spot): this does NOT work for kmod
(19:26:40) slack_: agreed
(19:26:42) warren: rpm -U not working is no different than it has historically not worked for kernel itself.  I don't see this as a regression.
(19:26:49) Toshio Kuratomi (abadget1999): warren: +1
(19:26:55) Tom Callaway (spot): does anyone disagree with that?
(19:26:59) Toshio Kuratomi (abadget1999): kmods should behave the same as kernels.
(19:26:59) slack_: warren: agreed as well
(19:27:06) warren: A higher level tool should be handling the problem.
(19:27:18) ***jcmasters agrees with that.
(19:27:32) Rex Dieter (rdieter): kernels are "speshul" :)
(19:27:32) ***Thorsten Leemhuis agrees as well
(19:27:41) ***jeremy too, fwiw
(19:27:41) jcmasters: It would be nice if rpm -U was clean but it's not :-)
(19:27:49) Tom Callaway (spot): ok. next line item: $1 in scriptlets
(19:27:59) Thorsten Leemhuis: left out on purpose
(19:28:01) Thorsten Leemhuis: in kmod
(19:28:02) Tom Callaway (spot): this doesn't work in kmod as far as i could test.
(19:28:13) warren: similarly, I don't think rpm -i is a usual case that we should encourage users to use.  higher level tools should handle it.
(19:28:16) Thorsten Leemhuis: that was requested during the initial kmod debatte
(19:28:41) Rex Dieter (rdieter): thl: why exactly?
(19:28:44) Tom Callaway (spot): thl: do you recall the reasoning why it was requested?
(19:28:52) Thorsten Leemhuis: we had some ideas for it lying around; shoudn't be to hard to add if we really need it
(19:29:00) Thorsten Leemhuis: rdieter, spot, sorry, no ATM
(19:29:08) Thorsten Leemhuis: I would need to look it up in the archieves
(19:29:10) Tom Callaway (spot): ok, so let's flag that as something to revisit
(19:29:16) Thorsten Leemhuis: but we wanted something easy iirc
(19:29:26) Thorsten Leemhuis: where people can#t do any harm
(19:29:39) jcmasters: warren: I'm planning to write a tool for helping with hardware detection and finding a driver in time for FC7 btw.
(19:30:10) Tom Callaway (spot): ok, next item
(19:30:14) jcmasters: warren: e.g. by putting modalias etc. into RPM deps so we can find the right RPM for some hardware.
(19:30:21) Tom Callaway (spot): yum: no special plugin, module installs (not upgrades)
(19:30:22) Rex Dieter (rdieter): thimm pointed out several intances where full scriptlets (and $1) would be needed.
(19:30:43) slack_: spot: this works
(19:30:59) Thorsten Leemhuis: rdieter, I'm not yet 100% sure if you really need them; but yes, maybe one might need them
(19:31:03) Tom Callaway (spot): i would also expect this to work, given that rpm -i is the behavior here.
(19:31:12) slack_: *nod*
(19:31:39) ***Thorsten Leemhuis nods, too
(19:31:40) Tom Callaway (spot): anyone want to voice disagreement or discuss this item?
(19:31:50) warren: slack_, could you please quickly summarize what fedorakmod.py does for those present?
(19:31:54) ***Axel Thimm is not allowed to speak
(19:32:00) Tom Callaway (spot): thimm: of course you are.
(19:32:17) slack_: warren: looks for Provides: kernel-modules, forces transaction element to be i
(19:32:33) Thorsten Leemhuis: slack_, that works in basic yum already
(19:32:43) slack_: yes
(19:33:01) slack_: the behavior is identical, and in fedorakmod.py for bug proofiness
(19:33:46) Thorsten Leemhuis: slack_, k, just wanted to make sure
(19:33:51) slack_: *nod*
(19:34:00) Tom Callaway (spot): yum also gives the added feature of being able to automatically install the kmod package with new kernels
(19:34:03) Tom Callaway (spot): correct?
(19:34:27) Thorsten Leemhuis: spot, that also works without plugin if the repos are in sync
(19:34:32) Thorsten Leemhuis: and if a repo is late
(19:34:40) Thorsten Leemhuis: yum will isntall the module automatically later
(19:34:42) slack_: what thl said :-)
(19:34:54) warren: what about past kernels?
(19:35:03) slack_: no
(19:35:04) warren: so you can reboot into the older kernel
(19:35:05) Thorsten Leemhuis: warren, nope, only current kernel
(19:35:09) Thorsten Leemhuis: warren, also by design
(19:35:11) warren: fedorakmod.py allows that
(19:35:12) warren: ?
(19:35:12) slack_: inteded to be an added feature
(19:35:43) Tom Callaway (spot): ok. so what yum can't handle without a plugin for kmod is: installing kmod packages for older kernels, upgrading existing kmod packages
(19:35:52) slack_: correct
(19:35:56) Thorsten Leemhuis: spot, ni
(19:35:58) Thorsten Leemhuis: no
(19:36:12) Thorsten Leemhuis: yum can't handle "installing kmod packages for older kernels"
(19:36:33) Thorsten Leemhuis: and upgrading existing kmod packages for old kernels does not work
(19:36:43) Thorsten Leemhuis: upgrading for the latest works
(19:36:44) warren: installing kmod for older kernels seems desirable to me
(19:36:58) jcmasters: warren: agreed.
(19:37:01) Tom Callaway (spot): well, upgrading for the latest works at the cost of all the old ones being removed, right?
(19:37:16) Thorsten Leemhuis: warren, well, when we developed the kmod standard people always wanted to only support the latest kernel
(19:37:22) slack_: warren: indeed,
(19:37:23) Thorsten Leemhuis: spot, no, the old ones stay
(19:37:25) slack_: spot: no
(19:37:43) slack_: without fedorakmod.py you get conflicts.  The plugin handles that case
(19:37:44) Thorsten Leemhuis: spot, there seems to be a bug in the installonly plugin
(19:37:51) jcmasters: Bah. I've probably not noticed this in my testing so far. Annoying :-)
(19:37:53) Thorsten Leemhuis: spot, that removes old modules accidentally
(19:39:10) slack_: also, fedorakmod.py can upgrade modules for older kernels with evil rpm tricks, but I really don't count that as "working"
(19:39:34) ***Axel Thimm bites his fist
(19:40:20) Thorsten Leemhuis: spot, how about this conclusion:
(19:40:34) Thorsten Leemhuis: the current kmod standard is designed to support only the latest kernel
(19:40:47) Thorsten Leemhuis: we want to support older kernels in the future too and need a solution
(19:41:01) Thorsten Leemhuis: "uname -r" or other identifies are one way to archieve this
(19:41:07) Thorsten Leemhuis: a plugin another
(19:41:22) Thorsten Leemhuis: EOF
(19:41:47) warren: Perhaps we should discuss the merits of uname -r vs. plugin?
(19:42:00) Thorsten Leemhuis: warren, to complicated here and now
(19:42:08) Rex Dieter (rdieter): or a combination?
(19:42:11) Thorsten Leemhuis: warren, we really would have a detailed lokk at it
(19:42:30) Thorsten Leemhuis: rdieter, we need a plugin if we  use uname -r in any case
(19:42:39) Thorsten Leemhuis: for automatic updates when new kernels arise
(19:42:42) Rex Dieter (rdieter): lot's of kmod's shortcomings can be relieved via uname-r
(19:42:46) Thorsten Leemhuis: the kmdl plugin
(19:43:05) Rex Dieter (rdieter): so, uname-r vs. plugin (only)
(19:43:09) Thorsten Leemhuis: rdieter, but it bings in other nasty issues
(19:43:18) Thorsten Leemhuis: kmod works fine without plugins
(19:43:22) ***slack_ is still uncomfortable with the code there...buts that not the issue here
(19:43:26) ***Axel Thimm drops dead
(19:43:48) Rex Dieter (rdieter): depends on definition of "works fine"
(19:43:56) Thorsten Leemhuis: rdieter, yes, sorry
(19:43:58) slack_: indeed :-)
(19:44:10) Thorsten Leemhuis: kmod works fine IMHO without plugins and only for the latest kernel
(19:44:19) Thorsten Leemhuis: that's a morea accurate
(19:44:54) jcmasters: Did anyone take a look at the kABI additions to kmods btw? IMO that's the better way to pair with kernels.
(19:45:23) Thorsten Leemhuis: jcmasters, I tend to prefer kabit, too
(19:45:27) warren: how hard would it be to improve the plugin to handle more than the latest kernel?
(19:45:29) Thorsten Leemhuis: but I'm not sure myself yet
(19:45:35) slack_: I haven't read your latest emails yet...but a little bit.  And I prefer that solution
(19:46:06) slack_: warren: I had planned on working on some of that support right as this issue...ummm...happened
(19:46:26) warren: It the ugly part is needing stuff to handle rpmvercmp of modules for a given older kernel?
(19:46:26) slack_: I wanted to have some basic support for multiple kernels in FC6
(19:46:45) Axel Thimm: warren: check my writeup close to the reality check
(19:47:03) Axel Thimm: mentions all steps needs to further develop fedorakmod.py
(19:47:17) Axel Thimm: Til the point where everyone should agree that it is too much of workarounds
(19:47:22) jcmasters: slack_: I think that's essential actually.
(19:47:28) slack_: warren: not really...its just digging through the transaction elements and matching modules with kernel versions
(19:48:00) Thorsten Leemhuis: the problem also is: how many kernels *can* we support?
(19:48:08) Thorsten Leemhuis: in FC-updates kernels get removed quite fast
(19:48:15) jcmasters: slack_: I'm volunteering to help you with that if you want.
(19:48:18) Thorsten Leemhuis: so they are not available to the buildsys anymore
(19:48:25) slack_: jcmasters: sweet :-)
(19:48:27) Thorsten Leemhuis: but that can be changes of course
(19:48:31) Thorsten Leemhuis: changed
(19:48:57) slack_: thl: policy on the number of kernels to build for?
(19:49:06) warren: If kernel is available, we can build for it.  And there is no issue of parallel install of differing kernel versions and associated modules.  Only complication is in the plugin.
(19:49:27) warren: It would be a simple matter to change the behavior of kernels disappearing in the repo.
(19:49:29) Thorsten Leemhuis: warren, but do we want to build modules for kernels that have known security problems?
(19:49:44) Thorsten Leemhuis: that was brought up during the first kmod discussion
(19:49:48) Thorsten Leemhuis: and the answer was: no
(19:49:54) warren: Yes.  Users have the option of shooting themselves in the foot.  FOSS is about freedom.
(19:50:02) Thorsten Leemhuis: warren, agreed
(19:50:05) Rex Dieter (rdieter): since thimm is being quiet, need it be mentioned that the kmdl plugin is (reportedly) easier/simpler?
(19:50:18) warren: Note that that question is not a technical question, but rather safety.
(19:50:22) Thorsten Leemhuis: rdieter, I tend to agreed
(19:50:42) Thorsten Leemhuis: rdieter, if we want to support older kernels I'd prefer "uname -r" or stuff like that over a plugin
(19:50:48) jcmasters: So, can we just clarify what we think happens with older kernels that relied on kmods when a new kernel is installed?
(19:50:51) slack_: I'm not sure it properly does the install mods for each kernel bit
(19:50:58) Thorsten Leemhuis: but that opinion can change if someone shows a plugin that works
(19:51:10) Thorsten Leemhuis: s/shows/shows me/
(19:51:24) warren: jeremy indicated strong reservations about adding uname -r
(19:51:31) warren: i hoped he could talk about it himself here.
(19:51:41) ***warren nudges jeremy 
(19:51:42) Thorsten Leemhuis: warren, as I said "other identifiers are also possible"
(19:51:51) Thorsten Leemhuis: it does not have to be uname -r
(19:51:52) Rex Dieter (rdieter): warren: tough... :), it may end up being the least-bad solution.
(19:52:00) Thorsten Leemhuis: I'd like to avoid "uname -r", too
(19:52:25) jcmasters: We could match on the kABI checksum of the struct module struct.
(19:52:33) Tom Callaway (spot): out of curiousity, what other identifier would we use?
(19:52:36) jcmasters: That's currently in the kernel(kernel) kABI dep.
(19:52:58) jeremy: 'uname -r' isn't necessarily good enough, though -- what if you wanted to use the kabi bits?  uname -r pretty much precludes doing so (... aside from my "it's ugly as hell" argument :-)
(19:53:01) jcmasters: But I was thinking about pulling it out into a separate kABI dep just with the minimal items used in modules.
(19:53:16) Thorsten Leemhuis: jcmasters, I#d prefer kABI currently, too
(19:53:29) Thorsten Leemhuis: but we really need to look into this closer
(19:53:32) Thorsten Leemhuis: and decide afterwards
(19:53:43) Rex Dieter (rdieter): are we confident that kABI is good enough?
(19:53:46) jcmasters: So if I modified the kABI generation and had a minimal kernel(module) dep with just struct module in it...
(19:53:46) Thorsten Leemhuis: that's noting we can change now before FC6
(19:53:48) ***Axel Thimm would like to explain to jeremy about kmdl interface design, but spot scratched it from the list ...
(19:54:16) ***jcmasters would like to do that because that dep doesn't always change between kernels...
(19:54:28) Thorsten Leemhuis: jcmasters, +1
(19:54:30) warren: general thought about this entire process, we're making progress by discussing things and not attacking each other.  But the issues are too complex to decide upon today.
(19:54:35) jcmasters: kernel(kernel) does because there's too much in kernel/ in the src.
(19:54:46) jcmasters: warren: agreed.
(19:54:53) warren: thimm, might I suggest instead of attacking spot, talk about the interface design specifically.
(19:55:30) Axel Thimm: warren, it's off the list and if I have a different opinion I'm being censored
(19:55:33) ***jcmasters repeats his earlier point. We don't actually need to be constrained by our notions of where things "should" go. I'm happy to change m-i-t logic to specifically support separately packaged drivers in a sane way that distros can use.
(19:55:41) jeremy: jcmasters: if you use a kabi hash in the name instead, it becomes far harder to figure out what the module is actually for
(19:55:48) ***Axel Thimm will try nonetheless
(19:56:01) jcmasters: jeremy: that's the ugliness of it, yeah.
(19:56:06) slack_: we are all dancing around the same problem
(19:56:08) Axel Thimm: jeremy: The kmdl scheme does not hardcode uname -are in the specfile/src.rpm
(19:56:21) slack_: what ever solution we use a plugin most deal with the 2D versioning
(19:56:24) Axel Thimm: It is sepearted into interface/implementattion
(19:56:31) slack_: How do we encode the extra kernel version into the package?
(19:56:48) Axel Thimm: If one decided to not use uname -are anmyore one can change the unerlying macros and not the source anymore
(19:56:55) Thorsten Leemhuis: slack_, we could do it just like we do in kmods
(19:57:17) slack_: thl, yes, using a provides/requires seems sanest(tm)
(19:57:38) warren: Is Require: kernel-version-release insufficient?  A plugin can examine all of these, and this doesn't interfere with rpmvercmp of modules of the same %{name}.
(19:57:52) slack_: no...need arch
(19:58:00) Thorsten Leemhuis: warren, slack_ is correct
(19:58:00) jcmasters: Just to clarify, in kABI kmodtool, the requires on the kernel version is gone and we add all the kABI deps right now anyway.
(19:58:01) slack_: kernel-i686 = 3
(19:58:38) slack_: also note that this method doesn't need to know about specific kernel variants
(19:58:41) Tom Callaway (spot): guys, i have to go catch a flight. feel free to continue without me.
(19:58:44) jcmasters: so e.g. for kmod-test on kerneldrivers.org relevent deps are:
(19:58:51) jcmasters: test-kmod-common >= 1.8
(19:58:54) slack_: who's writing this down :-)
(19:58:56) jcmasters: kernel(kernel) = bfc3c3d018c61131
(19:59:00) jcmasters: slack_: I'm logging
(19:59:02) Thorsten Leemhuis: warren, your need something like "kernel-i686 = 2.6.17-1.2174_FC5"
(19:59:03) Tom Callaway (spot): thimm: apologies if you felt i was somehow censoring you, it was not my intent
(19:59:05) slack_: sweet
(19:59:16) Axel Thimm: spot: not feeling that, it was a fcat
(19:59:28) warren: thl, ok, is that sufficient for a plugin to decide a kernel module to install for each kernel version?
(19:59:35) Axel Thimm: changing the list, rmeoving items and not allowing me to disagree
(19:59:46) Axel Thimm: Is this session over?
(19:59:47) Thorsten Leemhuis: warren, should be AFAICS
(19:59:55) warren: What problems remain then?
(20:00:21) slack_: jcmasters: with kabi, do we still need an arch dep?
(20:00:25) spot left the room (quit: "Leaving").
(20:00:36) jcmasters: PROPOSAL: we accept the limitations in kmods, with with slack_ to handle older kernels for FC6 and switch over to whatever new system in FC7 given enough time for informed debate.
(20:01:16) jcmasters: slack_: technically, it's unlikely we'd have the same SHA1 (I switched over from MD5s recently) but I would really still want an arch dep :-)
(20:01:26) warren: I would prefer this approach, with the possibility of addition of an identifier (if needed) to aid the plugin's 3D decisioning.
(20:01:30) fedorared [n=john at fedora/fedorared] entered the room.
(20:01:36) slack_: jcmasters: that's what I was thinking...;-)
(20:02:04) jcmasters: slack_: if we fix that problem, FC6 is ok to go as is. Then we listen to thimm more and others and re-think the whole thing in FC7.
(20:02:28) slack_: the multiple kernel support problem?
(20:02:32) ***jcmasters *is* in favor of completely overhauling this puppy, but I think we all agree it needs a lot of thinking time.
(20:02:38) jcmasters: slack_: yeah, IMO.
(20:02:50) Thorsten Leemhuis: jcmasters, I agree with your proposal; but we should make sure that we discuss each part at a time and improve kmod one step at a time
Conversation with #fedora-packaging at 2006-08-18 20:04:04 on thimm at irc.freenode.net (irc)
(20:04:04) : The topic for #fedora-packaging is: Channel for Fedora packaging related discussion | Next Meeting: Thursday, August 17th, 2006 16:00 UTC
(20:04:08) jcmasters: slack_: that's what I'm thinking.
(20:04:13) warren: Install the latest kmod version for each installed kernel, is desirable.
(20:04:15) Rex Dieter (rdieter): thanks all, nice chat. :)
(20:04:17) tibbs [n=tibbs at fedora/tibbs] entered the room.
(20:04:20) rdieter is now known as rdieter_away
(20:04:31) slack_: so yum install kmod-openafs installs for all kernels (or tries)
(20:04:44) slack_: this does not solve the upgrading issue for older kernels
(20:04:48) jcmasters: I think /that/ would address the obvious problems for FC6 and give us sufficient time for informed debate in FC7 timeframe.
(20:04:49) warren: yes, we need the ability to reboot into older kernels
(20:04:55) fedorared [n=john at fedora/fedorared] entered the room.
(20:05:16) slack_: *nod*
(20:05:21) slack_: when is test 3 again?
(20:05:26) warren: How about we add to FC6 kmod standard *ONLY* if an extra identifier is needed for the plugin to do an accurate job?
(20:05:53) Axel Thimm: Sorry, I was reconnected due to 24h-policy of my ISP
(20:05:53) Axel Thimm: can someone past the logs from
(20:05:53) Axel Thimm: "(20:02:50) Thorsten Leemhuis: jcmasters, I agree with your proposal; but we should make sure that we discuss each part at a time and improve kmod one step at a time"
(20:05:53) Axel Thimm: to
(20:05:55) jcmasters: warren: I think that's a good idea. Minimal changes are a good idea at this point.
(20:06:04) Axel Thimm: "(20:04:08) jcmasters: slack_: that's what I'm thinking."
(20:06:19) jcmasters: thimm: uploading logs...
(20:06:26) warren: slack_, freeze is early Sept
(20:06:35) Axel Thimm: jcmasters: thanks
(20:07:00) fedorared: Has packaging discussed using subversion release numbers in pre-release Release tags rather than release date like cvs?
(20:07:07) Toshio Kuratomi (abadget1999): I'd really like us to identify the actual issues with kmod and fix them.  Then we can evaluate if there's anything unfixable and we need to rewrite the standard.
(20:07:17) warren: I think it is unwise to make bigger changes to kmod at this point, it is simply too late.  We need to revisit this point-by-point for FC7.
(20:07:33) slack_: I agree with warren at the moment
(20:07:53) Jason L Tibbitts III (tibbs): fedorared: There's sort of a meeting going on.  I'll get you in #fedora-extras.
(20:08:04) slack_: jcmasters: only problem is freeze is soon...I haven't done much work on this lately
(20:08:18) Toshio Kuratomi (abadget1999): thimm has identified some things (like file conflicts) that should be fixed but with the proposals to do that not-implemented, we don't know whether there's a new set of problems or not.
(20:08:33) jcmasters: thimm: this chat is being live logged at http://fremont.jonmasters.org/~jcm/#fedora-packaging.log
(20:09:04) warren: If I understand the situation correctly, file conflicts are only between simultaneous installs of a two versions of a kernel module for a given kernel?
(20:09:28) slack_: yes
(20:09:29) Toshio Kuratomi (abadget1999): warren: I believe so.
(20:09:36) warren: I don't think this should be an issue.  Neither rpm -i nor rpm -U are advisable supported paths for end-users.  yum and higher level plugins should do the right thing.
(20:09:56) jcmasters: Can we not just sit down at some point and form a new standard that actually addresses all of the issues we identify with both systems? After FC6 we should have a lot more useful data to help that.
(20:10:08) Axel Thimm: jcmasters: thanks again, looks like many people got disconnected during that time.
(20:10:17) thl [n=thl at fedora/thl] entered the room.
(20:10:41) ***Thorsten Leemhuis back, network outage
(20:10:41) Toshio Kuratomi (abadget1999): But what is the right solution?  thimm thinks coinstall is wrong but I think it's right.
(20:10:47) jcmasters: thl: logs at http://fremont.jonmasters.org/~jcm/%23fedora-packaging.log
(20:10:59) Axel Thimm: thl, please check http://fremont.jonmasters.org/~jcm/#fedora-packaging.log
(20:11:03) slack_: I think kmod procedes fairly logically to versioning against kabi instead of kernel versions
(20:11:05) Thorsten Leemhuis: thx
(20:11:15) Toshio Kuratomi (abadget1999): If coinstall is fine, thl had a proposal that would fix the rpm -i case.
(20:11:16) jcmasters: slack_: I agree.
(20:11:26) warren: I think spot was overly concerned that we have a different standard between FC6 and FC7, so much so that he suggested we disallow kmod's for FC6 until we decide.
(20:11:31) Axel Thimm: abadget1999: neither coinstall, nor ugrades are right/wrong
(20:11:32) warren: I dislike this idea.
(20:11:41) ***jcmasters wants to extend support and do modalias packaging eventually so we can also find out what packages support what hardware.
(20:11:58) slack_: We need to improve the existing standard, not completely ditch it :-)
(20:12:05) Axel Thimm: warren: I think change is inevitable
(20:12:20) warren: I will reiterate that I don't consider rpm -i nor rpm -U to be things we worry about.  Yum plugin should do the right thing.  The question then is, is there enough identifiers for yum plugin to do the job today?
(20:12:21) Axel Thimm: It all points to at the very least extend the name in ugl yway
(20:12:27) thl left the room (quit: Nick collision from services.).
(20:12:51) Axel Thimm: warren: In my writeup I outlined that the current plugin does not work
(20:12:55) slack_: warren: yes
(20:12:56) jcmasters: warren: I think so.
(20:13:05) Axel Thimm: and I also showed future work needed and what else will come up
(20:13:13) Jason L Tibbitts III (tibbs): Folks, it looks like freenode has split so some people are getting kicked off.
(20:13:14) jcmasters: slack_: I'll get myself some time freed up to help you fix the plugin before FC6 T3.
(20:13:18) slack_: We have a version/release for the module and a version/release OR kabi for the kernel
(20:13:20) ndim [i=hun at helena.bawue.de] entered the room.
(20:13:38) jcmasters: slack_: exactly.
(20:13:45) slack_: jcmasters: SVN: https://linuxczar.net/svn/slack/trunk/fedorakmod
(20:13:51) jcmasters: slack_: ta
(20:13:53) slack_: that version is also currently incomplete :-)
(20:14:11) Axel Thimm: In contrast the kmdl plugin is ready
(20:14:19) Axel Thimm: and less than half the current size of fedorakmod.py
(20:14:27) slack_: see if I can patch it up today or this weekend
(20:14:33) Axel Thimm: fedorakmod.py will need to reinvent the yum wheel
(20:14:59) slack_: thimm: any plugin has to do 2D versioning
(20:14:59) jcmasters: So can we wind this conversation down and agree that we just need to worry about old kernels for FC6. Then fix the whole design in FC7. Can we have a vote on that idea? (especially people who speak for Fedora officially)?
(20:15:05) Jesse Keating (f13): is this still going on?
(20:15:27) Axel Thimm: There wasn't enough people to vote when this started
(20:15:29) slack_: f13: of course :-)
(20:15:37) Axel Thimm: So currently we're very low on quorum
(20:15:50) jcmasters: PROPOSAL: we put that to those who can vote after this chat.
(20:15:51) thl [n=thl at fedora/thl] entered the room.
(20:15:52) slack_: I'm satisfied with jcmasters proposal
(20:16:14) warren: My recommendation is to go as-is for FC6 and take our time to the right thing for FC7.
(20:16:26) ***Thorsten Leemhuis fully back now
(20:16:30) Axel Thimm: I'd go with spot's proposal
(20:16:31) warren: jcmasters and slack_ can fix the plugin for FC6.
(20:16:34) jcmasters: warren: but fix the old kernel thing for FC6, yes?
(20:16:44) jcmasters: good ok.
(20:16:44) warren: jcmasters, yes
(20:16:47) jcmasters: good ok.
(20:17:10) jcmasters: Well, it's 19:20 here and food is sounding fun :-)
(20:17:19) warren: thimm, if you don't get your way today, you prefer that nobody gets anything?
(20:17:48) Axel Thimm: No, I prefer less known bugs
(20:18:05) Axel Thimm: You blocked the kmods a couple of days ago for the same reason, not?
(20:18:16) warren: thimm, coming late to the party and with an arrogant, accusatory attitude did not help your cause.
(20:18:22) jcmasters: thimm: I *fully agree* there are bugs. But I think it's far less painful to live with this now for FC6 and make big changes for FC7. Disabling the option for kmods is a really bad idea IMO.
(20:18:32) Axel Thimm: warren: You are getting very personal
(20:18:41) Axel Thimm: warren: I don't want to escalate
(20:19:03) Axel Thimm: warren: If someone would rip your writeup apart you would be upset, too
(20:19:19) jcmasters: I think we all agree that thimm is a smart guy with some ideas that need consideration but I think it's *too late* for FC6.
(20:19:19) Jesse Keating (f13): jcmasters: what is the proposal again?
(20:19:22) Axel Thimm: warren: And if you were being told what to define as working or not, you would consider it censoring, too
(20:19:42) jcmasters: fl3: keep kmods in FC6. Fix only major issue of upgrading old kernels and rethink design in FC7.
(20:19:47) ***Thorsten Leemhuis really fully back, but prefers to stay quiet atm
(20:20:19) slack_: so are we done?
(20:20:21) Thorsten Leemhuis: jcmasters, we probably should have a special kernel-module working group
(20:20:28) Jesse Keating (f13): jcmasters: worksforme.
(20:20:38) Thorsten Leemhuis: jcmasters, worksforme, too
(20:20:54) Jesse Keating (f13): jcmasters: however, that means kmod will have to be supported for the next 5+ years (RHEL5)
(20:21:01) jcmasters: There's a closed list at RH for this stuff for partners, I'm going to setup a mailing list for Fedora kmod discussion if you guys think it's a good idea?
(20:21:07) Jesse Keating (f13): but it was really too late to change that anyway.
(20:21:18) jcmasters: fl3: I much prefer /that/ to changing it all :-)
(20:21:42) jcmasters: fl3: I'll live with the pain of it being MY problem in RHEL5. But I'd love to get slack_'s plugin fixes in time :-)
(20:21:55) Jesse Keating (f13): nod
(20:21:56) warren: If the plugin can be fixed to DTRT I don't see any remaining big issues here.
(20:21:56) warren: We should just do that.
(20:22:05) jcmasters: All in favor of a working group mailing list?
(20:22:06) ***slack_ would love to fix it in time
(20:22:07) warren: And FC7 make it perfect with whatever design changes.
(20:22:27) Jesse Keating (f13): Fedora World 7
(20:22:31) jcmasters: lol
(20:22:33) Jesse Keating (f13): (conversation for a different day)
(20:22:41) jcmasters: fl3: indeed.!
(20:22:41) slack_: woot!
(20:22:56) jcmasters: Shall I make a mailing list and invite everyone here to join?
(20:23:00) Rathann [n=rathann at debi.pekin.waw.pl] entered the room.
(20:23:06) Thorsten Leemhuis: jcmasters, +1
(20:23:10) warren: jcmasters, +1
(20:23:11) Jesse Keating (f13): jcmasters: any reason why not to use packaging list?
(20:23:15) slack_: why not?  I'm on them all anyway :-)
(20:23:22) Jesse Keating (f13): because you know lists suck.  more lists suck more.
(20:23:28) warren: hmm
(20:23:30) Thorsten Leemhuis: f13, agreed
(20:23:35) warren: jcmasters, what's wrong with the existing list?
(20:23:40) jcmasters: ok. Well let's just use that then :-)
(20:23:41) Thorsten Leemhuis: but maybe we should have kernel module working group meetings in IRC
(20:23:49) slack_: I really don't care...I just want sane discusion
(20:23:51) jcmasters: thl: +1 instead.
(20:24:00) Jesse Keating (f13): use existing +1
(20:24:29) jcmasters: Ok. slack_ and I get the plugin looked at. Then we start regular meetings to discuss replacement for FC7. When shall those start?
(20:24:30) Thorsten Leemhuis: use existing mailing list and have kernel module working group meetings in IRC +1
(20:24:34) jcmasters: After FC6 release?
(20:24:39) Thorsten Leemhuis: jcmasters, yes
(20:24:42) jcmasters: ok.
(20:24:45) slack_: yes
(20:24:59) slack_: after we have taken our sanity pills
(20:25:00) jcmasters: So, we're done. Is it ok to post the logs to the mailing list?
(20:25:04) jcmasters: (logs of this chat)
(20:25:07) Jesse Keating (f13): yep
(20:25:09) slack_: please do
(20:25:11) Thorsten Leemhuis: posting logs +1
(20:25:17) jcmasters: cool
(20:25:18) Jesse Keating (f13): eating +1
(20:25:21) jcmasters: indeed
(20:25:25) slack_: doing real work: +1
(20:25:26) warren: thimm, I understand why you are upset, but I think this has been a timing problem.  This is akin to congress working on a bill for years, finally passing it, President about to sign it into law because it is needed REAL SOON, then suddenly an outsider attempts to change it.  I hope you can understand how that would be disruptive and upsetting for everyone else.
(20:25:28) Axel Thimm: jcmasters: tahnks for the logging!
(20:25:47) Axel Thimm: warren: I understand that
(20:25:54) jcmasters: thimm: No problem. I'm *very* keen to work with you and not have you feel you're being ignored *in the FC7 timeframe*.
(20:25:56) Axel Thimm: I even took that into the list of comparison
(20:26:01) warren: thimm, let us please work to make the FC7 standard perfect.
(20:26:12) warren: Maybe we can make rpm perfect too. =)
(20:26:15) Axel Thimm: Please givt the kmdl standard a fair chance
(20:26:23) Axel Thimm: I feel like it doesn't get one currently
(20:26:27) jcmasters: warren: they call those must pass legislation amendments :P
(20:26:31) Thorsten Leemhuis: thimm, we need to discuss changes step by step
(20:26:34) Axel Thimm: But let that be my feeling, I'd love to be wrong
(20:26:35) Thorsten Leemhuis: I'm against a complete switch
(20:26:45) Thorsten Leemhuis: but discussing one thing at a time
(20:26:58) Thorsten Leemhuis: and chose the one that looks more sane is okay for me
(20:27:00) Thorsten Leemhuis: but warning
(20:27:06) Axel Thimm: thl: that's why I analysed all differences in so much work
(20:27:08) Thorsten Leemhuis: took half a year last time we did it
(20:27:12) jcmasters: ok. I think we're digressing. I think we all agree we've addressed the key points now, that Thimm has useful things to say and that we'll get time to discuss it all in time for FC7 :-)
(20:27:32) slack_: indeed
(20:27:40) jcmasters: let's wrap this up right now then! :-)
(20:27:42) warren: ok
(20:27:59) Axel Thimm: thanks for attending all!
(20:28:01) Jason L Tibbitts III (tibbs): Is there anyone who is neutral in this debate?
(20:28:06) Axel Thimm: you? ;)
(20:28:13) ***jcmasters will post logs and followup mail in 30 minutes.
(20:28:28) ***Thorsten Leemhuis will go afk now
(20:28:33) Jason L Tibbitts III (tibbs): It might be me, because honestly I don't care one way or the other what happens as long as the outcome is better than what we have now.
(20:28:33) Thorsten Leemhuis: guys have fun!
(20:28:39) warren: Well, the interesting part will be FPB deciding whether we want to allow modules at all.
(20:28:51) Thorsten Leemhuis: warren, when will that be discussed?
(20:28:54) Axel Thimm: warren: is this going to be decided, soon?
(20:28:59) warren: thl, that is FPB's decision, it is political.
(20:29:05) Thorsten Leemhuis: thimm, sure
(20:29:06) warren: I don't know.
(20:29:16) jcmasters is now known as jcmasters_food
(20:29:20) Thorsten Leemhuis: warren, the question is: should we provide more details?
(20:29:34) warren: thl, hmm
(20:29:34) Thorsten Leemhuis: or is the board well informed already ?
(20:29:57) Jason L Tibbitts III (tibbs): It's kind of odd to get so far into the process and actually have kernel modules before deciding whether or not we should have kernel modules.
(20:29:59) warren: I think the board understands the issues involved.
(20:30:00) Thorsten Leemhuis: nobody relied to the mail from jwb on FAB yesterday
(20:30:03) Thorsten Leemhuis: warren, k
(20:30:07) ***Thorsten Leemhuis now really afk
(20:30:09) Thorsten Leemhuis: cu
(20:30:11) warren: ttyl
(20:30:22) Axel Thimm: bye, all!
(20:31:09) Jason L Tibbitts III (tibbs): In any case, RHEL will still need kernel modules, so there's something to be gained from good technical discussion.
(20:31:37) Jason L Tibbitts III (tibbs): And external repositories aren't going to care what FPB says about modules, so a standard method would be good for the end users regardless.
(20:34:01) Jesse Keating (f13): warren: the decision wouldn't be political.  It would be based on real issues like the inevitable lag of module support for new kernels, the inescapable slew of bug reports that go to kernel rather than the particular module, the very existance of the hacks that have to be done either in package name, or in depsolver plugins to handle the nature of kernel modules, etc, etc, etc...  These are problems that no standard can fix.
(20:34:41) Jason L Tibbitts III (tibbs): Do note that the kernel devs will still get the bug reports if the modules live in external repos.
(20:35:33) Jason L Tibbitts III (tibbs): davej says he can tell quickly when a nonstandard module is in use, but he'd still have to look at the tickets unless others volunteer to triage that kind of thing.
(20:38:22) Jesse Keating (f13): nod
(20:38:44) Jesse Keating (f13): but if said modules were available in Core or Extras, that increases the visibility by a long way
(20:40:17) Jason L Tibbitts III (tibbs): I'm not sure.  In general, you don't install a module unless you need it, and if you need it then you'll look for it (or go to some other distro, I guess).
(20:42:20) Jesse Keating (f13): tibbs: unless you do an everything install
(20:42:27) Jesse Keating (f13): and we _know_ people do that kind of crap
(20:43:05) Jason L Tibbitts III (tibbs): I thought we didn't have everything installs.  You certainly can't do an everything install from extras because packages rightfully conflict.
(20:44:26) Jesse Keating (f13): tibbs: we have whiners that want it, and there are people that start with yum install \*
(20:44:45) Jesse Keating (f13): tibbs: but we're off in hyperbole land here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20060818/7c4bbfb4/attachment-0001.bin