On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote: > 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 I'm with Thorsten. -1 *) We are way too late to implement a completely new kernel module for FE6/FC6 and RHEL 5. We were on schedule with the kmod scheme. But alas, I've not coded more things because I've been practicing my email skills. (Site point d) *) I also site the scalability concerns. Jack -- Jack Neely <jjneely@xxxxxxxx> Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
