[Fedora-packaging] Re: Mail voting on kmdl adoption

Thorsten Leemhuis fedora at leemhuis.info
Mon Aug 14 17:41:40 UTC 2006


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




More information about the Fedora-packaging mailing list