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:
pgpYaQSQSnriT.pgp
Description: PGP signature
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
