Axel Thimm schrieb: > On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote: >> +/-0 currently if we only work for Fedora here. > > 0 is equal to -1 in fedora-packaging Sorry, "0" meant undecided for me. >> -1 currently if we want the same stuff in RHEL and Fedora -- the "uname >> -r" is not that important with the kabi stuff and the problem should be >> fixed properly. > kabi argumentation was shown to not lead anywhere, not even with RHEL. "--verbose" please, seems I missed something here. I prefer to have the same stuff in RHEL and Fedora -- even if it of small use in Fedora. >> - changes only in the kmod will require that the userland packages gets >> rebuild, too. > Changes to glibc-devel will require rebuilding glibc, too. Should we > decompose each package into that many src.rpm as it has suppackages??? Well, kmod packages in my experience need some updates now and then (e.g. special patches for a new kernel version). I prefer to save our users the download of a new userland package in that case. That by itself of course doesn't warrent the split. But together with the two other reasons I gave I think it's okay. (Note, I didn't like the split in the beginning when we created the current kmod standard. I really like it now that I got used to it). >> - Because the name of the SRPM doesn't change when you rebuild stuff for >> a newly released kernel the name of the debuginfo packages does also not >> change. > That was addressed by Ville on this list and the full sane and > elegant solution already presented. So the rest of the argument is > bogus. You mean https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html ? That stuff is what I meant with: --- [...] -- created manually; we tried that during the development of the kmod standard. We didn't like it [...] --- in my mail you replied to. >>> c) kernel module scheme needs to be kernel agnostic (both version >>> *and* flavour) >> +1 -- They are agnostic already. The current hardwiring in the spec file >> is only a temporary solution [...] > It's hardcoded in the guidelines. Well, you would have to hardcode it also until the buildsys gains proper support for your scheme. The guidelines ever state that is an interim solution: # stuff to be implemented externally: [...] # hardcode for now: [...] >>> d) support for coinstallation of kmdls should be pushed into FC6 asap >>> (working plugin has already been submitted here and tested be >>> ATrpms users). Requires a positive vote on a-c) >> -1 -- we took about half a year to develop the current standard for FE. >> I'm not going to switch to something where besides Axel no one of the >> people around has practical experiences >> >> - in a hurry >> >> - without getting a buy-in from Jeremy, f13, davej, warren and jcmasters >> >> - after test2 >> >> - shortly before RHEL beta 1 (or is it out already?) >> >> I'd even tend to say: We shouldn't change what was discussed below "a)" >> (see above) at this point. To risky IMHO. > Are you are trying to subvert the voting by raising the bar too high? > The current scheme was proven to be broken "in your opinion" is missing here. Or I lost track completely here. Yes, there is the problem described in https://www.redhat.com/archives/fedora-packaging/2006-August/msg00079.htmlis But switching to a total different solution is not the only way to fix this. Further: I got not only one bug report due to this. I got many report due to problems when we had the "uname -r" in the name. If I'm missing other real "problems" please enlight me. tia! >, there is nothing more that > can be broken, the kmdl scheme was presented and is in practice at > ATrpms for *years*. So you have both theoretical and practical proof > on the benefits. The kmod scheme works fine in lvn for FC5, too. That's not years. But we had years with problems with the other scheme that used to have "uname -r" in the name. > And please consider that you are endorsing a standard for RHEL I do -- that's why I'm proposing a solution based on the current one that works on both FC and RHEL. > that is > known to break the yum kmod plugin when it comes to GFS/cman > dependencies, which is the only place where FC or RHEL really use > kernel modules. GFS2 is in the Fedoras main kernel package for some time now. See http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?view=markup for details. I suspect that will be the case for RHEL, too. CU thl -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
