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
> -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
> 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
That was addressed by Ville on this list and the full sane and
elegant solution already presented. So the rest of the argument is
? 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
>> *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
# stuff to be implemented externally:
# hardcode for now:
>> d) support for coinstallation of kmdls should be pushed into
>> (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
> (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
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.
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
GFS2 is in the Fedoras main kernel package for some time now. See
for details. I suspect that will be the case for RHEL, too.