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.
ATrpms' concept also supports RHEL3 and earlier FCs and even RHL
releases (e.g. not dependending on availability of kernel-devel which
doesn't exist for these distributions).
So my options are
o convince people about adopting ATrpms' methology
good: field-proven, easy maintenance, many users already accustomed
to kmdls, works on RHEL3 and legacy, too
bad: Thorsten has put a lot of work in the current proposal,
different buildsystem adaption, danger of endless discussions
o fork packages (RHEL3 and legacy in ATrpms, other here)
good: all the bad above reversed
bad: double maintain them
o do nothing
good: no work ;)
bad: no packages :/
Maybe a compromise may look like
o Allow ATrpms' methology to enter the system
o Allow kmdls to get submitted/reviewed
o Modify the methology w/o breaking RHEL3/legacy stuff and w/o
breaking the user's interfacing (but potentially break the
packagers' interface if a better macro system is developed)