On Mon, Aug 14, 2006 at 06:56:15PM +0200, Axel Thimm wrote: > On Mon, Aug 14, 2006 at 06:43:45PM +0200, Thorsten Leemhuis wrote: > > +/-0 currently if we only work for Fedora here. > > 0 is equal to -1 in fedora-packaging > > > -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. > > kabi argumentation was shown to not lead anywhere, not even with RHEL. > > > - changes only in the kmod will require that the userland packages gets > > rebuild, too. > > Changes to glibc-devel will require rebuilding glibc, too. Should we > decompose each package into that many src.rpm as it has suppackages??? > > > - 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. > > That was addressed by Ville on this list and the full sane and > elegant solution already presented. So the rest of the argument is > bogus. > > > > 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 [...] > > It's hardcoded in the guidelines. > > > > 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. > > Are you are trying to subvert the voting by raising the bar too high? > The current scheme was proven to be broken, there is nothing more that > can be broken, the kmdl scheme was presented and is in practice at > ATrpms for *years*. So you have both theoretical and practical proof > on the benefits. Again, show me how kmdl scales. A university/enterprise environment is not a 3rd party extras repository. > > And please consider that you are endorsing a standard for RHEL that is > known to break the yum kmod plugin when it comes to GFS/cman > dependencies, which is the only place where FC or RHEL really use > kernel modules. You haven't addressed all my points either. > > Should Fedora's heritage to RHEL be a completely broken cluster/gfs > setup or should we wait until RHEL's QA addresses upgradability, and > dumps the current scheme then? Or worse, have the customers find out? > -- > Axel.Thimm at ATrpms.net > -- > Fedora-packaging mailing list > Fedora-packaging@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-packaging -- 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
