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

[Axel Thimm]

On Mon, Aug 14, 2006 at 07:41:40PM +0200, Thorsten Leemhuis wrote:
> >> -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.

Then please check the archives it was after all an answer to a mail
from you. Alternatively please outline what you suppose any kabi stuff
will bring in other than a further delay?

> I prefer to have the same stuff in RHEL and Fedora -- even if it of
> small use in Fedora.

I agree and ATrpms ships kmdls for RHEL3 and RHEL4 since years,
too. Part of kmdl's design is so that RHEL3 is supported, too.

So RHEL is not an issue with kmdls, more an argument in favour of
them.

> >> - 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.

Which were debunked, too. And please add the confusion of users when
say nvidia does not work. File a bug against kmdo-nvidia or nvidia?
Check changelogs of which package for what change?

> >> - 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.

What is manual about it? It works fully transparently in the
background like the usual debuginfo stuff does. There are no manual
actions required or manual entries in specfiles. You don't even need
to patch up redhat-rpm-macros. It can't be more automatic ...

> >> 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.

Everything is in my opinion of course, even that 2+2=4. Still the
current scheme factually remains broken whether it's my opinion or
not.

> But switching to a total different solution is not the only way to fix
> this.

I showed inductively that uname-r-in-name is a neccessity. The other
way is to patch up rpm to use a new rpmvercmp. Not ever going to
happen IMO. The way you seem to prefer is to live with broken rpm
semantics and try to cover up with plugins that try to save the day
for yum but abandon rpm broken and only cover our eyes with dirt that
yum is working.

> Further: I got not only one bug report due to this.

Lack of usage? Lack of updated packages? yum dependency calculation
abort (wrongly) attributed to something else? User totally confused on
the cause of havoc attributing it to his usage?

You know when and *that* it triggers inevitably. You don't need bug
reports for something proven to be the case. I neither have seen any
bug reports on rm -fr / being bad ...

> > 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.

Who said GFS2? GFS is "GFS1" introduced in RHEL3 and supported in
RHEL4 and RHEL5, it denotes an online format as contrasted to actual
GFS versioning (like 6.0 and 6.1). GFS will continue to live outside
the kernel package and is required to support every productive GFS
setup out there. There are no GFS2 productive setups to date (because
there is no enterprise supported solution for GFS2 yet released, RHEL5
possibly layered would be the first)

So it remains the current hertiage is a broken GFS setup for RHEL.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060814/5c5aa943/attachment.sig>