[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ATrpms' kernel modules (kmdls)



On Wed, Apr 26, 2006 at 10:28:10AM -0400, Warren Togami wrote:
> >The dilemma is, that the methology used at ATrpms differs in some
> >fundamental design parts from what is the current proposal, mostly
> >the one spec/src.rpm for both userland and kmdl builds and simple
> >unprepared upstream Sources:, and further derived concept bits.
> 
> This is not a "current proposal".  Over the course of literally
> YEARS Extras has discussed the standard.  Earlier this year Red Hat
> has officially ratified this as the kernel module standard for Core,
> Extras, and RHEL5+.

But over these years, the standard changed in non-adiabatic ways, it's
more like several standards succeeding each other. So if there is
"another standard" that fullfils all needs and maybe more why outrule
it?

> Fedora packages are generally against keeping compatibility across
> many distributions.

That probably sounds stronger than you mean it, almost looks like
you're saying fedora's intention is to not keep compatibility ;)

> That being said, if you can point out ways in which to improve the
> current ratified standard, please start a discussion about specific
> things that can be improved about it.

That's what I did. And the most specific part is (unfortunately) the
top level design of

o several src.rpms per project and
o removing the uname-r info.

IIRC (perhaps from private communication) even thl was unhappy with
both and these somehow were forced onto him. If you rework these then
many other bits need redoing, it's another standard again.

And if that's the way to go, why not pick a standard that is known to
work and be rather mainenance free (otherwise how would I supply 10
(!) distributions with several archs and kernel flavours out of the
same specfiles with automated kmdl builds for new kernels within a
day).
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpnKqXWo96eH.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]