Axel Thimm schrieb: > a) kernel module scheme needs uname-r-in-name +/-0 currently if we only work for Fedora here. -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. Note the word "currently". > b) kernel module scheme needs one-specfile approach (for both usreland > and kernel modules) -1 ; Reasons: - changes only in the kmod will require that the userland packages gets rebuild, too. That unnecessary. Yes, it can be prevented manually. But we would have to make sure that SRPMs for the old userland packages stay in the repo; and we would need special handling in the buildsys -> can of worms. - people during the last kmod development didn't like having spec files with a lot of -- %if userland do stuff to build userland #endif %if module do stuff to build kmod #endif - 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. So with a one-specfile approach we'd have to -- created manually; we tried that during the development of the kmod standard. We didn't like it or -- that the release in increased everytime so the new debuginfo packages gets a new name -- creates the SRPMS problem described above > c) kernel module scheme needs to be kernel agnostic (both version > *and* flavour) +1 -- They are agnostic already. The current hardwiring in the spec file is only a temporary solution until we have proper support in the buildsys. Yes, there is one place in "kmodtool" where the flavours are hardcoded for users that rebuild kmods manually to prevent that they do something wrong. > d) support for coinstallation of kmdls should be pushed into FC6 asap > (working plugin has already been submitted here and tested be > ATrpms users). Requires a positive vote on a-c) -1 -- we took about half a year to develop the current standard for FE. I'm not going to switch to something where besides Axel no one of the people around has practical experiences - in a hurry - without getting a buy-in from Jeremy, f13, davej, warren and jcmasters - after test2 - shortly before RHEL beta 1 (or is it out already?) I'd even tend to say: We shouldn't change what was discussed below "a)" (see above) at this point. To risky IMHO. > e) [...] Requires a positive vote on a-d) [...] I had to many -1 up to here, so I'm stopping now ;-) CU thl -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
