Hi,
where is the right place to discuss kernel modules, this list?
I know most people are weared out on the subject, and probably don't
want to hear about it anymore. Still, ATrpms has a bunchful of useful
kernel modules that would fit in very well.
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)
e.g. if the basic properties of the kmdl system are acceptable (mostly
the one src.rpm with upstream sources for all builds), then let's get
it into the system to start improving it.
--
Axel.Thimm at ATrpms.net
Attachment:
pgpdhaYyO4JsM.pgp
Description: PGP signature
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
