From cweyl at alumni.drew.edu Tue Aug 1 18:17:38 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 1 Aug 2006 11:17:38 -0700 Subject: [Fedora-packaging] Fwd: When to use perl(:WITH_...) requires? In-Reply-To: <7dd7ab490607310815w1aa3e160w21467dbdc8ec3a8d@mail.gmail.com> References: <7dd7ab490607290826q1edf8743n53d64909fd30f7f1@mail.gmail.com> <7dd7ab490607310815w1aa3e160w21467dbdc8ec3a8d@mail.gmail.com> Message-ID: <7dd7ab490608011117o38033420g9a95ee5e0737aea3@mail.gmail.com> Ok, maybe the third list is the charm :) Could someone please explain to me -- or point me at a doc somewhere -- what these provides are (I gather they indicate features perl was built with), and, more importantly, when they should be used in a spec? They seem as if they may be fairly important, but there's nothing indicating when they should be used, if they're relevant to noarch packages, etc etc, and neither the wiki nor google (oddly enough) is shedding any light on it... -Chris ---------- Forwarded message ---------- From: Chris Weyl Date: Jul 31, 2006 8:15 AM Subject: When to use perl(:WITH_...) requires? To: Discussion related to Fedora Extras Hey all -- Perl provides a number of provides flags, e.g.: perl(:WITH_ITHREADS) perl(:WITH_LARGEFILES) perl(:WITH_PERLIO) perl(:WITH_THREADS) Most perl module spec files only deal with perl(:MODULE_COMPAT_5.8.8), etc. But I see a number of them (arch-specific, typically), do use these flags, along the lines of: Requires: %(perl -MConfig -le 'if (defined $Config{useithreads}) { print "perl(:WITH_ITHREADS)" } else { print "perl(:WITHOUT_ITHREADS)" }') etc, etc. So, when should a packager use these? Should lines along the one above be included for all flags in an arch-specific spec file? What's a good rule of thumb here? (And, are these flags documented anywhere? A cursory search of the wiki isn't turning up anything for me.) -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Tue Aug 1 18:51:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 1 Aug 2006 14:51:02 -0400 Subject: [Fedora-packaging] Fwd: When to use perl(:WITH_...) requires? In-Reply-To: <7dd7ab490608011117o38033420g9a95ee5e0737aea3@mail.gmail.com> References: <7dd7ab490607290826q1edf8743n53d64909fd30f7f1@mail.gmail.com> <7dd7ab490607310815w1aa3e160w21467dbdc8ec3a8d@mail.gmail.com> <7dd7ab490608011117o38033420g9a95ee5e0737aea3@mail.gmail.com> Message-ID: <200608011451.02742.jkeating@redhat.com> On Tuesday 01 August 2006 14:17, Chris Weyl wrote: > Ok, maybe the third list is the charm :) > > Could someone please explain to me -- or point me at a doc somewhere > -- what these provides are (I gather they indicate features perl was > built with), and, more importantly, when they should be used in a > spec? ?They seem as if they may be fairly important, but there's > nothing indicating when they should be used, if they're relevant to > noarch packages, etc etc, and neither the wiki nor google (oddly > enough) is shedding any light on it... I think it comes down to if the perl content in your package depends on these features or not. If you know you'll need ITHREADS or LARGEFILES or PERLIO or whatever, then you would use one of these Requires. It depends on the content of your package. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Aug 2 21:14:53 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 03 Aug 2006 00:14:53 +0300 Subject: [Fedora-packaging] Fwd: When to use perl(:WITH_...) requires? In-Reply-To: <200608011451.02742.jkeating@redhat.com> References: <7dd7ab490607290826q1edf8743n53d64909fd30f7f1@mail.gmail.com> <7dd7ab490607310815w1aa3e160w21467dbdc8ec3a8d@mail.gmail.com> <7dd7ab490608011117o38033420g9a95ee5e0737aea3@mail.gmail.com> <200608011451.02742.jkeating@redhat.com> Message-ID: <1154553294.2743.56.camel@localhost.localdomain> On Tue, 2006-08-01 at 14:51 -0400, Jesse Keating wrote: > On Tuesday 01 August 2006 14:17, Chris Weyl wrote: > > Ok, maybe the third list is the charm :) > > > > Could someone please explain to me -- or point me at a doc somewhere > > -- what these provides are (I gather they indicate features perl was > > built with), and, more importantly, when they should be used in a > > spec? They seem as if they may be fairly important, but there's > > nothing indicating when they should be used, if they're relevant to > > noarch packages, etc etc, and neither the wiki nor google (oddly > > enough) is shedding any light on it... > > I think it comes down to if the perl content in your package depends on these > features or not. > > If you know you'll need ITHREADS or LARGEFILES or PERLIO or whatever, then you > would use one of these Requires. It depends on the content of your package. Yep, and that depends on whether your module packages were built using a perl that has these features enabled or not. My guess is that they're probably not too relevant nowadays and could be ignored; I find it unlikely that a perl without support for threads or large files would appear in FC any more, and for what it's worth, unlike threading and large files stuff, PerlIO support is already hardcode-enabled in the FC perl specfile. Note: for a definite answer, consult the current FC perl maintainer and maybe the previous one (Chip Turner). From cweyl at alumni.drew.edu Wed Aug 2 22:59:02 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 2 Aug 2006 15:59:02 -0700 Subject: [Fedora-packaging] Fwd: When to use perl(:WITH_...) requires? In-Reply-To: <1154553294.2743.56.camel@localhost.localdomain> References: <7dd7ab490607290826q1edf8743n53d64909fd30f7f1@mail.gmail.com> <7dd7ab490607310815w1aa3e160w21467dbdc8ec3a8d@mail.gmail.com> <7dd7ab490608011117o38033420g9a95ee5e0737aea3@mail.gmail.com> <200608011451.02742.jkeating@redhat.com> <1154553294.2743.56.camel@localhost.localdomain> Message-ID: <7dd7ab490608021559t2385e854o9e5d937e48687fd5@mail.gmail.com> On 8/2/06, Ville Skytt? wrote: > Yep, and that depends on whether your module packages were built using a > perl that has these features enabled or not. My guess is that they're > probably not too relevant nowadays and could be ignored; I find it > unlikely that a perl without support for threads or large files would > appear in FC any more, and for what it's worth, unlike threading and > large files stuff, PerlIO support is already hardcode-enabled in the FC > perl specfile. Ahhh, ok, so it's more about what's enabled in the perl the module is built against, rather than something in particular the module's code is doing. That makes more sense. So, from a packaging perspective, would it be appropriate to embed the various requires :WITH_ or :WITHOUT_ in conditionals like the one above, in arch-specific packages? At least that way one knows they always sync up between the perl package and the module package. Or am I really making way too big a deal out of something that should just quietly be allowed to slip into oblivion... :) > Note: for a definite answer, consult the current FC perl maintainer and > maybe the previous one (Chip Turner). cc'ed. :) Thanks- -Chris -- Chris Weyl Ex astris, scientia From jeff at ocjtech.us Thu Aug 3 21:11:28 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 03 Aug 2006 16:11:28 -0500 Subject: [Fedora-packaging] missing this week's meetings In-Reply-To: <1154376857.3478.44.camel@cutter> References: <1154369120.3296.30.camel@localhost.localdomain> <20060731180728.GA18328@jadzia.bu.edu> <1154369767.3296.34.camel@localhost.localdomain> <200607311420.05560.jkeating@redhat.com> <1154370340.3296.37.camel@localhost.localdomain> <20060731182733.GA19395@jadzia.bu.edu> <1154376697.3478.42.camel@cutter> <20060731201250.GA13422@devserv.devel.redhat.com> <1154376857.3478.44.camel@cutter> Message-ID: <1154639488.31062.5.camel@pc04331.campus.dmacc.edu> On Mon, 2006-07-31 at 16:14 -0400, seth vidal wrote: > On Mon, 2006-07-31 at 16:12 -0400, Bill Nottingham wrote: > > seth vidal (skvidal at linux.duke.edu) said: > > > > Clearly, a private Fedora jet is in order. > > > > > > We should get dfong working on a logo mockup on the side of a plane > > > right away. > > > > Why a plane? Don't we already have the black helicopters? > > The logo is blue - it doesn't look as good on a black helicopter. Plus helicopters aren't practical for transcontinental or transoceanic flights... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun Aug 6 11:07:46 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 06 Aug 2006 13:07:46 +0200 Subject: [Fedora-packaging] Fix problems building Extras packages for FC3 and FC4 Message-ID: <44D5CD82.8040103@leemhuis.info> Hi! Now that mock on the Extras builders was updated to 0.6 (thx dgilmore for your work) we noticed that there are big problems building Extras packages for FC3 and FC4. For details see this thread: https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00091.html The problem is well know and described in #196930 -- opened by Paul Howarth on 2006-06-27 We really should fix this as soon as possible. That means: - add elfutils to the default buildroot in all Fedora Dists < FC5 - add python to the default buildroot in FC3 and FC4 Everyone (especially fedora-packaging) fine with that? I'd like to see this fixed soon and would like to avoid waiting for the next meetings. If yes: can somebody (skvidal) please apply this patch: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=133705 and update http://buildsys.fedoraproject.org/buildgroups/ please? The patch does what's described above and also fixes the default buildroots for older dists (see patch for details). CU thl From Axel.Thimm at ATrpms.net Sun Aug 6 18:24:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 6 Aug 2006 20:24:30 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <44CCD892.5060306@leemhuis.info> References: <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> Message-ID: <20060806182430.GB27561@neu.nirvana> On Sun, Jul 30, 2006 at 06:04:34PM +0200, Thorsten Leemhuis wrote: > Toshio Kuratomi schrieb: > > Apologies for posting into the wrong subthread of this monster, I > > already deleted the relevant mail. > > > > If one of the major issues with the current kmod spec is that neither > > rpm -U nor rpm -i work correctly, shouldn't that be corrected? If the > > module could install into something like this: > > /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko > > > > instead of: > > /lib/modules/KERNELVER/extra/MODULE/MODULE.ko > > > > wouldn't that bring the behaviour of kmods inline with that of the > > kernel? (Use rpm -i for normal operations, rpm -U if you don't believe > > in Murphy). > > I like that idea -- especially when combined with the the kabi stuff. > Yes, someone still could run "rpm -Uvh" and would loose older kmods, but > yum and apt would do the right thing. Why would suddenly yum/apt work better? The issues brought up with the current kernel module scheme didn't address the actual contents of the packages and Toshio's suggestion only discusses the contents. So any raised issue on the naming/versioning of kernel module packages still remains as discussed - including non-rpm conformant behaviour of such packages with the rpm -U/-i nuke/conflict situation, which is still not "fixed" on yum level or any other depsolver's (and having looked into yum's plugin system which is quite nice BTW, I don't know whether it will be "fixable" at all) "Fixing yum or the yum plugin" is in quotes, because it is not yum that has any deficiencies, but the current kernel packaging scheme. The kmdl scheme works with yum already even w/o a plugin and a plugin under 100 lines enables coinstalls for new kernel packages. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjneely at ncsu.edu Mon Aug 7 14:00:13 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 7 Aug 2006 10:00:13 -0400 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060806182430.GB27561@neu.nirvana> References: <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> Message-ID: <20060807140013.GK5520@anduril.unity.ncsu.edu> > Why would suddenly yum/apt work better? The issues brought up with the > current kernel module scheme didn't address the actual contents of the > packages and Toshio's suggestion only discusses the contents. > > So any raised issue on the naming/versioning of kernel module packages > still remains as discussed - including non-rpm conformant behaviour of > such packages with the rpm -U/-i nuke/conflict situation, which is still > not "fixed" on yum level or any other depsolver's (and having looked > into yum's plugin system which is quite nice BTW, I don't know whether > it will be "fixable" at all) If the existing fedorakmod.py plugin in yum-utils does not handle installs, upgrades, and co-installs of kmod style kernel modules then I'd like a detailed bug report please. Jack > > "Fixing yum or the yum plugin" is in quotes, because it is not yum > that has any deficiencies, but the current kernel packaging > scheme. > > The kmdl scheme works with yum already even w/o a plugin and a plugin > under 100 lines enables coinstalls for new kernel packages. > -- > Axel.Thimm at ATrpms.net > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From Axel.Thimm at ATrpms.net Mon Aug 7 14:54:14 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 Aug 2006 16:54:14 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060807140013.GK5520@anduril.unity.ncsu.edu> References: <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> Message-ID: <20060807145414.GH27561@neu.nirvana> On Mon, Aug 07, 2006 at 10:00:13AM -0400, Jack Neely wrote: > > So any raised issue on the naming/versioning of kernel module packages > > still remains as discussed - including non-rpm conformant behaviour of > > such packages with the rpm -U/-i nuke/conflict situation, which is still > > not "fixed" on yum level or any other depsolver's (and having looked > > into yum's plugin system which is quite nice BTW, I don't know whether > > it will be "fixable" at all) > > If the existing fedorakmod.py plugin in yum-utils does not handle > installs, upgrades, and co-installs of kmod style kernel modules then > I'd like a detailed bug report please. AFAIU yum's plugin logic in order to perform according to the current rpm-level-broken kernel module scheme a plugin would have to undo parts of yum's transaction. E.g. yum does not offer a hook to manipulate its logic during the depsolving. Note that yum's depsolver logic is rpm conformant. Therefore the moment the fedorakmod.py takes over the transaction set may contain both nuking and conflicts which the plugin needs to address in retrospective now. Coinstall support "solves" the first issue, but the second issue is only "solvable" by removing parts of the transaction. Unfortunately removing is an operation that needs to get back into the depsolver logic - unless the package to be removed has no further dependent or depending on packages. This may be true for most of the current few available kernel modules in this scheme, but there are others that have richer depedendency structure - most notably v4l2 and wifi related modules. It doesn't look like the fedorakmod.py plugin takes that into account. It's still "fixable" by adding even more code, but it's already gaining code size and therefore maintenance costs for something that wasn't "broken" to begin with. This also shows that there may be even more bugs lurking, and this is only the support for yum, rpm still remains "broken" and so do all the other depsolvers. It's nothing against Jack's work or even Thorsten's and Ville's work on the kernel module specs. It's just a core design element that proves to be bad and needs replacement asap. I know I repeat myself, but: There is the kmdl proposal which doesn't even need any special plugins to remain rpm-compliant for both rpm and all depsolvers and while support for coinstalls for new kernels is missing in all depsolvers it proved to be trivial to add a < 100 lines easy to maintain plugin to accomplish that. So there really is only the I-don't-like-uname-r- in-name issue left ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Aug 7 15:19:19 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 07 Aug 2006 10:19:19 -0500 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060807145414.GH27561@neu.nirvana> References: <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> Message-ID: <1154963959.12550.123.camel@localhost.localdomain> On Mon, 2006-08-07 at 16:54 +0200, Axel Thimm wrote: > There is the kmdl proposal which doesn't even need any special plugins > to remain rpm-compliant for both rpm and all depsolvers and while > support for coinstalls for new kernels is missing in all depsolvers it > proved to be trivial to add a < 100 lines easy to maintain plugin to > accomplish that. So there really is only the I-don't-like-uname-r- > in-name issue left ... Axel, what are the differences between the "kmdl" proposal and the existing Fedora kernel module standard? Can you summarize for me? ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From Axel.Thimm at ATrpms.net Mon Aug 7 15:50:52 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 Aug 2006 17:50:52 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1154963959.12550.123.camel@localhost.localdomain> References: <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <1154963959.12550.123.camel@localhost.localdomain> Message-ID: <20060807155052.GI27561@neu.nirvana> On Mon, Aug 07, 2006 at 10:19:19AM -0500, Tom 'spot' Callaway wrote: > On Mon, 2006-08-07 at 16:54 +0200, Axel Thimm wrote: > > > There is the kmdl proposal which doesn't even need any special plugins > > to remain rpm-compliant for both rpm and all depsolvers and while > > support for coinstalls for new kernels is missing in all depsolvers it > > proved to be trivial to add a < 100 lines easy to maintain plugin to > > accomplish that. So there really is only the I-don't-like-uname-r- > > in-name issue left ... > > Axel, what are the differences between the "kmdl" proposal and the > existing Fedora kernel module standard? Can you summarize for me? The main design differences are o one src.rpm for both userland and kernel module subpackages. o full abstraction of names and embedded dependencies supporting among others a uname-r-in-name scheme. The latter means that the kmdl macros used are flexible enough to even produce the current kernel module scheme. But they can also produce what is usually known as kmdl packages including the uname-r-in-name idiom and therefore remaining rpm conformant. So kmdl is both o an abstract interface hiding implementation details from the specfile o an explit implemenentation of these macros to fulfill rpm compliant versioning of kernel modules This results in a flexible and powerful kernel module macro language and very small and maintainable forward-compatible specfiles (e.g. specfiles survive any furture implementation modification). For a very small (but also very old) example see http://dl.atrpms.net/all/arc4.spec (This kmdl is used for *swan support on RHEL3 IIRC, e.g. the openswan kmdl depends on presence of the arc4 cipher. It was the smallest example I found, it has no userland parts but the placeholders are still there) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Aug 7 16:19:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 Aug 2006 18:19:51 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060807155052.GI27561@neu.nirvana> References: <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <1154963959.12550.123.camel@localhost.localdomain> <20060807155052.GI27561@neu.nirvana> Message-ID: <44D76827.6030905@leemhuis.info> Axel Thimm schrieb: > On Mon, Aug 07, 2006 at 10:19:19AM -0500, Tom 'spot' Callaway wrote: > > o one src.rpm for both userland and kernel module subpackages. People disliked that when we created the current kmod standard because either you build the userland stuff for i586 and i686 or you have to add a lot of %if foo #build userland %endif %if bar #build module %endif into the spec file. People also wanted proper debuginfo packages. This means that you have to create the debuginfo packages either manually or have to increase the release each time you build for a new kernel. >[...] > For a very small (but also very old) example see > > http://dl.atrpms.net/all/arc4.spec >From a quick glance: -> no proper debuginfo packages -> has to be queued to the buildsys multiple time to build for UP, SMP, Xen, ... (it at least looks this way? Or am I wrong?) Cu thl From fedora at leemhuis.info Mon Aug 7 16:22:52 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 Aug 2006 18:22:52 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060806182430.GB27561@neu.nirvana> References: <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> Message-ID: <44D768DC.4040507@leemhuis.info> Axel Thimm schrieb: > On Sun, Jul 30, 2006 at 06:04:34PM +0200, Thorsten Leemhuis wrote: >> Toshio Kuratomi schrieb: >>> Apologies for posting into the wrong subthread of this monster, I >>> already deleted the relevant mail. >>> >>> If one of the major issues with the current kmod spec is that neither >>> rpm -U nor rpm -i work correctly, shouldn't that be corrected? If the >>> module could install into something like this: >>> /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko >>> >>> instead of: >>> /lib/modules/KERNELVER/extra/MODULE/MODULE.ko >>> >>> wouldn't that bring the behaviour of kmods inline with that of the >>> kernel? (Use rpm -i for normal operations, rpm -U if you don't believe >>> in Murphy). >> I like that idea -- especially when combined with the the kabi stuff. >> Yes, someone still could run "rpm -Uvh" and would loose older kmods, but >> yum and apt would do the right thing. > > Why would suddenly yum/apt work better? Because /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko avoids that there are ever file conflicts between packages so yum will always be able to install the new module (just like the kernel -- you can of course still do rpm -Uvh manually, but I don't care because that's possible with the kernel, too). CU thl From Axel.Thimm at ATrpms.net Mon Aug 7 16:36:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 Aug 2006 18:36:08 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <44D76827.6030905@leemhuis.info> References: <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <1154963959.12550.123.camel@localhost.localdomain> <20060807155052.GI27561@neu.nirvana> <44D76827.6030905@leemhuis.info> Message-ID: <20060807163608.GA19528@neu.nirvana> On Mon, Aug 07, 2006 at 06:19:51PM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Mon, Aug 07, 2006 at 10:19:19AM -0500, Tom 'spot' Callaway wrote: > > > > o one src.rpm for both userland and kernel module subpackages. > > People disliked that when we created the current kmod standard because > either you build the userland stuff for i586 and i686 or you have to add > a lot of > %if foo > #build userland > %endif > %if bar > #build module > %endif > into the spec file. It's better than to have two possibly divergent specs/src.rpms. Just imagine a cvs patch to apply to to both packages at once. You only have three %if/%else/%endif constructs in a common specfile saving quite a bit of redundant information and having a proper common changelog - maintenance and package overview is much better in a common specfile. I think some of the design problems of the current kernel module scheme is due to allowing too much "external" pressure to get them through. I don't think/remember early drafts to have done this splitting of src.rpms just as I know the uname-r was removed due to external requests. The kernel module scheme was finally accepted, but at what price? > People also wanted proper debuginfo packages. This means that you have > to create the debuginfo packages either manually or have to increase the > release each time you build for a new kernel. Proper debuginfo packages are produced at ATrpms - just not published due to lack of size. > >[...] > > For a very small (but also very old) example see > > > > http://dl.atrpms.net/all/arc4.spec > > >From a quick glance: > > -> no proper debuginfo packages Where do you see that in the specfile? FWIW debuginfos are no problem at all for kmdls. > -> has to be queued to the buildsys multiple time to build for UP, SMP, > Xen, ... (it at least looks this way? Or am I wrong?) Yes, and that's actually a *feature* I forgot to add to the design principles: o kmdls are completely kernel flavour agnostic. There is no hardwiring up/smp/xen anywhere. Which is why the same specfile can be used unaltered for xenU/xen0/xen/PAE/kdump and whatever future kernel flavours may come up or even on RHEL flavours like hugemem. And it even works when the flavours change over the curse of time like "xen" suddenly appearing in FC5 alongside xen0/xenU. The easy maintenance of the kmdl scheme based specfiles and buildsystems are the reason why ATrpms can offer that many kernel modules for that many distributions/releases/flavour at a very timely schedule after each kernel upgrade with only a fragment of one human resource :=) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 7 16:39:23 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 Aug 2006 18:39:23 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <44D768DC.4040507@leemhuis.info> References: <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <44D768DC.4040507@leemhuis.info> Message-ID: <20060807163923.GB19528@neu.nirvana> On Mon, Aug 07, 2006 at 06:22:52PM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Sun, Jul 30, 2006 at 06:04:34PM +0200, Thorsten Leemhuis wrote: > >> Toshio Kuratomi schrieb: > >>> Apologies for posting into the wrong subthread of this monster, I > >>> already deleted the relevant mail. > >>> > >>> If one of the major issues with the current kmod spec is that neither > >>> rpm -U nor rpm -i work correctly, shouldn't that be corrected? If the > >>> module could install into something like this: > >>> /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko > >>> > >>> instead of: > >>> /lib/modules/KERNELVER/extra/MODULE/MODULE.ko > >>> > >>> wouldn't that bring the behaviour of kmods inline with that of the > >>> kernel? (Use rpm -i for normal operations, rpm -U if you don't believe > >>> in Murphy). > >> I like that idea -- especially when combined with the the kabi stuff. > >> Yes, someone still could run "rpm -Uvh" and would loose older kmods, but > >> yum and apt would do the right thing. > > > > Why would suddenly yum/apt work better? > > Because > > /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko > > avoids that there are ever file conflicts between packages so yum will > always be able to install the new module (just like the kernel -- you > can of course still do rpm -Uvh manually, but I don't care because > that's possible with the kernel, too). I understand, you push the problem from rpm/yum to module-init-tools, e.g. now /sbin/depmod needs to understand rpmvercmp to decide which MODULE-VERSION-RELEASE is newer? The issue is still there, just not where it belong, in rpm and yum. It is now at module-init-tools level and suddenly /sbin/depmod would need to understand rpm ordering rules. I don't think that's an improvement :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Aug 8 05:40:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 08 Aug 2006 07:40:51 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060807163923.GB19528@neu.nirvana> References: <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <44D768DC.4040507@leemhuis.info> <20060807163923.GB19528@neu.nirvana> Message-ID: <44D823E3.3090900@leemhuis.info> Axel Thimm schrieb: > On Mon, Aug 07, 2006 at 06:22:52PM +0200, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: >>> On Sun, Jul 30, 2006 at 06:04:34PM +0200, Thorsten Leemhuis wrote: >>>> Toshio Kuratomi schrieb: >>>>> Apologies for posting into the wrong subthread of this monster, I >>>>> already deleted the relevant mail. >>>>> >>>>> If one of the major issues with the current kmod spec is that neither >>>>> rpm -U nor rpm -i work correctly, shouldn't that be corrected? If the >>>>> module could install into something like this: >>>>> /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko >>>>> >>>>> instead of: >>>>> /lib/modules/KERNELVER/extra/MODULE/MODULE.ko >>>>> >>>>> wouldn't that bring the behaviour of kmods inline with that of the >>>>> kernel? (Use rpm -i for normal operations, rpm -U if you don't believe >>>>> in Murphy). >>>> I like that idea -- especially when combined with the the kabi stuff. >>>> Yes, someone still could run "rpm -Uvh" and would loose older kmods, but >>>> yum and apt would do the right thing. >>> Why would suddenly yum/apt work better? >> Because >> >> /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko >> >> avoids that there are ever file conflicts between packages so yum will >> always be able to install the new module (just like the kernel -- you >> can of course still do rpm -Uvh manually, but I don't care because >> that's possible with the kernel, too). > > I understand, you push the problem from rpm/yum to module-init-tools, > e.g. now /sbin/depmod needs to understand rpmvercmp to decide which > MODULE-VERSION-RELEASE is newer? Well, if we use the kerneldrivers stuff from jcm then /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko seems like the better place for modules than /lib/modules/KERNELVER/extra/MODULE/MODULE.ko because the latter path might be confusing when KERNELVER was already deinstalled. > The issue is still there, just not where it belong, in rpm and yum. It > is now at module-init-tools level and suddenly /sbin/depmod would need > to understand rpm ordering rules. The kerneldrivers stuff will handle that in any case afaics. The question is: do we want to use it. There are also other open question if we want to use it, e.g. - when does a kmod get removed? - do we need to drop the hard dep on the kernel > I don't think that's an improvement :) I didn't try it out yet. Maybe it's an improvement, maybe not. CU thl From fedora at leemhuis.info Tue Aug 8 05:52:20 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 08 Aug 2006 07:52:20 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060807163608.GA19528@neu.nirvana> References: <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <1154963959.12550.123.camel@localhost.localdomain> <20060807155052.GI27561@neu.nirvana> <44D76827.6030905@leemhuis.info> <20060807163608.GA19528@neu.nirvana> Message-ID: <44D82694.80104@leemhuis.info> Axel Thimm schrieb: > On Mon, Aug 07, 2006 at 06:19:51PM +0200, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: >>> On Mon, Aug 07, 2006 at 10:19:19AM -0500, Tom 'spot' Callaway wrote: >>> >>> o one src.rpm for both userland and kernel module subpackages. >> People disliked that when we created the current kmod standard because >> either you build the userland stuff for i586 and i686 or you have to add >> a lot of >> %if foo >> #build userland >> %endif >> %if bar >> #build module >> %endif >> into the spec file. > > It's better than to have two possibly divergent specs/src.rpms. Debatable. When the kmod standard was developed people were in favor of a split. I used the above scheme for round about two years (E.g. FC2, FC3 and FC4) and I prefer the two srpms solution now that I got used to it (I didn't like it in the beginning). > Just > imagine a cvs patch to apply to to both packages at once. You only > have three %if/%else/%endif constructs in a common specfile saving > quite a bit of redundant information and having a proper common > changelog - maintenance and package overview is much better in a > common specfile. I don't think that's a real benefit. > I think some of the design problems of the current kernel module > scheme is due to allowing too much "external" pressure to get them > through. I don't think/remember early drafts to have done this > splitting of src.rpms just as I know the uname-r was removed due to > external requests. The kernel module scheme was finally accepted, but > at what price? It was a compromise and I must say it works a lot better than the stuff we had before (with uname-r in the name) and I'm quite satisfied with it. >> People also wanted proper debuginfo packages. This means that you have >> to create the debuginfo packages either manually or have to increase the >> release each time you build for a new kernel. > Proper debuginfo packages are produced at ATrpms - just not published > due to lack of size. Okay. Looking closer. But that would also means you get a SRPM per kernel variant afaics? That will waste a lot of space on the servers (yes, technically all those SRPMS contain the same stuff, but there were people that want to find the corresponding SRPM by looking at %{SOURCERPM} -- that will fail if you don't upload all those SRPMS) >>> [...] >> -> has to be queued to the buildsys multiple time to build for UP, SMP, >> Xen, ... (it at least looks this way? Or am I wrong?) > > Yes, and that's actually a *feature* I forgot to add to the design > principles: > > o kmdls are completely kernel flavour agnostic. There is no hardwiring > up/smp/xen anywhere. That's also true for the current kmod stuff. We hardwire it currently for the buildsystem until it gains support for to pass the defines over. And new kernel flavour should in work without adjustments. > The easy maintenance of the kmdl scheme based specfiles and > buildsystems are the reason why ATrpms can offer that many kernel > modules for that many distributions/releases/flavour at a very timely > schedule after each kernel upgrade with only a fragment of one human > resource :=) I still can't see it being much easier, sorry. Here and there it's a bit easier, yes, but here and there it's a bit more complicated -> overall it comes down to the same. CU thl From Axel.Thimm at ATrpms.net Tue Aug 8 05:53:19 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 Aug 2006 07:53:19 +0200 Subject: [Fedora-packaging] blocking kmdl adoption at all costs? (was: atrpms kernel modules) In-Reply-To: <44D823E3.3090900@leemhuis.info> References: <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <44D768DC.4040507@leemhuis.info> <20060807163923.GB19528@neu.nirvana> <44D823E3.3090900@leemhuis.info> Message-ID: <20060808055319.GC1475@neu.nirvana> On Tue, Aug 08, 2006 at 07:40:51AM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > >On Mon, Aug 07, 2006 at 06:22:52PM +0200, Thorsten Leemhuis wrote: > >>Axel Thimm schrieb: > >>>On Sun, Jul 30, 2006 at 06:04:34PM +0200, Thorsten Leemhuis wrote: > >>>>Toshio Kuratomi schrieb: > >>>>>Apologies for posting into the wrong subthread of this monster, I > >>>>>already deleted the relevant mail. > >>>>> > >>>>>If one of the major issues with the current kmod spec is that neither > >>>>>rpm -U nor rpm -i work correctly, shouldn't that be corrected? If the > >>>>>module could install into something like this: > >>>>> /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko > >>>>> > >>>>>instead of: > >>>>> /lib/modules/KERNELVER/extra/MODULE/MODULE.ko > >>>>> > >>>>>wouldn't that bring the behaviour of kmods inline with that of the > >>>>>kernel? (Use rpm -i for normal operations, rpm -U if you don't believe > >>>>>in Murphy). > >>>>I like that idea -- especially when combined with the the kabi stuff. > >>>>Yes, someone still could run "rpm -Uvh" and would loose older kmods, but > >>>>yum and apt would do the right thing. > >>>Why would suddenly yum/apt work better? > >>Because > >> > >>/lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko > >> > >>avoids that there are ever file conflicts between packages so yum will > >>always be able to install the new module (just like the kernel -- you > >>can of course still do rpm -Uvh manually, but I don't care because > >>that's possible with the kernel, too). > > > >I understand, you push the problem from rpm/yum to module-init-tools, > >e.g. now /sbin/depmod needs to understand rpmvercmp to decide which > >MODULE-VERSION-RELEASE is newer? > > Well, if we use the kerneldrivers stuff from jcm then > /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko > seems like the better place for modules than > /lib/modules/KERNELVER/extra/MODULE/MODULE.ko > because the latter path might be confusing when KERNELVER was already > deinstalled. I agree, but still something needs to manage the evr (where epoch is missing in the above path BTW) comparison of modules per kernel. > >The issue is still there, just not where it belong, in rpm and yum. It > >is now at module-init-tools level and suddenly /sbin/depmod would need > >to understand rpm ordering rules. > > The kerneldrivers stuff will handle that in any case afaics. The > question is: do we want to use it. There are also other open question if > we want to use it, e.g. > - when does a kmod get removed? > - do we need to drop the hard dep on the kernel > > >I don't think that's an improvement :) > > I didn't try it out yet. Maybe it's an improvement, maybe not. *Something* in the system needs to be able to compare different evrs of "MODULE-VERSION-RELEASE" and decide on *removing* the old module. It really *needs removal* and not simple overriding because the new and old kernel module package's contents may differ in the number/names of carried kernel module files. Even if removing would not be needed and we could live with module-init-tools doing some magic you would still have to push the rpmvercmp logic to module-init-tools which upstream will not accept. And we don't gain anything: The problem must still be solved, it just looks like being out of sight. So pushing this problem out of rpm's and yum's scope is very wrong and only creates more problems. This is not against the actual location of kernel module files. For the kabi forward-compatibility stuff thinking about new locations is OK, but it will not solve the issues we're talking about. It's realy purely orthogonal. Did I mention that resitance is futile? This is the umpteenth attempt to find something to block kmdl adoption, that I need to argue against. If I would had put that energy into something else I would probably had solved the TOE by now. Possibly my attempts to get a sane kernel module packaging scheme is futile ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 8 06:11:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 Aug 2006 08:11:27 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <44D82694.80104@leemhuis.info> References: <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <1154963959.12550.123.camel@localhost.localdomain> <20060807155052.GI27561@neu.nirvana> <44D76827.6030905@leemhuis.info> <20060807163608.GA19528@neu.nirvana> <44D82694.80104@leemhuis.info> Message-ID: <20060808061127.GD1475@neu.nirvana> On Tue, Aug 08, 2006 at 07:52:20AM +0200, Thorsten Leemhuis wrote: > >You only have three %if/%else/%endif constructs in a common > >specfile saving quite a bit of redundant information and having a > >proper common changelog - maintenance and package overview is much > >better in a common specfile. > > I don't think that's a real benefit. Lower maintenance not a benefit? > >I think some of the design problems of the current kernel module > >scheme is due to allowing too much "external" pressure to get them > >through. I don't think/remember early drafts to have done this > >splitting of src.rpms just as I know the uname-r was removed due to > >external requests. The kernel module scheme was finally accepted, > >but at what price? > > It was a compromise and I must say it works a lot better than the stuff > we had before (with uname-r in the name) and I'm quite satisfied with it. I'm sorry, but you actively ignore the fact that was discussed over and over again in this thread that this scheme is *broken at rpm level*, dragging into the breakage all depsolvers which therefore *require* patching/plugins all one-by-one to avoid severe problems like nuking current working graphics drivers from the system. And you know that this will never get fixed on rpm level. How can you be satisfied with this situation, when you know it can all be fixed? And not even know, but can see in practise. The kmdls are there since several years. > Okay. Looking closer. But that would also means you get a SRPM per > kernel variant afaics? That will waste a lot of space on the servers Yes, that would waste a lot of space. NO, THIS IS NOT THE CASE!!! Please, Thorsten, it does look to me that you are desperately trying to find reasons against kmdls. You're really pushing me to the edge. The waste of space are the current src.rpm pairs that are needed in your scheme. Twice the sources is redundant, a waste of space and error prone. so if you agree on saving space let's go kmdls, they only need half the space. ... > >The easy maintenance of the kmdl scheme based specfiles and > >buildsystems are the reason why ATrpms can offer that many kernel > >modules for that many distributions/releases/flavour at a very timely > >schedule after each kernel upgrade with only a fragment of one human > >resource :=) > > I still can't see it being much easier, sorry. Here and there it's a bit > easier, yes, but here and there it's a bit more complicated -> overall > it comes down to the same. Sorry, we strongly disagree. What exactly is more complicated about kmdls? The fact that o plugins are not *required*, but a nice-to-have? o these plugins are at most half the code that a plugin for the current scheme needs? o works at rpm level? o Only one src.rpm for everything cutting space and reducing maintenance I can only see benfits with kmdls, and not nice-to-have stuff, but required functionality that the current scheme cannot offer. For God's sake *the current scheme is broken* and we're trying to patch up yum with plugins to get back to rpm behaviour. And the patch/plugin is still not complete, and the same is needed for other depsolvers and still rpm CLI will be broken. Shouldn't that make all alarms sound? That's far from "overall it comes down to the same". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Aug 8 06:12:53 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 08 Aug 2006 08:12:53 +0200 Subject: [Fedora-packaging] blocking kmdl adoption at all costs? In-Reply-To: <20060808055319.GC1475@neu.nirvana> References: <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <44D768DC.4040507@leemhuis.info> <20060807163923.GB19528@neu.nirvana> <44D823E3.3090900@leemhuis.info> <20060808055319.GC1475@neu.nirvana> Message-ID: <44D82B65.9070500@leemhuis.info> Axel Thimm schrieb: > On Tue, Aug 08, 2006 at 07:40:51AM +0200, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: > > Did I mention that resitance is futile? This is the umpteenth attempt > to find something to block kmdl adoption, that I need to argue > against. If I would had put that energy into something else I would > probably had solved the TOE by now. > > Possibly my attempts to get a sane kernel module packaging scheme is > futile ... > You are in the packaging committee, I'm not. If you convince the others in the committee that throwing away the current standard (that will be used in RHEL5 afaics) and that going "back" to something that's similar to the stuff we used in fedora.us/lvn is a good thing -> go ahead. CU thl From fedora at leemhuis.info Tue Aug 8 06:38:17 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 08 Aug 2006 08:38:17 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060808061127.GD1475@neu.nirvana> References: <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <1154963959.12550.123.camel@localhost.localdomain> <20060807155052.GI27561@neu.nirvana> <44D76827.6030905@leemhuis.info> <20060807163608.GA19528@neu.nirvana> <44D82694.80104@leemhuis.info> <20060808061127.GD1475@neu.nirvana> Message-ID: <44D83159.1070302@leemhuis.info> Hi! Axel Thimm schrieb: I'll leave the rest of the mail to the members of the packaging committee, but I'd like to say one thing to this para: > Please, Thorsten, it does look to me that you are desperately trying > to find reasons against kmdls. You're really pushing me to the edge. Sorry, that was not my intention. I just tried to lay down the details behind the decisions that lead to the current kmod standard. CU thl From Axel.Thimm at ATrpms.net Tue Aug 8 09:26:46 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 Aug 2006 11:26:46 +0200 Subject: [Fedora-packaging] kmdl proposal and kmod flaws Message-ID: <20060808092646.GE1475@neu.nirvana> I've created a wiki page outlining the kmdl design as well as showing the flaws of the current kernel module scheme ("kmod"): http://fedoraproject.org/wiki/AxelThimm/kmdls It's focusing on the properties that are different in the two schemes as such it is not a stand-alone specification. The purpose of this write-up is to clarify the issues we're facing and in light of this to stop further adoption of the current kernel module scheme especially in GFS related parts in FC. Please take some time to read it through, if I forgot some arguments I will add them later to it. I would very much like to discuss it on Thursday and vote on whether the kmod scheme should be blocked in favour of adopting a kmdl scheme. Beyond fedora-packaging's scope, e.g. hammering together a sane guide for kernel modules, I'm willing to work with build infrastructure to get the kmdl scheme firmly in place if this is approved and ratified. I've done that in the past with ATrpms' buildsystem, so I hope it will not be a too difficult task. Furthermore I will work with upstream depsolver authors to get the (trivial) kmdl support in all depsolvers. For yum and apt this can be considered as already done, for smart I requested convenient hooks for plugging in kmdl support which upstream already accepted. I will also try to promote this scheme to the kmp/kerneldriver.org folks. I think the kmdl scheme has a chance of becoming a wider-spread standard that all rpm distros will benefit from. Thanks. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Aug 8 10:04:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 08 Aug 2006 12:04:51 +0200 Subject: [Fedora-packaging] kmdl proposal and kmod flaws In-Reply-To: <20060808092646.GE1475@neu.nirvana> References: <20060808092646.GE1475@neu.nirvana> Message-ID: <44D861C3.3050708@leemhuis.info> Axel Thimm schrieb: > I've created a wiki page outlining the kmdl design as well as showing > the flaws of the current kernel module scheme ("kmod"): > > http://fedoraproject.org/wiki/AxelThimm/kmdls Just FYI, I won't oppose this in general -- if people think this is the way forward (*1) and if we get a buy in from Core developers, too, I'm fine with working further on it. CU thl (*1) -- But I doubt that it is because some important pieces of this scheme are similar to the one we started with when we developed the current kmod-standard From Axel.Thimm at ATrpms.net Tue Aug 8 10:11:50 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 8 Aug 2006 12:11:50 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <44D861C3.3050708@leemhuis.info> References: <20060808092646.GE1475@neu.nirvana> <44D861C3.3050708@leemhuis.info> Message-ID: <20060808101150.GB7062@neu.nirvana> On Tue, Aug 08, 2006 at 12:04:51PM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > >I've created a wiki page outlining the kmdl design as well as showing > >the flaws of the current kernel module scheme ("kmod"): > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls > > Just FYI, I won't oppose this in general -- if people think this is the > way forward (*1) and if we get a buy in from Core developers, too, I'm > fine with working further on it. Thanks. > CU > thl > > (*1) -- But I doubt that it is because some important pieces of this > scheme are similar to the one we started with when we developed the > current kmod-standard I hope that the wiki page is outlining the issues good enough for non-kernel-module experts, too, so that pointing Core folks disliking this proposal to the wiki may help. But first the fedora-packaging group needs to give it's blessing before the real nasty guys show up ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Aug 8 10:30:46 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 08 Aug 2006 12:30:46 +0200 Subject: [Fedora-packaging] Do we need a Rule "Docs should be packaged as %doc"? Message-ID: <44D867D6.50708@leemhuis.info> Hi! Subject says it all. Reason for this idea: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199108#c33 Quote: >> > I will prefer not to move docs from /usr/share/gutenprint/doc to >> > /usr/share/doc/gutenprint. >> >> Hmmm, we don't seem to have anything in the guidelines for this AFAICS. But IMHO >> all docs should be marked as %doc and thus should land in >> /usr/share/doc/ (the proper place used by all other >> packages) >> >> Maybe we need to add such a rule :-/ > > Sure if you think like that. Primary looking at package said me that let that > doc files be in /usr/share/gutenprint/doc > Then i check under /usr/share on my system using > find . -name doc * and i got following output > ./sane/xsane/doc > ./cups/doc > ./apps/quanta/doc > ./sgml/docbook/xsl-stylesheets-1.69.1-5/htmlhelp/doc > ./scrollkeeper/doc > ./vim/vim70/doc > ./eclipse/plugins/org.python.pydev_0.9.3/PySrc/ThirdParty/logilab/common/doc > ./eclipse/plugins/org.python.pydev_0.9.3/PySrc/ThirdParty/logilab/pylint/doc > ./pear/doc > ./gutenprint/doc > where some of the entries belongs to Fedora Core packages. > > So it looks to me that either we have different strategy for Fedora Extras or we > have some Guidelines that will require a major changes when a package moves from > Fedora Extras to Fedora Core. Then i would like to see that Guidelines page. CU thl From tibbs at math.uh.edu Tue Aug 8 14:57:43 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 08 Aug 2006 09:57:43 -0500 Subject: [Fedora-packaging] Do we need a Rule "Docs should be packaged as %doc"? In-Reply-To: <44D867D6.50708@leemhuis.info> (Thorsten Leemhuis's message of "Tue, 08 Aug 2006 12:30:46 +0200") References: <44D867D6.50708@leemhuis.info> Message-ID: This can conflict with the absolute rule that the package not depend on any of its documentation for proper operation. This happens with about boxes that read LICENSE, and programs with internal documentation browsers. Also, some files are treated as %doc without needing to be marked as such. So it's not really simple. - J< From tcallawa at redhat.com Tue Aug 8 19:04:24 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 08 Aug 2006 14:04:24 -0500 Subject: [Fedora-packaging] kmdl proposal and kmod flaws In-Reply-To: <20060808092646.GE1475@neu.nirvana> References: <20060808092646.GE1475@neu.nirvana> Message-ID: <1155063864.17183.85.camel@localhost.localdomain> On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote: > I've created a wiki page outlining the kmdl design as well as showing > the flaws of the current kernel module scheme ("kmod"): > > http://fedoraproject.org/wiki/AxelThimm/kmdls Axel, Thank you for taking the time to do this. I honestly think it will be helpful for the Packaging Committee to have this information in front of them. Rather than trying to replace kmod with kmdl, I'd rather look at the key changes that we should consider making. The biggest one, IMHO, is overloading name with the kernel version. I've been one of the staunchest opponents of doing this, because I think its ugly, a hack, and causes problems. With all that said: I now think it is necessary for kernel module packages. I did a lot of thinking and reading over the last several days, and overloading the name works. We know it works, whether done with rpm by hand or via depsolvers (yum). As Axel points out: It makes kernel module packages completely independent across kernels, and within a kernel, the kernel modules are normally updated. I think these things are key. Users expect things to just work without having to worry about doing things differently or special. The reason that third party repositories such as ATrpms have been so successful is because things just work. So, what problems does it cause to overload the name? 1. cvs: No changes necessary. CVS keys off SRPM name, which remains foo-kmod. 2. buildsystem: The buildsystem needs to treat kernel-module packages differently, but we've got the buildsystem code authors on board to help fit the buildsystem to our standards (within reason). Either way, the buildsystem has to detect kernel modules and build them specially, so this is just a different color of paint. Plus, Axel has volunteered to help with this. 3. bugzilla: Bugzilla pulls from owners.list, which bases off SRPM/CVS, so we're fine here. 4. rpm queries: rpm -q kmod-foo doesn't return anything? Say what? Ehh. If you're a power user enough to be querying with rpm on the commandline, you're geek enough to rpm -qa |grep kmod-foo and find it. I now believe that the benefits of overloading the name with kver outweigh any pain it causes, and I propose that we amend the existing kernel module standard to include the version of the kernel in the name field. Here is an updated version of the kmod proposal with kver in the name: http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From skvidal at linux.duke.edu Tue Aug 8 19:07:37 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 08 Aug 2006 15:07:37 -0400 Subject: [Fedora-packaging] kmdl proposal and kmod flaws In-Reply-To: <1155063864.17183.85.camel@localhost.localdomain> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> Message-ID: <1155064057.1941.12.camel@cutter> On Tue, 2006-08-08 at 14:04 -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote: > > I've created a wiki page outlining the kmdl design as well as showing > > the flaws of the current kernel module scheme ("kmod"): > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls > > Axel, > > Thank you for taking the time to do this. I honestly think it will be > helpful for the Packaging Committee to have this information in front of > them. > > Rather than trying to replace kmod with kmdl, I'd rather look at the key > changes that we should consider making. > > The biggest one, IMHO, is overloading name with the kernel version. I've > been one of the staunchest opponents of doing this, because I think its > ugly, a hack, and causes problems. > > With all that said: I now think it is necessary for kernel module > packages. I did a lot of thinking and reading over the last several > days, and overloading the name works. We know it works, whether done > with rpm by hand or via depsolvers (yum). > > As Axel points out: It makes kernel module packages completely > independent across kernels, and within a kernel, the kernel modules are > normally updated. I think these things are key. Users expect things to > just work without having to worry about doing things differently or > special. The reason that third party repositories such as ATrpms have > been so successful is because things just work. > > So, what problems does it cause to overload the name? > > 1. cvs: No changes necessary. CVS keys off SRPM name, which remains > foo-kmod. > > 2. buildsystem: The buildsystem needs to treat kernel-module packages > differently, but we've got the buildsystem code authors on board to help > fit the buildsystem to our standards (within reason). Either way, the > buildsystem has to detect kernel modules and build them specially, so > this is just a different color of paint. Plus, Axel has volunteered to > help with this. > > 3. bugzilla: Bugzilla pulls from owners.list, which bases off SRPM/CVS, > so we're fine here. > > 4. rpm queries: rpm -q kmod-foo doesn't return anything? Say what? Ehh. > If you're a power user enough to be querying with rpm on the > commandline, you're geek enough to rpm -qa |grep kmod-foo and find it. > > I now believe that the benefits of overloading the name with kver > outweigh any pain it causes, and I propose that we amend the existing > kernel module standard to include the version of the kernel in the name > field. > > Here is an updated version of the kmod proposal with kver in the name: > http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName not to make work but it wouldn't be hard. would it be worth making a little script to help users manage kernel modules like they would with rpm? kernel-module-package -q kmod-foo would look through the package lists/provides lists and find out all the installed packages that way? -sv From tcallawa at redhat.com Tue Aug 8 19:15:15 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 08 Aug 2006 14:15:15 -0500 Subject: [Fedora-packaging] kmdl proposal and kmod flaws In-Reply-To: <1155064057.1941.12.camel@cutter> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155064057.1941.12.camel@cutter> Message-ID: <1155064515.17183.86.camel@localhost.localdomain> On Tue, 2006-08-08 at 15:07 -0400, seth vidal wrote: > not to make work but it wouldn't be hard. > > would it be worth making a little script to help users manage kernel > modules like they would with rpm? > > kernel-module-package -q kmod-foo > > would look through the package lists/provides lists and find out all the > installed packages that way? That would be trivial. It could either share code with repoquery or simply call out to it. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From skvidal at linux.duke.edu Tue Aug 8 19:17:42 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 08 Aug 2006 15:17:42 -0400 Subject: [Fedora-packaging] kmdl proposal and kmod flaws In-Reply-To: <1155064515.17183.86.camel@localhost.localdomain> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155064057.1941.12.camel@cutter> <1155064515.17183.86.camel@localhost.localdomain> Message-ID: <1155064662.1941.14.camel@cutter> On Tue, 2006-08-08 at 14:15 -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-08-08 at 15:07 -0400, seth vidal wrote: > > > not to make work but it wouldn't be hard. > > > > would it be worth making a little script to help users manage kernel > > modules like they would with rpm? > > > > kernel-module-package -q kmod-foo > > > > would look through the package lists/provides lists and find out all the > > installed packages that way? > > That would be trivial. It could either share code with repoquery or > simply call out to it. exactly. -sv From toshio at tiki-lounge.com Tue Aug 8 19:31:13 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 08 Aug 2006 12:31:13 -0700 Subject: [Fedora-packaging] Do we need a Rule "Docs should be packaged as %doc"? In-Reply-To: References: <44D867D6.50708@leemhuis.info> Message-ID: <1155065473.2684.30.camel@localhost> On Tue, 2006-08-08 at 09:57 -0500, Jason L Tibbitts III wrote: > This can conflict with the absolute rule that the package not depend > on any of its documentation for proper operation. This happens with > about boxes that read LICENSE, and programs with internal > documentation browsers. The packager would have to check the operation of the program to know which it falls under. If the documentation really is documentation rather than data for the program it should be marked %doc, though. A further question, do docs have to be marked as: %doc example/ Or would this be acceptable: %doc %{_datadir}/[APP]/example I lean towards the former as it makes for a central location to look for local documentation whereas the latter can leave documentation scattered all over the filesystem. > Also, some files are treated as %doc without > needing to be marked as such. > I think this is by pathname, though. So /usr/share/doc/* /usr/man/* /usr/info/* would be automatically marked but /usr/share/[APP]/doc would not. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Tue Aug 8 21:29:08 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 09 Aug 2006 00:29:08 +0300 Subject: [Fedora-packaging] kmdl proposal and kmod flaws In-Reply-To: <1155063864.17183.85.camel@localhost.localdomain> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> Message-ID: <1155072548.2997.172.camel@localhost.localdomain> On Tue, 2006-08-08 at 14:04 -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote: > > I've created a wiki page outlining the kmdl design as well as showing > > the flaws of the current kernel module scheme ("kmod"): > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls One thing completely missing from that is debuginfo packages. The NEVR of the debuginfo package is derived from the name of the *source* package, which means overlaps/unshippability of debuginfo between builds unless 1) the source package's NEVR changes on every rebuild, *including* just rebuilding it for a newer kernel using different rpmbuild flags or whatever, or 2) the module packages implement their own debuginfo package creation. https://bugzilla.redhat.com/113276 > The reason that third party repositories such as ATrpms have > been so successful is because things just work. Things certainly haven't "just work"ed without special user education and making POLA violations a standard practice. Dunno about the current state of affairs with using that scheme, but I've seen the bug reports elsewhere in the past. Before depsolvers are adapted to do "the right thing", their users need to remember to manually pull in module package updates when a new kernel is installed. Granted, with the suggested scheme, they *can* do that without interference from other module packages in more situations than with the current one, ditto with the rpm CLI. > I now believe that the benefits of overloading the name with kver > outweigh any pain it causes I have no doubts that it can be made to work (and there is still some work to do, eg. debuginfo, depsolvers), but I'm still not convinced that it's worth the trouble. But that's moot if consensus says otherwise and there's competent manpower available to do the work. From jjneely at ncsu.edu Tue Aug 8 22:29:41 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Tue, 8 Aug 2006 18:29:41 -0400 Subject: [Fedora-packaging] kmdl proposal and kmod flaws In-Reply-To: <1155072548.2997.172.camel@localhost.localdomain> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> Message-ID: <20060808222941.GB25716@anduril.unity.ncsu.edu> On Wed, Aug 09, 2006 at 12:29:08AM +0300, Ville Skytt? wrote: > On Tue, 2006-08-08 at 14:04 -0500, Tom 'spot' Callaway wrote: > > On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote: > > > I've created a wiki page outlining the kmdl design as well as showing > > > the flaws of the current kernel module scheme ("kmod"): > > > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls > > One thing completely missing from that is debuginfo packages. > > The NEVR of the debuginfo package is derived from the name of the > *source* package, which means overlaps/unshippability of debuginfo > between builds unless 1) the source package's NEVR changes on every > rebuild, *including* just rebuilding it for a newer kernel using > different rpmbuild flags or whatever, or 2) the module packages > implement their own debuginfo package creation. > https://bugzilla.redhat.com/113276 > > > The reason that third party repositories such as ATrpms have > > been so successful is because things just work. > > Things certainly haven't "just work"ed without special user education > and making POLA violations a standard practice. Dunno about the current > state of affairs with using that scheme, but I've seen the bug reports > elsewhere in the past. Before depsolvers are adapted to do "the right > thing", their users need to remember to manually pull in module package > updates when a new kernel is installed. Granted, with the suggested > scheme, they *can* do that without interference from other module > packages in more situations than with the current one, ditto with the > rpm CLI. > > > I now believe that the benefits of overloading the name with kver > > outweigh any pain it causes > > I have no doubts that it can be made to work (and there is still some > work to do, eg. debuginfo, depsolvers), but I'm still not convinced that > it's worth the trouble. But that's moot if consensus says otherwise and > there's competent manpower available to do the work. > I've spent quite a bit of time working on a Yum plugin to add the proper functionality to Yum. In fact I spent part of today adding some features that Thorsten had requested. My goal was to have decent support in FC6 for kernel modules. The freeze is about a month away. I will veto Axel's current plugin as it uses regular expressions to parse the name of the package. I've seen some fun kernel versions and parsing that out of the name is just asking for corner cases. This information needs to be pulled from what the package provides or requires. Most of my hesitation regarding the uname-r in name scheme is because this was fully discussed before and we decided on something different. FESCo ratified it and we were going to be able to support in in FC6 and RHEL 5. There is another important trade off here. Right now up2date/yum/whatever is able to suck down upgraded kernel modules just like upgrades to a new kernel. This works without modifications to the depresolvers because the package name is always the same. With the uname-r in name scheme we are now dependent on some other additional magic to pull down the new kernel modules for the new kernel everyone got 3 days ago. My shop depends on OpenAFS. AFS issues are a complete show stopper. I manage well over 1,300 servers/workstations. Now instead of writing code to make my job easier I have to write code to keep my work load at its current level. Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From Axel.Thimm at ATrpms.net Tue Aug 8 23:21:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 Aug 2006 01:21:11 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <1155072548.2997.172.camel@localhost.localdomain> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> Message-ID: <20060808232111.GC17474@neu.nirvana> On Wed, Aug 09, 2006 at 12:29:08AM +0300, Ville Skytt? wrote: > On Tue, 2006-08-08 at 14:04 -0500, Tom 'spot' Callaway wrote: > > On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote: > > > I've created a wiki page outlining the kmdl design as well as showing > > > the flaws of the current kernel module scheme ("kmod"): > > > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls > > One thing completely missing from that is debuginfo packages. Debuginfo packages are handled in the kmdl scheme, I just didn't outline the details in the wiki to keep the document from growing larger than a packaging comittee member is expected to invest in reading. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 8 23:27:35 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 Aug 2006 01:27:35 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <1155063864.17183.85.camel@localhost.localdomain> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> Message-ID: <20060808232735.GD17474@neu.nirvana> On Tue, Aug 08, 2006 at 02:04:24PM -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote: > > I've created a wiki page outlining the kmdl design as well as showing > > the flaws of the current kernel module scheme ("kmod"): > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls > Thank you for taking the time to do this. I honestly think it will be > helpful for the Packaging Committee to have this information in front of > them. > > Rather than trying to replace kmod with kmdl, I'd rather look at the key > changes that we should consider making. > > The biggest one, IMHO, is overloading name with the kernel version. I've > been one of the staunchest opponents of doing this, because I think its > ugly, a hack, and causes problems. > > With all that said: I now think it is necessary for kernel module > packages. I did a lot of thinking and reading over the last several > days, and overloading the name works. We know it works, whether done > with rpm by hand or via depsolvers (yum). I'm glad I'm getting things rolling finally :) But please consider the following: Changing some key elements like uname-r-in-name and one-specfile you inevitably end very near to kmdl scheme. If these idioms are decided upon to be used in the future it would be a pity to create yet-another-standard if the one existing (kmdl) really covers everything we wish. It's also a scheme in use by ATrpms since quite some time and a vehicle for me to push some kernel modules to FE (provided the legal/quality issues are covered). That having said if something needs improvement in the kmdl scheme I'm open to suggestions. But it would really be a pity to come so close and still have a forked scheme. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 8 23:42:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 Aug 2006 01:42:10 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060808222941.GB25716@anduril.unity.ncsu.edu> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> Message-ID: <20060808234210.GE17474@neu.nirvana> On Tue, Aug 08, 2006 at 06:29:41PM -0400, Jack Neely wrote: > I will veto Axel's current plugin as it uses regular expressions to Let the plugin wars begin ;) > Most of my hesitation regarding the uname-r in name scheme is because > this was fully discussed before and we decided on something different. > FESCo ratified it and we were going to be able to support in in FC6 and > RHEL 5. Decisions can be wrong especially when it affects complex matters that affects only few packages like less than 0.5% of all packages. The important thing is that any decision needs to be reevaluated from time to time and possibly changed. Otherwise you kill development. > There is another important trade off here. Right now > up2date/yum/whatever is able to suck down upgraded kernel modules just > like upgrades to a new kernel. This works without modifications to the > depresolvers because the package name is always the same. No, you forget that this scheme either nukes or conflicts/coinstalls the new modules. Imagine running up2date/yum w/o any kmod-plugin support on RHEL5 and nuking your GFS (or AFS) modules away. You (and your clients) will not be amused. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjneely at ncsu.edu Wed Aug 9 00:06:49 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Tue, 8 Aug 2006 20:06:49 -0400 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060808234210.GE17474@neu.nirvana> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> Message-ID: <20060809000649.GE25716@anduril.unity.ncsu.edu> On Wed, Aug 09, 2006 at 01:42:10AM +0200, Axel Thimm wrote: > On Tue, Aug 08, 2006 at 06:29:41PM -0400, Jack Neely wrote: > > I will veto Axel's current plugin as it uses regular expressions to > > Let the plugin wars begin ;) > > > Most of my hesitation regarding the uname-r in name scheme is because > > this was fully discussed before and we decided on something different. > > FESCo ratified it and we were going to be able to support in in FC6 and > > RHEL 5. > > Decisions can be wrong especially when it affects complex matters that > affects only few packages like less than 0.5% of all packages. The > important thing is that any decision needs to be reevaluated from time > to time and possibly changed. Otherwise you kill development. > > > There is another important trade off here. Right now > > up2date/yum/whatever is able to suck down upgraded kernel modules just > > like upgrades to a new kernel. This works without modifications to the > > depresolvers because the package name is always the same. > > No, you forget that this scheme either nukes or conflicts/coinstalls > the new modules. Imagine running up2date/yum w/o any kmod-plugin > support on RHEL5 and nuking your GFS (or AFS) modules away. You (and > your clients) will not be amused. > -- > Axel.Thimm at ATrpms.net Okay...walk me through this then: Assuming no yum plugins or other mess. A new kernel is available that corrects some random remote DoS. How do I get all 1300 machines to pull down the new AFS modules? More complex: How do I get 1300 machines to download both the new kernel and AFS modules together? Assume that we cannot allow a machine to reboot between getting the new kernel and getting the new AFS modules. (This equals broken for me.) Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From fedora at leemhuis.info Wed Aug 9 04:06:04 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 Aug 2006 06:06:04 +0200 Subject: [Fedora-packaging] kmdl proposal and kmod flaws In-Reply-To: <1155063864.17183.85.camel@localhost.localdomain> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> Message-ID: <44D95F2C.4020806@leemhuis.info> Tom 'spot' Callaway schrieb: > On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote: >> I've created a wiki page outlining the kmdl design as well as showing >> the flaws of the current kernel module scheme ("kmod"): >> http://fedoraproject.org/wiki/AxelThimm/kmdls [...] > So, what problems does it cause to overload the name? > > 1. cvs: No changes necessary. CVS keys off SRPM name, which remains > foo-kmod. > > 2. buildsystem: The buildsystem needs to treat kernel-module packages > differently, but we've got the buildsystem code authors on board to help > fit the buildsystem to our standards (within reason). Either way, the > buildsystem has to detect kernel modules and build them specially, so > this is just a different color of paint. Plus, Axel has volunteered to > help with this. > > 3. bugzilla: Bugzilla pulls from owners.list, which bases off SRPM/CVS, > so we're fine here. > > 4. rpm queries: rpm -q kmod-foo doesn't return anything? Say what? Ehh. > If you're a power user enough to be querying with rpm on the > commandline, you're geek enough to rpm -qa |grep kmod-foo and find it. The most important thing didn't come up in this discussion yet (or I overlooked it): 5. None of the depsolvers will install new kernel-modules for newly installed kernels by default. All need a special plugin that handles that. That's no problem with the current kmod standard. CU thl From toshio at tiki-lounge.com Wed Aug 9 06:48:26 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 08 Aug 2006 23:48:26 -0700 Subject: [Fedora-packaging] Do we need a Rule "Docs should be packaged as %doc"? In-Reply-To: <1155065473.2684.30.camel@localhost> References: <44D867D6.50708@leemhuis.info> <1155065473.2684.30.camel@localhost> Message-ID: <1155106106.2640.13.camel@localhost> On Tue, 2006-08-08 at 12:31 -0700, Toshio Kuratomi wrote: > On Tue, 2006-08-08 at 09:57 -0500, Jason L Tibbitts III wrote: > > This can conflict with the absolute rule that the package not depend > > on any of its documentation for proper operation. This happens with > > about boxes that read LICENSE, and programs with internal > > documentation browsers. > > The packager would have to check the operation of the program to know > which it falls under. If the documentation really is documentation > rather than data for the program it should be marked %doc, though. > > A further question, do docs have to be marked as: > %doc example/ > > Or would this be acceptable: > %doc %{_datadir}/[APP]/example > > I lean towards the former as it makes for a central location to look for > local documentation whereas the latter can leave documentation scattered > all over the filesystem. This just crossed through my INBOX: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201828 The reporter is making a case for putting docs in %{_datadir} based on the behaviour of current packages (lyx). If we think we want any rules around documentation we should put a note in that bug. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Wed Aug 9 07:47:13 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 Aug 2006 09:47:13 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060809000649.GE25716@anduril.unity.ncsu.edu> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> Message-ID: <20060809074713.GB23919@neu.nirvana> On Tue, Aug 08, 2006 at 08:06:49PM -0400, Jack Neely wrote: > On Wed, Aug 09, 2006 at 01:42:10AM +0200, Axel Thimm wrote: > > On Tue, Aug 08, 2006 at 06:29:41PM -0400, Jack Neely wrote: > > > I will veto Axel's current plugin as it uses regular expressions to > > > > Let the plugin wars begin ;) > > > > > Most of my hesitation regarding the uname-r in name scheme is because > > > this was fully discussed before and we decided on something different. > > > FESCo ratified it and we were going to be able to support in in FC6 and > > > RHEL 5. > > > > Decisions can be wrong especially when it affects complex matters that > > affects only few packages like less than 0.5% of all packages. The > > important thing is that any decision needs to be reevaluated from time > > to time and possibly changed. Otherwise you kill development. > > > > > There is another important trade off here. Right now > > > up2date/yum/whatever is able to suck down upgraded kernel modules just > > > like upgrades to a new kernel. This works without modifications to the > > > depresolvers because the package name is always the same. > > > > No, you forget that this scheme either nukes or conflicts/coinstalls > > the new modules. Imagine running up2date/yum w/o any kmod-plugin > > support on RHEL5 and nuking your GFS (or AFS) modules away. You (and > > your clients) will not be amused. > > > Okay...walk me through this then: > > Assuming no yum plugins or other mess. > > A new kernel is available that corrects some random remote DoS. How do > I get all 1300 machines to pull down the new AFS modules? It's in the wiki, but here it comes again: o current kernel module scheme w/o any special depsolver handling: - broken on rpm level, inherits on all depsolvers - Modules of the current kernel get nuked whether you reboot into the new kernel or not - Module upgrades within the same kernel get blocked due to file conflicts - OR module upgrades within the same kernel get coinstalled and module-init-tools can flip a coin to find out what to choose + but the new kernel gets its kernel modules (and only the new kernel ...) o proposed kernel module scheme + old and current kernels remain untouched by new kernels and kernel modules for new kernels + Proper upgrades of kernel modules within a kernel - new kernels don't get associated kmdls coinstalled Now compare and judge for yourself :=) Next thing to consider is whether and how to fix the remaining issues: o current kernel module scheme special handling: - no special handling possible with rpm cli will remain forever broken - needs to both mark kernel module packages as coinstallable (which they are not) and to perform non-rpm comformant depsolving - Is required for all depsolvers and is a MUST otherwise depsolvers reduce your system to ashes o proposed kernel module scheme special handling: + nothing needed for rpm cli + Obviously less than half the code needed than for the current scheme, rather trivial coding, easy maintenance + Is NICE TO HAVE, absence does not break running system Compare again. :=) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 9 07:50:02 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 Aug 2006 09:50:02 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <44D95F2C.4020806@leemhuis.info> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <44D95F2C.4020806@leemhuis.info> Message-ID: <20060809075002.GC23919@neu.nirvana> On Wed, Aug 09, 2006 at 06:06:04AM +0200, Thorsten Leemhuis wrote: > The most important thing didn't come up in this discussion yet (or I > overlooked it): > > 5. None of the depsolvers will install new kernel-modules for newly > installed kernels by default. All need a special plugin that handles that. which was already submitted > That's no problem with the current kmod standard. but this needs a plugin/patch even more to avoid nuking of kernel modules of the running kernel or depsolvers bailing out due to file conflicts or partial kernel module overwrites or non-wanted coinstalltion per kernel. See the wiki and my reply to Jack. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Aug 9 11:32:29 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 09 Aug 2006 06:32:29 -0500 Subject: [Fedora-packaging] Do we need a Rule "Docs should be packaged as %doc"? In-Reply-To: <1155106106.2640.13.camel@localhost> References: <44D867D6.50708@leemhuis.info> <1155065473.2684.30.camel@localhost> <1155106106.2640.13.camel@localhost> Message-ID: <44D9C7CD.506@math.unl.edu> Toshio Kuratomi wrote: > This just crossed through my INBOX: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201828 > > The reporter is making a case for putting docs in %{_datadir} based on > the behaviour of current packages (lyx). If we think we want any rules > around documentation we should put a note in that bug. Per my comment in bugzilla... IMO, it's not (necessarily) wrong to install docs into a non-versioned dir under /usr/share/doc. -- Rex From jjneely at ncsu.edu Wed Aug 9 13:38:54 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Wed, 9 Aug 2006 09:38:54 -0400 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060809074713.GB23919@neu.nirvana> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> Message-ID: <20060809133854.GB32759@anduril.unity.ncsu.edu> > > Okay...walk me through this then: > > > > Assuming no yum plugins or other mess. > > > > A new kernel is available that corrects some random remote DoS. How do > > I get all 1300 machines to pull down the new AFS modules? > > It's in the wiki, but here it comes again: > > o current kernel module scheme w/o any special depsolver handling: > - broken on rpm level, inherits on all depsolvers > - Modules of the current kernel get nuked whether you reboot into > the new kernel or not Wrong. Both up2date and yum have always marked packages that provide 'kernel-modules' as install only for several years now. Modules don't get "nuked" unless you rpm -U. > - Module upgrades within the same kernel get blocked due to file > conflicts > - OR module upgrades within the same kernel get coinstalled and > module-init-tools can flip a coin to find out what to choose Upgrades within the same kernel don't work. This is one point, not multiple. > + but the new kernel gets its kernel modules (and only the new > kernel ...) This point has been used in practice by several large universities. I've been doing this for about 6 years. While not perfect its been proven to be acceptable and allow machines to remain fulled patched. NC State University. Duke. I believe Matt at Boston U. has used this approch in the past as well. > > o proposed kernel module scheme > + old and current kernels remain untouched by new kernels and kernel > modules for new kernels Contrast: The current tools allow this as well. I use up2date. It does not nuke my old kernel modules. > + Proper upgrades of kernel modules within a kernel > - new kernels don't get associated kmdls coinstalled > This is a big problem. Your scheme discurages people from keeping their systems updated. You'd rather have all of my 1300 machines run a swiss cheese kernel from 2003 for RHEL 3. > Now compare and judge for yourself :=) > I did. Its hard enough to get people to keep their kernels upgraded. Your scheme makes it next to impossible without manual touching of all machines. This is not acceptable. > Next thing to consider is whether and how to fix the remaining issues: > > o current kernel module scheme special handling: > - no special handling possible with rpm cli will remain forever > broken And it sucks. I agree here. However, ask who did not make compromises when we developed the current scheme. > - needs to both mark kernel module packages as coinstallable (which > they are not) and to perform non-rpm comformant depsolving The co-installable mark has been in production and tested for 3 years now I beleive. I use the caveat of not issuing an upgrade within a kernel version. Modules act identically to kernel packages themselves. > - Is required for all depsolvers and is a MUST otherwise depsolvers > reduce your system to ashes > I've been doing this with up2date for quite a while and manage to maintain mine. Seth? Matt? > o proposed kernel module scheme special handling: > + nothing needed for rpm cli > + Obviously less than half the code needed than for the current > scheme, rather trivial coding, easy maintenance How much code do we need to support pulling in modules for new kernels? > + Is NICE TO HAVE, absence does not break running system No. Yum/Up2date modifications would be required. Not optional. We must not discurage people from applying security errata. > > Compare again. :=) Jack > -- > Axel.Thimm at ATrpms.net > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From skvidal at linux.duke.edu Wed Aug 9 13:51:42 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 09 Aug 2006 09:51:42 -0400 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060809133854.GB32759@anduril.unity.ncsu.edu> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> Message-ID: <1155131502.9162.1.camel@cutter> > NC State University. Duke. I believe Matt at Boston U. has used this > approch in the past as well. > Agreed. We've been using kernels and kernel-modules in this way for a number of years, now. example: rpm -q --provides openafs-kernel kernel-module-openafs-2.6.9-22.0.2.EL kernel-modules openafs-kernel = 0:1.3.82-7.duke.1.centos4 -sv From Axel.Thimm at ATrpms.net Wed Aug 9 15:13:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 Aug 2006 17:13:08 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060809133854.GB32759@anduril.unity.ncsu.edu> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> Message-ID: <20060809151308.GA5164@neu.nirvana> On Wed, Aug 09, 2006 at 09:38:54AM -0400, Jack Neely wrote: > > > Okay...walk me through this then: > > > > > > Assuming no yum plugins or other mess. > > > > > > A new kernel is available that corrects some random remote DoS. How do > > > I get all 1300 machines to pull down the new AFS modules? > > > > It's in the wiki, but here it comes again: > > > > o current kernel module scheme w/o any special depsolver handling: > > - broken on rpm level, inherits on all depsolvers > > - Modules of the current kernel get nuked whether you reboot into > > the new kernel or not > > Wrong. Both up2date and yum have always marked packages that provide > 'kernel-modules' as install only for several years now. Modules don't > get "nuked" unless you rpm -U. Wrong x 3: o not always, neither yum, not up2date initially had any "kernel-module(s)" support o first implementation had a typo mismatch, kernel-modules vs kernel-module. In fact effectively its a very young approach, I think this was fixed less than a year ago o you asked for "no yum plugins or other mess". Requiring all kernel modules to be initially marked as "always coinstallable" has been proven to be a bug and therefore a "mess". > > - Module upgrades within the same kernel get blocked due to file > > conflicts > > - OR module upgrades within the same kernel get coinstalled and > > module-init-tools can flip a coin to find out what to choose > > Upgrades within the same kernel don't work. This is one point, not > multiple. There is a big capitalized "OR" in the list. Which means that if the current /lib/module//... file paths are kept you are lucky that it's only file conflicts (and "just" an aborted yum update). But if the non-overlapping kabi/whatever file path scheme is adopted you don't have file conflicts, but worse: the modules will get installed and depmod will play oracle on what module to chose. So yes, it's one point with multiple failure paths all of which are ugly. > > + but the new kernel gets its kernel modules (and only the new > > kernel ...) > > This point has been used in practice by several large universities. > I've been doing this for about 6 years. While not perfect its been > proven to be acceptable and allow machines to remain fulled patched. 6 years? So you've been using yum's secret unannounced and NSA sponsored version back then, huh? ;) > NC State University. Duke. I believe Matt at Boston U. has used this > approch in the past as well. And I know large universities that extensively make use of proprietary operating systems, so what exactly does that say? Mass does not imply infallibility. > > + Proper upgrades of kernel modules within a kernel > > - new kernels don't get associated kmdls coinstalled > > This is a big problem. Your scheme discurages people from keeping > their systems updated. You'd rather have all of my 1300 machines > run a swiss cheese kernel from 2003 for RHEL 3. [...] Its hard > enough to get people to keep their kernels upgraded. Your scheme > makes it next to impossible without manual touching of all machines. > This is not acceptable. You asked about "Assuming no yum plugins or other mess", see above. I never suggested using this scheme w/o any support for depsolvers, and I did submit a working yum plugin for this scheme, didn't I? Don't twist my words, please. > The co-installable mark has been in production and tested for 3 years > now I beleive. Well, you need to decide, is it 6, 3 or perhaps less? ... > No. Yum/Up2date modifications would be required. Not optional. We > must not discurage people from applying security errata. Certainly not, then don't ask about academic exersizes on what the behaviour is w/o any special depsolver handling. To remain on the subject since there are other depsolvers out there that know nothing yet about any kernel module scheme: The old scheme will nuke your running kernel modules, there is no way out, and currently for smart to not do so requires a special config entry *per module*!!! Getting back to the real facts: We're interested in a) supporting rpm cli b) supporting yum c) supporting up2date In the old case a) is forever tainted, b) needs a yet uncomplete plugin (you never replied on the review on the requirements on recursive package removal your plugin would have to do) and c) is unclear to me. In the new case a) is already done with, b) needs a plugin that is already finished and c) is unclear, too ;) [Regarding c) I hope that up2date uses yum more and more, so perhaps at RHEL5 time yum plugins will fix this, too]. Nice to have are a) support for apt b) support for smart As said in the old scheme, where you need *both* to mark all packages as coinstallable *and* to undo case-wise this assumption, b) is a big looser when it comes to marking packages as coinstallable. And support for a) for kmdls is trivial and is even shipped with the source tarball (only need to replace "kernel-module-*" matching with "*-kmld-" matching) while for kmods you have the same issues as under yum w/o any plugin. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Wed Aug 9 15:27:11 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 9 Aug 2006 11:27:11 -0400 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060809133854.GB32759@anduril.unity.ncsu.edu> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> Message-ID: <20060809152711.GA29832@jadzia.bu.edu> On Wed, Aug 09, 2006 at 09:38:54AM -0400, Jack Neely wrote: > NC State University. Duke. I believe Matt at Boston U. has used this > approch in the past as well. My current approach is to build a subpackage containing kernel modules for the latest three kernels all bundled together. This is horrible but works fine in our environment. (And, works perfectly fine with buildrequires and makes repeatable builds without passing in special parameters on the build command line.) (If we wanted to have both i586 and i686 kernels, there would be a problem, but we simply don't support i586.) I was working on updating to the Fedora standard, but it's a lot of work and the incentive isn't high. :) I am inclined to believe the only real solution here is to get the in-kernel AFS client up to snuff and abandon the OpenAFS kernel module. I don't know when this will happen, but I think it's easier than solving this problem. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at linux.duke.edu Wed Aug 9 15:29:05 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 09 Aug 2006 11:29:05 -0400 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060809151308.GA5164@neu.nirvana> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> <20060809151308.GA5164@neu.nirvana> Message-ID: <1155137345.9162.6.camel@cutter> On Wed, 2006-08-09 at 17:13 +0200, Axel Thimm wrote: > On Wed, Aug 09, 2006 at 09:38:54AM -0400, Jack Neely wrote: > > > > Okay...walk me through this then: > > > > > > > > Assuming no yum plugins or other mess. > > > > > > > > A new kernel is available that corrects some random remote DoS. How do > > > > I get all 1300 machines to pull down the new AFS modules? > > > > > > It's in the wiki, but here it comes again: > > > > > > o current kernel module scheme w/o any special depsolver handling: > > > - broken on rpm level, inherits on all depsolvers > > > - Modules of the current kernel get nuked whether you reboot into > > > the new kernel or not > > > > Wrong. Both up2date and yum have always marked packages that provide > > 'kernel-modules' as install only for several years now. Modules don't > > get "nuked" unless you rpm -U. > > Wrong x 3: > > o not always, neither yum, not up2date initially had any > "kernel-module(s)" support > o first implementation had a typo mismatch, kernel-modules vs > kernel-module. In fact effectively its a very young approach, I > think this was fixed less than a year ago 2003-11-21 01:24 skvidal * nevral.py: make packages providing 'kernel-modules' installonly. that was yum 2.0.X > > > + but the new kernel gets its kernel modules (and only the new > > > kernel ...) > > > > This point has been used in practice by several large universities. > > I've been doing this for about 6 years. While not perfect its been > > proven to be acceptable and allow machines to remain fulled patched. > > 6 years? So you've been using yum's secret unannounced and NSA > sponsored version back then, huh? ;) > we used the idea in yup prior to yum. That was about 2000->2001, iirc so yes, about 6 years. > > NC State University. Duke. I believe Matt at Boston U. has used > this > > approch in the past as well. > > And I know large universities that extensively make use of proprietary > operating systems, so what exactly does that say? Mass does not imply > infallibility. > I don't think he was alleging that. I think he was saying there are some big users with large installations who have used it and it works. that's all. -sv From Axel.Thimm at ATrpms.net Wed Aug 9 15:45:42 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 Aug 2006 17:45:42 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060809152711.GA29832@jadzia.bu.edu> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> <20060809152711.GA29832@jadzia.bu.edu> Message-ID: <20060809154542.GC5164@neu.nirvana> On Wed, Aug 09, 2006 at 11:27:11AM -0400, Matthew Miller wrote: > On Wed, Aug 09, 2006 at 09:38:54AM -0400, Jack Neely wrote: > > NC State University. Duke. I believe Matt at Boston U. has used this > > approch in the past as well. > > My current approach is to build a subpackage containing kernel modules for > the latest three kernels all bundled together. This is horrible but works > fine in our environment. (And, works perfectly fine with buildrequires and > makes repeatable builds without passing in special parameters on the build > command line.) doesn't this imply that the kernels are also effectively bundled? > (If we wanted to have both i586 and i686 kernels, there would be a problem, > but we simply don't support i586.) :/ > I was working on updating to the Fedora standard, but it's a lot of work and > the incentive isn't high. :) > > I am inclined to believe the only real solution here is to get the in-kernel > AFS client up to snuff and abandon the OpenAFS kernel module. I don't know > when this will happen, but I think it's easier than solving this problem. :) It looks like everyone is only (really) interested in openafs kernel modules. How about http://atrpms.net/name/openafs/ These are openafs kmdls for FC3-FC5 and RHEL4 (FC6 is being worked on). Less than RH9 was abandoned and RHEL3 could be resurrected (there were some issues with x86_64) if there were anyone interested (but I'm running out of licenses and need them for RHEL5). If you have spare boxes and time and like to test you're very welcome! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Wed Aug 9 16:01:58 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 9 Aug 2006 12:01:58 -0400 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060809154542.GC5164@neu.nirvana> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> <20060809152711.GA29832@jadzia.bu.edu> <20060809154542.GC5164@neu.nirvana> Message-ID: <20060809160158.GA32111@jadzia.bu.edu> On Wed, Aug 09, 2006 at 05:45:42PM +0200, Axel Thimm wrote: > > My current approach is to build a subpackage containing kernel modules for > > the latest three kernels all bundled together. This is horrible but works > > fine in our environment. (And, works perfectly fine with buildrequires and > > makes repeatable builds without passing in special parameters on the build > > command line.) > doesn't this imply that the kernels are also effectively bundled? No. There's no dependency tracking going on. It only works because everyone gets updates. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ville.skytta at iki.fi Wed Aug 9 16:20:56 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 09 Aug 2006 19:20:56 +0300 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060808232111.GC17474@neu.nirvana> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808232111.GC17474@neu.nirvana> Message-ID: <1155140456.2997.238.camel@localhost.localdomain> On Wed, 2006-08-09 at 01:21 +0200, Axel Thimm wrote: > On Wed, Aug 09, 2006 at 12:29:08AM +0300, Ville Skytt? wrote: > > On Tue, 2006-08-08 at 14:04 -0500, Tom 'spot' Callaway wrote: > > > On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote: > > > > I've created a wiki page outlining the kmdl design as well as showing > > > > the flaws of the current kernel module scheme ("kmod"): > > > > > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls > > > > One thing completely missing from that is debuginfo packages. > > Debuginfo packages are handled in the kmdl scheme, I just didn't > outline the details in the wiki to keep the document from growing > larger than a packaging comittee member is expected to invest in > reading. Without that information, folks who really want to review the suggestion now need to abort the review due to incompleteness, invest much more time than reading it would take in (re?)inventing how it could be done, or take things for granted. As discussed previously in private mail, if you don't have time to document something, just upload a few example packages built for let's say two successive FC kernels (complete with SRPMS, macro definitions, binaries and debuginfos) somewhere and post a link to that somewhere in public. From Axel.Thimm at ATrpms.net Wed Aug 9 16:34:19 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 Aug 2006 18:34:19 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <1155140456.2997.238.camel@localhost.localdomain> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808232111.GC17474@neu.nirvana> <1155140456.2997.238.camel@localhost.localdomain> Message-ID: <20060809163419.GD5164@neu.nirvana> On Wed, Aug 09, 2006 at 07:20:56PM +0300, Ville Skytt? wrote: > On Wed, 2006-08-09 at 01:21 +0200, Axel Thimm wrote: > > On Wed, Aug 09, 2006 at 12:29:08AM +0300, Ville Skytt? wrote: > > > On Tue, 2006-08-08 at 14:04 -0500, Tom 'spot' Callaway wrote: > > > > On Tue, 2006-08-08 at 11:26 +0200, Axel Thimm wrote: > > > > > I've created a wiki page outlining the kmdl design as well as showing > > > > > the flaws of the current kernel module scheme ("kmod"): > > > > > > > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls > > > > > > One thing completely missing from that is debuginfo packages. > > > > Debuginfo packages are handled in the kmdl scheme, I just didn't > > outline the details in the wiki to keep the document from growing > > larger than a packaging comittee member is expected to invest in > > reading. > > Without that information, folks who really want to review the suggestion > now need to abort the review due to incompleteness, invest much more > time than reading it would take in (re?)inventing how it could be done, > or take things for granted. Until now I'm fighting the uname-r-in-name and one-specfile battles, I really don't want to distract people from these issues until they are done with. To answer your question on debuginfos: You simply change the name of the debuginfo package to match that of the kmdl, e.g. one debuginfo package per kmdl package. > As discussed previously in private mail, if you don't have time to > document something, just upload a few example packages built for let's > say two successive FC kernels (complete with SRPMS, macro definitions, > binaries and debuginfos) somewhere and post a link to that somewhere in > public. You mean like http://ATrpms.net/? The kmdl scheme as proposed is in production there for quite a while. Due to size constraints I don't keep too many kmdls for different kernels around. The currently supported kernels are: fc5/2.6.17-1.2157_1.rhfc5.cubbi_suspend2 \ fc5/2.6.17-1.2157_0.99.rhfc5.cubbi_suspend2_8k \ fc4/2.6.17-1.2142_1.rhfc4.cubbi_swsusp2 \ fc4/2.6.17-1.2142_0.99.rhfc4.cubbi_swsusp2_8k \ el4/2.6.9-34.0.2.EL \ el3/2.4.21-47.EL \ fc6/2.6.17-1.2530.fc6 \ fc5/2.6.17-1.2157_FC5 \ fc4/2.6.17-1.2142_FC4 \ fc3/2.6.12-2.3.legacy_FC3 \ fc2/2.6.10-2.3.legacy_FC2 \ fc1/2.4.22-1.2199.8.legacy.nptl \ rh9/2.4.20-46.9.legacy \ rh7.3/2.4.20-46.7.legacy \ So if you want to compare kernel modules upgradablity you can either pick a module across two releases, or perhaps assume that the swsusp2 kernels are upgrades of the others (technically from rpm's POV they are, that's why they are not shipped in ATrpms "stable", but "testing"). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Aug 9 18:21:40 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 09 Aug 2006 21:21:40 +0300 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <20060809163419.GD5164@neu.nirvana> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808232111.GC17474@neu.nirvana> <1155140456.2997.238.camel@localhost.localdomain> <20060809163419.GD5164@neu.nirvana> Message-ID: <1155147700.2997.252.camel@localhost.localdomain> On Wed, 2006-08-09 at 18:34 +0200, Axel Thimm wrote: > Until now I'm fighting the uname-r-in-name and one-specfile battles, I > really don't want to distract people from these issues until they are > done with. debuginfos are intimately part of that "battle". It's not a distraction, it's required information. > To answer your question on debuginfos: You simply change the name of > the debuginfo package In the specfile? How? Examples? Surely you're not suggesting to just rename the actual debuginfo rpm file on disk after it has been built and be happy? > > As discussed previously in private mail, if you don't have time to > > document something, just upload a few example packages built for let's > > say two successive FC kernels (complete with SRPMS, macro definitions, > > binaries and debuginfos) somewhere and post a link to that somewhere in > > public. > > You mean like http://ATrpms.net/? I have no idea where to find the macro definitions and debuginfo packages for your suggested scheme there. From rdieter at math.unl.edu Wed Aug 9 18:25:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 09 Aug 2006 13:25:08 -0500 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <1155147700.2997.252.camel@localhost.localdomain> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808232111.GC17474@neu.nirvana> <1155140456.2997.238.camel@localhost.localdomain> <20060809163419.GD5164@neu.nirvana> <1155147700.2997.252.camel@localhost.localdomain> Message-ID: <44DA2884.6010207@math.unl.edu> Ville Skytt? wrote: > On Wed, 2006-08-09 at 18:34 +0200, Axel Thimm wrote: > >> Until now I'm fighting the uname-r-in-name and one-specfile battles, I >> really don't want to distract people from these issues until they are >> done with. > > debuginfos are intimately part of that "battle". It's not a > distraction, it's required information. > >> To answer your question on debuginfos: You simply change the name of >> the debuginfo package > > In the specfile? How? Examples? Surely you're not suggesting to just > rename the actual debuginfo rpm file on disk after it has been built and > be happy? I think he is, and stop calling him Surely. (: -- Rex From Axel.Thimm at ATrpms.net Thu Aug 10 01:07:40 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 Aug 2006 03:07:40 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <44DA2884.6010207@math.unl.edu> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808232111.GC17474@neu.nirvana> <1155140456.2997.238.camel@localhost.localdomain> <20060809163419.GD5164@neu.nirvana> <1155147700.2997.252.camel@localhost.localdomain> <44DA2884.6010207@math.unl.edu> Message-ID: <20060810010740.GA15388@neu.nirvana> On Wed, Aug 09, 2006 at 01:25:08PM -0500, Rex Dieter wrote: > Ville Skytt? wrote: > >On Wed, 2006-08-09 at 18:34 +0200, Axel Thimm wrote: > > > >>Until now I'm fighting the uname-r-in-name and one-specfile battles, I > >>really don't want to distract people from these issues until they are > >>done with. > > > >debuginfos are intimately part of that "battle". It's not a > >distraction, it's required information. OK, if you feel that way I'm attaching the requested details below. I hope that this thread doesn't stall into some implementation detail issues. It's rather trivial and really doesn't deserve the attention it receives, but at least I hope that it makes clear that all implementation details have been carefully thought of already or matured in the last three years. So, do you buy it now? :) > >>To answer your question on debuginfos: You simply change the name of > >>the debuginfo package > > > >In the specfile? How? Examples? No, remember that the kmdl scheme is a clean and KISS interface/ implementation design. Furthermore debuginfos are hidden as an implementation detail in conventional packages, too. So starting to add such information to the specfile or the kmdl interface part would be wrong or a hack. It belongs to the implementation part, aka macro definitions. > >Surely you're not suggesting to just rename the actual debuginfo > >rpm file on disk after it has been built and be happy? > > I think he is, and stop calling him Surely. (: Surely is my middle name, but I prefer Axel ;) In fact renaming after the fact would be dirty and would leave traces in the resulting debuginfo package (the internal rpm name would still be the one before renaming). I prefer modding the macros. It's a simple change, but since I don't want to touch the upstream macros (well, I do want to, but rather in the source itself ;), I override the macro with a local copy. No, let's not get distracted about what I have in mind about future redhat-rpm-config contents ... In order to avoid any further inquiries on this rather trivial issue I even diffed the original macro to the one I use to reveal all the magic at once (note again: the macro is overridden, not replaced in the original definition, this is a convenience diff). %kmdl_userland is always 1 unless the package to be built is a kernel specific kernel module (the default for %kmdl_userland is an implementation detail, for FE's buildsystem it would probably be the other way around). So project foo ends up with debuginfos naturally named as foo-debuginfo-1.2.3 foo-kmdl-2.6.20-4.5.6-debuginfo-1.2.3 foo-kmdl-2.6.20-4.5.6smp-debuginfo-1.2.3 foo-kmdl-2.6.20-4.5.6PAE-debuginfo-1.2.3 [...] | +## Note^2: A modified copy to reflect different debuginfo packages for kmdls | +%debuginfoname %(test "%{kmdl_userland}" = 1 && echo debuginfo || echo "-n %{kmdl_name}-debuginfo") | | # Template for debug information sub-package. | # NOTE: This is a copy from rpm to get the ifnarch noarch fix, it can be removed later | %debug_package \ | %ifnarch noarch\ | %global __debug_package 1\ | -%package debuginfo \ | +%package %{debuginfoname} \ | Summary: Debug information for package %{name}\ | Group: Development/Debug\ | -%description debuginfo\ | +%description %{debuginfoname}\ | This package provides debug information for package %{name}.\ | Debug information is useful when developing applications that use this\ | package or when debugging this package.\ | -%files debuginfo -f debugfiles.list\ | +%files %{debuginfoname} -f debugfiles.list\ | %defattr(-,root,root)\ | %endif\ | %{nil} -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Thu Aug 10 03:58:07 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 09 Aug 2006 22:58:07 -0500 Subject: [Fedora-packaging] Missing this week's meetings (again) In-Reply-To: <1154369120.3296.30.camel@localhost.localdomain> References: <1154369120.3296.30.camel@localhost.localdomain> Message-ID: <1155182287.2671.28.camel@localhost.localdomain> Due to the fact that I'll be in a customer meeting on Thursday morning, I'm going to miss both the FESCO and the Packaging meetings. :( Next week, I should be at LinuxWorld, and I'll make sure to hide under the booth and attend via my EVDO Treo (I'm still excited about getting that working with Linux). ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From pmatilai at laiskiainen.org Thu Aug 10 05:08:38 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 10 Aug 2006 08:08:38 +0300 (EEST) Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <1155131502.9162.1.camel@cutter> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> <1155131502.9162.1.camel@cutter> Message-ID: On Wed, 9 Aug 2006, seth vidal wrote: >> NC State University. Duke. I believe Matt at Boston U. has used this >> approch in the past as well. >> > > Agreed. We've been using kernels and kernel-modules in this way for a > number of years, now. > > example: > rpm -q --provides openafs-kernel > kernel-module-openafs-2.6.9-22.0.2.EL > kernel-modules > openafs-kernel = 0:1.3.82-7.duke.1.centos4 Just for the measure, we've been using kernel-module-foo- scheme (basically the old livna.org scheme which is similar to Axels kmdl scheme) very successfully at work for a few years. Been working quite nicely, first with apt and now yum, both with an additional plugin to handle these. Now, I don't really want to take any sides in this, I just want the dang thing to be decided one way or the other so we can move on to refining our plugins, as plugins are required in both schemes to be correctly handled in all cases. From experience I know the unamer-in-name works quite nicely but has it quirks from user POV [1], OTOH the kmod scheme (currently used by livna) also seems to work just fine, at least it hasn't bitten me yet although I haven't used any plugins to handle it. [1] When you can't rely on plugins, eg with plain rpm, one needs to remember to append -`uname -r` to the package name. Our users haven't complained about that, mostly I suppose because they never really see it thanks to plugins. - Panu - From skvidal at linux.duke.edu Thu Aug 10 05:13:38 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 10 Aug 2006 01:13:38 -0400 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> <1155131502.9162.1.camel@cutter> Message-ID: <1155186819.11572.41.camel@cutter> On Thu, 2006-08-10 at 08:08 +0300, Panu Matilainen wrote: > Now, I don't really want to take any sides in this, I just want the dang > thing to be decided one way or the other so we can move on to refining our > plugins, as plugins are required in both schemes to be correctly handled > in all cases. From experience I know the unamer-in-name works quite nicely > but has it quirks from user POV [1], OTOH the kmod scheme (currently used > by livna) also seems to work just fine, at least it hasn't bitten me yet > although I haven't used any plugins to handle it. +1 I was not taking a side in it. I was just explaining about what has worked about the kmod scheme in the past. I'd just like one or the other, ultimately, please, for the love of all that's good and holy. :) -sv From pmatilai at laiskiainen.org Thu Aug 10 05:43:24 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 10 Aug 2006 08:43:24 +0300 (EEST) Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <1155186819.11572.41.camel@cutter> References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> <1155131502.9162.1.camel@cutter> <1155186819.11572.41.camel@cutter> Message-ID: On Thu, 10 Aug 2006, seth vidal wrote: > On Thu, 2006-08-10 at 08:08 +0300, Panu Matilainen wrote: > >> Now, I don't really want to take any sides in this, I just want the dang >> thing to be decided one way or the other so we can move on to refining our >> plugins, as plugins are required in both schemes to be correctly handled >> in all cases. From experience I know the unamer-in-name works quite nicely >> but has it quirks from user POV [1], OTOH the kmod scheme (currently used >> by livna) also seems to work just fine, at least it hasn't bitten me yet >> although I haven't used any plugins to handle it. > > +1 > > I was not taking a side in it. I was just explaining about what has > worked about the kmod scheme in the past. Yup, that's the way at least I read it. > I'd just like one or the other, ultimately, please, for the love of all > that's good and holy. :) Amen! :) - Panu - From fedora at leemhuis.info Thu Aug 10 08:47:12 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 10 Aug 2006 10:47:12 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: References: <20060808092646.GE1475@neu.nirvana> <1155063864.17183.85.camel@localhost.localdomain> <1155072548.2997.172.camel@localhost.localdomain> <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> <1155131502.9162.1.camel@cutter> <1155186819.11572.41.camel@cutter> Message-ID: <44DAF290.4070900@leemhuis.info> Panu Matilainen schrieb: > On Thu, 10 Aug 2006, seth vidal wrote: >> On Thu, 2006-08-10 at 08:08 +0300, Panu Matilainen wrote: >>> Now, I don't really want to take any sides in this, I just want the dang >>> thing to be decided one way or the other so we can move on to >>> refining our >>> plugins, as plugins are required in both schemes to be correctly handled >>> in all cases. From experience I know the unamer-in-name works quite >>> nicely >>> but has it quirks from user POV [1], OTOH the kmod scheme (currently >>> used >>> by livna) also seems to work just fine, at least it hasn't bitten me yet >>> although I haven't used any plugins to handle it. with my livna hat on: the Extras kmod standard we used in FC5 works a lot better out of the box (e.g. without plugins) than the old scheme where we had in FC[1-4] which had the "uname -r" in the name. >> I'd just like one or the other, ultimately, please, for the love of all >> that's good and holy. :) > Amen! :) +1 If we really want to fix the problem that was brought up in this discussion (the "a update might remove old kmods for older kernels") then we IMHO can do that with an adjusted variant of the current kmod-standard together with the kabi stuff and/or with a proper plugin. I currently prefer the solution with the kabi stuff because that solution will have other benefits as well. I can try to outline my thoughts/ideas later (maybe today, but probably on the weekend) in more detail. BTW, do we really want to use the "uname -r" again in times where RHEL will have a kabi which means that the "uname -r" is mostly meaningless? I'd really prefer one solution for both FC and RHEL. CU thl From Axel.Thimm at ATrpms.net Thu Aug 10 09:44:19 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 Aug 2006 11:44:19 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <44DAF290.4070900@leemhuis.info> References: <20060808222941.GB25716@anduril.unity.ncsu.edu> <20060808234210.GE17474@neu.nirvana> <20060809000649.GE25716@anduril.unity.ncsu.edu> <20060809074713.GB23919@neu.nirvana> <20060809133854.GB32759@anduril.unity.ncsu.edu> <1155131502.9162.1.camel@cutter> <1155186819.11572.41.camel@cutter> <44DAF290.4070900@leemhuis.info> Message-ID: <20060810094419.GA25950@neu.nirvana> On Thu, Aug 10, 2006 at 10:47:12AM +0200, Thorsten Leemhuis wrote: > together with the kabi stuff and/or with a proper plugin. > BTW, do we really want to use the "uname -r" again in times where RHEL > will have a kabi which means that the "uname -r" is mostly meaningless? > I'd really prefer one solution for both FC and RHEL. Just to make sure everybody understands about kabi myths and doesn't have expectations that are known to not be fulfilled: o There is never ever going to be an ordered api id like kabi = 1.0 o There is no intention of upstream having a stable api which is a prerequisite for a stable abi, in fact it is considered a feature (less `locate stable_api_nonsense.txt`) o The discussion about recycling old kernel modules using kabi tools means hashing subset information like kabihash(subsystem_abc_def) = 0ed3425d. o The full kabi will be a large set of unorderable hases as above o You don't know from a packging POV which hashes are relevant. And even if you knew you would have to concatenate the relevant parts into the kernel module package's filename o If you consider hashing the hashes into one master (sub-)"kabi" hash item you will - still need the single hashes in the package relations for the kabi recycling mechanism to work at all - end with an unorderable hash At the very best you would replace uname-r with an unorderable hash which no user can associate to his kernel. E.g. with either scheme can you humanly identify that foo-kmdl-0ed3425d-1.2.3-4.i686.rpm (or kmod-foo-1.2.3-4_0ed3425d) can satisfy kabi relationships of kernel-2.6.18-23.0.1.EL5.i686.rpm and kernel-2.6.18-23.0.2.EL5.i686.rpm No, you can't. In a pure RHEL5 world with a really stable kabi (note on passing that this is *not* the case with RHEL4 and for example the wireless extensions update breaking both api and abi) you would end up with dropping the evr of the kernel, e.g. uname -r or kabi, to make any positive packaging use of the kabi scheme. In the world of Fedora Core you will never have the same total kabi hash as the previous kernel, so in this case the discussion is moot anyway. So then you may wonder, were's the kabi stuff going to help at all and why do people invest time to develop it further? It will only help in RHEL5 and similar "enterprise" environments if the kernel packages really keep the set of kabi hashes invariant over the years (and the kabi tools will assist kernel engineering in detecting and avoiding such changes). The benefits lie with the IHV/ISVs, who will be able to invest once in a package (either open or closed source) and never have to rebuild it again for RHEL5 if engineering does its work well. It's of no use to systems that don't firmly commit to a stable kabi/kapi like the upstream kernel itself and Fedora, though. And it will also encourage use of closed source drivers (see stable_api_nonsense.txt for why this is so). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Thu Aug 10 13:30:19 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 10 Aug 2006 15:30:19 +0200 Subject: [Fedora-packaging] Missing IRCs Message-ID: <1155216619.2403.100.camel@mccallum.corsepiu.local> FYI, I am currently moving and busy renovating our new home. Therefore, I'll probably be only able to sporadically attend upcoming Packaging IRCs and will probably miss some of them, at least though end of August. Ralf From Axel.Thimm at ATrpms.net Fri Aug 11 10:58:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 11 Aug 2006 12:58:03 +0200 Subject: [Fedora-packaging] Mail voting on kmdl adoption Message-ID: <20060811105803.GA30245@neu.nirvana> Hi, I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme. a) kernel module scheme needs uname-r-in-name b) kernel module scheme needs one-specfile approach (for both usreland and kernel modules) c) kernel module scheme needs to be kernel agnostic (both version *and* flavour) 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) e) Adoption of kmdl interface scheme as used at ATrpms and outlined on http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive vote on a-d) f) Assignment to kmdl-task force to integrate kmdl support into the buildsystems used by Fedora (myself volunteering). Requires a positive vote on a-e) g) Allow kmdl package submissions to Fedora Core/Extras. Requires a positive vote on a-f) Without voting, but dependent on vote results: Assist in GFS kmdl packaging (altready done at FC4 times, needs to resurface). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Fri Aug 11 20:43:53 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 11 Aug 2006 15:43:53 -0500 Subject: [Fedora-packaging] Mail voting on kmdl adoption In-Reply-To: <20060811105803.GA30245@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> Message-ID: <1155329033.2723.64.camel@localhost.localdomain> On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote: > 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) Rather than vote on these issues as Axel suggests (which we can certainly do), I think that perhaps we should look at a different approach: Just throwing it out here, but I don't really see consensus on this issue. People either like kmod or kmdl, and I think there are definite pros/cons to each approach. My instinct is that if we vote on Axel's items, they will not pass. And I don't think it is because the kmdl standard is broken or outright wrong, I think much of it is due to the fact that so much pain and effort went into making the kmod standard (which works for the majority of cases) that people are honestly unwilling to start over. So, here's the heretical proposition: How about we permit either kmod OR kmdl as an acceptable standard? E.g. Document both, and let the packager choose? I see kernel module packaging as one of the last barriers to bringing in contributions from open source, unencumbered 3rd party repo packages. Given the near religious nature of this debate, maybe a little flexibility (not infinite flexibility) is merited here for the greater good? Thoughts? ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From skvidal at linux.duke.edu Fri Aug 11 20:53:12 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 11 Aug 2006 16:53:12 -0400 Subject: [Fedora-packaging] Mail voting on kmdl adoption In-Reply-To: <1155329033.2723.64.camel@localhost.localdomain> References: <20060811105803.GA30245@neu.nirvana> <1155329033.2723.64.camel@localhost.localdomain> Message-ID: <1155329593.18928.17.camel@cutter> On Fri, 2006-08-11 at 15:43 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote: > > > 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) > > Rather than vote on these issues as Axel suggests (which we can > certainly do), I think that perhaps we should look at a different > approach: > > Just throwing it out here, but I don't really see consensus on this > issue. People either like kmod or kmdl, and I think there are definite > pros/cons to each approach. My instinct is that if we vote on Axel's > items, they will not pass. And I don't think it is because the kmdl > standard is broken or outright wrong, I think much of it is due to the > fact that so much pain and effort went into making the kmod standard > (which works for the majority of cases) that people are honestly > unwilling to start over. > > So, here's the heretical proposition: > > How about we permit either kmod OR kmdl as an acceptable standard? E.g. > Document both, and let the packager choose? > > I see kernel module packaging as one of the last barriers to bringing in > contributions from open source, unencumbered 3rd party repo packages. > Given the near religious nature of this debate, maybe a little > flexibility (not infinite flexibility) is merited here for the greater > good? umm - then we'll need both plugins and it will be near impossible to make sure they play nicely. moreover - if a package switches owners and one likes kmod while the previous one likes kmdl then we're kinda, umm, screwed. the packaging committee should make a choice, go with and then it is done. that's the whole point of the committee. -sv From fedora at leemhuis.info Sat Aug 12 07:01:15 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 12 Aug 2006 09:01:15 +0200 Subject: [Fedora-packaging] Mail voting on kmdl adoption In-Reply-To: <1155329593.18928.17.camel@cutter> References: <20060811105803.GA30245@neu.nirvana> <1155329033.2723.64.camel@localhost.localdomain> <1155329593.18928.17.camel@cutter> Message-ID: <44DD7CBB.3080203@leemhuis.info> seth vidal schrieb: > On Fri, 2006-08-11 at 15:43 -0500, Tom 'spot' Callaway wrote: >> On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote: >> >>> 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) >> Rather than vote on these issues as Axel suggests (which we can >> certainly do), I think that perhaps we should look at a different >> approach: >> >> Just throwing it out here, but I don't really see consensus on this >> issue. People either like kmod or kmdl, and I think there are definite >> pros/cons to each approach. My instinct is that if we vote on Axel's >> items, they will not pass. And I don't think it is because the kmdl >> standard is broken or outright wrong, I think much of it is due to the >> fact that so much pain and effort went into making the kmod standard >> (which works for the majority of cases) that people are honestly >> unwilling to start over. >> >> So, here's the heretical proposition: >> >> How about we permit either kmod OR kmdl as an acceptable standard? E.g. >> Document both, and let the packager choose? >> >> I see kernel module packaging as one of the last barriers to bringing in >> contributions from open source, unencumbered 3rd party repo packages. >> Given the near religious nature of this debate, maybe a little >> flexibility (not infinite flexibility) is merited here for the greater >> good? > > umm - then we'll need both plugins and it will be near impossible to > make sure they play nicely. > moreover - if a package switches owners and one likes kmod while the > previous one likes kmdl then we're kinda, umm, screwed. And we need proper support for both standards in plague. And having two standard is confusing for the users, too. > the packaging committee should make a choice, go with and then it is > done. > > that's the whole point of the committee. +1 Cu thl From pmatilai at laiskiainen.org Sat Aug 12 12:14:23 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 12 Aug 2006 15:14:23 +0300 Subject: [Fedora-packaging] Mail voting on kmdl adoption In-Reply-To: <1155329593.18928.17.camel@cutter> References: <20060811105803.GA30245@neu.nirvana> <1155329033.2723.64.camel@localhost.localdomain> <1155329593.18928.17.camel@cutter> Message-ID: <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> On Fri, 2006-08-11 at 16:53 -0400, seth vidal wrote: > On Fri, 2006-08-11 at 15:43 -0500, Tom 'spot' Callaway wrote: > > On Fri, 2006-08-11 at 12:58 +0200, Axel Thimm wrote: > > > > > 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) > > > > Rather than vote on these issues as Axel suggests (which we can > > certainly do), I think that perhaps we should look at a different > > approach: > > > > Just throwing it out here, but I don't really see consensus on this > > issue. People either like kmod or kmdl, and I think there are definite > > pros/cons to each approach. My instinct is that if we vote on Axel's > > items, they will not pass. And I don't think it is because the kmdl > > standard is broken or outright wrong, I think much of it is due to the > > fact that so much pain and effort went into making the kmod standard > > (which works for the majority of cases) that people are honestly > > unwilling to start over. > > > > So, here's the heretical proposition: > > > > How about we permit either kmod OR kmdl as an acceptable standard? E.g. > > Document both, and let the packager choose? > > > > I see kernel module packaging as one of the last barriers to bringing in > > contributions from open source, unencumbered 3rd party repo packages. > > Given the near religious nature of this debate, maybe a little > > flexibility (not infinite flexibility) is merited here for the greater > > good? > > umm - then we'll need both plugins and it will be near impossible to > make sure they play nicely. > > moreover - if a package switches owners and one likes kmod while the > previous one likes kmdl then we're kinda, umm, screwed. +1 Having both standards mix and match is by far the worst of both worlds IMNSHO. > > the packaging committee should make a choice, go with and then it is > done. > > that's the whole point of the committee. Another +1 Both choices have their weak and strong points. If it's impossible to decide based on technical merits alone... flip a coin or something, really. - Panu - From jkeating at redhat.com Sat Aug 12 13:31:04 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 12 Aug 2006 09:31:04 -0400 Subject: [Fedora-packaging] Mail voting on kmdl adoption In-Reply-To: <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> Message-ID: <200608120931.08171.jkeating@redhat.com> On Saturday 12 August 2006 08:14, Panu Matilainen wrote: > Both choices have their weak and strong points. If it's impossible to > decide based on technical merits alone... flip a coin or something, > really. Or continue to use the current one that is being used by current packages in Extras, and in RHEL. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Aug 12 15:18:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 12 Aug 2006 17:18:08 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <200608120931.08171.jkeating@redhat.com> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> Message-ID: <20060812151808.GB22196@neu.nirvana> On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote: > On Saturday 12 August 2006 08:14, Panu Matilainen wrote: > > Both choices have their weak and strong points. If it's impossible > > to decide based on technical merits alone... flip a coin or > > something, really. > > Or continue to use the current one that is being used by current > packages in Extras, and in RHEL. and which cannot be used for manual rpm installations, breaks all depsolvers, endangers your running setup or the total upgradablity of the system and the ugly workarounds trying to fix this turn out to introduce more bugs that they fix making the depsolver support a maintenance nightmare. Workaround 1: assume rpm -i is in order, add "kernel-modules" coinstall support in yum proper Workaround 2: find out that the coinstall support is not enough, additionally write a plugin Workaround 3: find out that rpm -i isn't the proper mode, try to fix the plugin for yum, despair on rpm Workaround 4: find out that the plugin for yum is still incomplete and possibly cannot be ever fixed. Workaround 5: Impose restrictions on kernel modules and their usage so that unfixable bugs are not triggered [*]. In contrast to well behaved rpm, yum and all other from the very start and a trivial plugin to make yum usage more comfortable not even needeing special "kernel-modules" support? FYI there is exatly 1 (one) package in extras using the kernel module scheme and RHEL is just being taught kmods (GFS) - it's not too late to avoid RHEL5 ship with such a broken scheme unless we decide to discuss this forever. [*] Like - never use rpm cli - never have dependencies of kernel module packages on other packages (breaks GFS/cman/dlm/...) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Aug 12 15:33:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 12 Aug 2006 17:33:10 +0200 Subject: [Fedora-packaging] fedorakmod.py unfixable (was: atrpms kernel modules) In-Reply-To: <20060807145414.GH27561@neu.nirvana> References: <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> Message-ID: <20060812153310.GC22196@neu.nirvana> Hi Jack, can you please answer on the statement below that wrt fedorakmod.py plugin if the wrongly tagged kernel module packages pull in other packages through dependencies you're hosed up? Explenation for the others: That's because the plugin works in such a way that it needs to allow yum to perform the proper transaction setup which includes tagging kernel module packages for installation that should not had been tagged according to the kmod scheme (but that's not yum's fault, yum is just being rpm compatible). So the plugin tries to remove again these packages before the transaction is commited. But it doesn't take into account that these packages may have further dependencies and may have pulled in more packages, which currently is not checked and I doubt that one can ever identify them. Just to name real-world cases where kmdls pull in other kmdls and userland bits where this plugin would fail: GFS/cman/dlm, ivtv/v4ldvb, ipw3495{,d} packages, ipw*/ieee80211. Please make a statement about that as this demonstrates that the plugin has unfixable flaws - which is neither yum's not the plugin's fault, it is just the mirroring of allowing an rpm-incompatible kernel module scheme. I hope the correctness and maintenance issues here will persuade the last kmdl opponent. :) On Mon, Aug 07, 2006 at 04:54:14PM +0200, Axel Thimm wrote: > On Mon, Aug 07, 2006 at 10:00:13AM -0400, Jack Neely wrote: > > > So any raised issue on the naming/versioning of kernel module packages > > > still remains as discussed - including non-rpm conformant behaviour of > > > such packages with the rpm -U/-i nuke/conflict situation, which is still > > > not "fixed" on yum level or any other depsolver's (and having looked > > > into yum's plugin system which is quite nice BTW, I don't know whether > > > it will be "fixable" at all) > > > > If the existing fedorakmod.py plugin in yum-utils does not handle > > installs, upgrades, and co-installs of kmod style kernel modules then > > I'd like a detailed bug report please. > > AFAIU yum's plugin logic in order to perform according to the current > rpm-level-broken kernel module scheme a plugin would have to undo > parts of yum's transaction. E.g. yum does not offer a hook to > manipulate its logic during the depsolving. Note that yum's depsolver > logic is rpm conformant. Therefore the moment the fedorakmod.py takes > over the transaction set may contain both nuking and conflicts which > the plugin needs to address in retrospective now. > > Coinstall support "solves" the first issue, but the second issue is > only "solvable" by removing parts of the transaction. Unfortunately > removing is an operation that needs to get back into the depsolver > logic - unless the package to be removed has no further dependent or > depending on packages. This may be true for most of the current few > available kernel modules in this scheme, but there are others that > have richer depedendency structure - most notably v4l2 and wifi > related modules. > > It doesn't look like the fedorakmod.py plugin takes that into > account. It's still "fixable" by adding even more code, but it's > already gaining code size and therefore maintenance costs for > something that wasn't "broken" to begin with. This also shows that > there may be even more bugs lurking, and this is only the support for > yum, rpm still remains "broken" and so do all the other depsolvers. > > It's nothing against Jack's work or even Thorsten's and Ville's work > on the kernel module specs. It's just a core design element that > proves to be bad and needs replacement asap. > > I know I repeat myself, but: > > There is the kmdl proposal which doesn't even need any special plugins > to remain rpm-compliant for both rpm and all depsolvers and while > support for coinstalls for new kernels is missing in all depsolvers it > proved to be trivial to add a < 100 lines easy to maintain plugin to > accomplish that. So there really is only the I-don't-like-uname-r- > in-name issue left ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Aug 14 13:44:08 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 14 Aug 2006 08:44:08 -0500 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060812151808.GB22196@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> Message-ID: <1155563048.31141.8.camel@localhost.localdomain> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote: > On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote: > > On Saturday 12 August 2006 08:14, Panu Matilainen wrote: > > > Both choices have their weak and strong points. If it's impossible > > > to decide based on technical merits alone... flip a coin or > > > something, really. > > > > Or continue to use the current one that is being used by current > > packages in Extras, and in RHEL. > > and which cannot be used for manual rpm installations, breaks all > depsolvers, endangers your running setup or the total upgradablity of > the system and the ugly workarounds trying to fix this turn out to > introduce more bugs that they fix making the depsolver support a > maintenance nightmare. To be fair, the only change to kmod that would be necessary to remove all of this "it won't work for manual rpm installations" is the addition of kver in the Name field. So far, the only technical reason that I've heard mentioned here against adding kver to Name is that it would make debuginfo more complicated for kmod packages (and I believe that someone posted a workaround method). In fact, I suspect that kmodtool could even include the necessary magic. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From fedora at leemhuis.info Mon Aug 14 14:06:36 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Aug 2006 16:06:36 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155563048.31141.8.camel@localhost.localdomain> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> Message-ID: <44E0836C.4030107@leemhuis.info> Tom 'spot' Callaway schrieb: > On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote: > > So far, the only technical reason that I've heard mentioned here against > adding kver to Name is that it would make debuginfo more complicated for > kmod packages (and I believe that someone posted a workaround method). You forgot the biggest "issue" (note the quotes): All the depsolvers would need special handling to install kmods for newly installed kernels. That works out of the box with the current scheme and IMHO is an important advantage of the current standard. Yes, there exists a yum-plugin already that handles it. But we would need something for up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. > In fact, I suspect that kmodtool could even include the necessary magic. Sure, that would be possible. But we'll hit other problems after this major scheme change. We probably hit some in the old livna days, but I forget most of them already (sorry -- maybe I can skip though bugzilla to fresh up my mind). But I think sticking to the current scheme and solving the "install-conflicts" problem together with the kabi stuff would be the better idea. CU thl From tcallawa at redhat.com Mon Aug 14 14:26:49 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 14 Aug 2006 09:26:49 -0500 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <44E0836C.4030107@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> Message-ID: <1155565609.31141.20.camel@localhost.localdomain> On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote: > > Tom 'spot' Callaway schrieb: > > On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote: > > > > So far, the only technical reason that I've heard mentioned here against > > adding kver to Name is that it would make debuginfo more complicated for > > kmod packages (and I believe that someone posted a workaround method). > > You forgot the biggest "issue" (note the quotes): All the depsolvers > would need special handling to install kmods for newly installed > kernels. That works out of the box with the current scheme and IMHO is > an important advantage of the current standard. Yes, there exists a > yum-plugin already that handles it. But we would need something for > up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. I'm not sure I see how this automatically works in the current kmod scheme (or alternately, how it doesn't work in the kmod+kver scheme). > > In fact, I suspect that kmodtool could even include the necessary magic. > > Sure, that would be possible. But we'll hit other problems after this > major scheme change. We probably hit some in the old livna days, but I > forget most of them already (sorry -- maybe I can skip though bugzilla > to fresh up my mind). But I think sticking to the current scheme and > solving the "install-conflicts" problem together with the kabi stuff > would be the better idea. Again, I tend to defer to people who know more about packaging kernel modules than I do. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From skvidal at linux.duke.edu Mon Aug 14 15:02:35 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 14 Aug 2006 11:02:35 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <44E0836C.4030107@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> Message-ID: <1155567755.565.7.camel@cutter> On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote: > You forgot the biggest "issue" (note the quotes): All the depsolvers > would need special handling to install kmods for newly installed > kernels. That works out of the box with the current scheme and IMHO is > an important advantage of the current standard. Yes, there exists a > yum-plugin already that handles it. But we would need something for > up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. > up2date/rhel5 isn't an issue. rhel5 is basing off of yum - like fedora is. So the plugins available here can be used there, too. -sv From Axel.Thimm at ATrpms.net Mon Aug 14 15:27:44 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 Aug 2006 17:27:44 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155563048.31141.8.camel@localhost.localdomain> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> Message-ID: <20060814152744.GC31585@neu.nirvana> On Mon, Aug 14, 2006 at 08:44:08AM -0500, Tom 'spot' Callaway wrote: > On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote: > > On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote: > > > On Saturday 12 August 2006 08:14, Panu Matilainen wrote: > > > > Both choices have their weak and strong points. If it's impossible > > > > to decide based on technical merits alone... flip a coin or > > > > something, really. > > > > > > Or continue to use the current one that is being used by current > > > packages in Extras, and in RHEL. > > > > and which cannot be used for manual rpm installations, breaks all > > depsolvers, endangers your running setup or the total upgradablity of > > the system and the ugly workarounds trying to fix this turn out to > > introduce more bugs that they fix making the depsolver support a > > maintenance nightmare. > > To be fair, the only change to kmod that would be necessary to remove > all of this "it won't work for manual rpm installations" is the addition > of kver in the Name field. It sounds like it's a minor details, but it's a major design block. If you also agree to one specfile handling for both userland/kernelland you end up at kmdl's versioning with a different name. And since one does throw out the biggest design elements, why not bring in all the other good stuff that kmdls bring with them? Nobody objected to the rest of the benfits only the uname-r-in-name stuff is being discussed. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Aug 14 15:30:48 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Aug 2006 17:30:48 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155567755.565.7.camel@cutter> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> <1155567755.565.7.camel@cutter> Message-ID: <44E09728.1060309@leemhuis.info> seth vidal schrieb: > rhel5 is basing off of yum - like fedora is. So the plugins available > here can be used there, too. Ohh, didn't know that. Interesting. BTW, why isn't jcmasters (the men behind the kabi stuff for RHEL) participating in this discussion? Is he on holiday (i poked hime once via e-mail but I got no response)? I think it's important to get him involved in this discussion. CU thl From Axel.Thimm at ATrpms.net Mon Aug 14 15:33:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 Aug 2006 17:33:10 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <44E0836C.4030107@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> Message-ID: <20060814153310.GD31585@neu.nirvana> On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote: > You forgot the biggest "issue" (note the quotes): All the depsolvers > would need special handling to install kmods for newly installed > kernels. That works out of the box with the current scheme and IMHO is > an important advantage of the current standard. Yes, there exists a > yum-plugin already that handles it. But we would need something for > up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. o the yum-plugin for kmods is broken and possibly cannot be rectified, see mail to Jack o "out of the box" the current scheme is severely broken. In yum you get file conflicts, in rpm total breakage and in smart/apt you get your running kernel modules nuked. You make it sound like the kmdl scheme needs special handling, while it's the other way round. The kmdl scheme does never jeopardize your existing install and this inherits to all depsolvers and rpm. While the kmod scheme violates basic rpm ordering rules and tried to rectify with in-depsolver special handling *and* plugins and has already been shown to be broken by design. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 14 15:35:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 Aug 2006 17:35:27 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060811105803.GA30245@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> Message-ID: <20060814153527.GE31585@neu.nirvana> Just to give the good example. Please do your voting and let's see where we stand. My batteries are running out, repeating the same arguments again and again isn't fun. So let's either do it or drown it. On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote: > Hi, > > I suggest to vote through email about replacing the current kernel > scheme with the kmdl or similar scheme. > > a) kernel module scheme needs uname-r-in-name +1 > b) kernel module scheme needs one-specfile approach (for both usreland > and kernel modules) +1 > c) kernel module scheme needs to be kernel agnostic (both version > *and* flavour) +1 > 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 > e) Adoption of kmdl interface scheme as used at ATrpms and outlined on > http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive > vote on a-d) +1 > f) Assignment to kmdl-task force to integrate kmdl support into the > buildsystems used by Fedora (myself volunteering). Requires a > positive vote on a-e) +1 > g) Allow kmdl package submissions to Fedora Core/Extras. Requires a > positive vote on a-f) +1 > Without voting, but dependent on vote results: Assist in GFS kmdl > packaging (altready done at FC4 times, needs to resurface). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 14 15:41:23 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 Aug 2006 17:41:23 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155567755.565.7.camel@cutter> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> <1155567755.565.7.camel@cutter> Message-ID: <20060814154123.GF31585@neu.nirvana> On Mon, Aug 14, 2006 at 11:02:35AM -0400, seth vidal wrote: > On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote: > > Yes, there exists a yum-plugin already that handles it. But we > > would need something for up2date/RHEL5 too in case the ABI breaks > > -- I suspect that's to late. Just FYI the kernel api/abi between RHEL4U3 and RHEL4U4 broke again at least in the wireless extensions submodule. I don't think that this will be different with RHEL5U --> U updates. > up2date/rhel5 isn't an issue. > > rhel5 is basing off of yum - like fedora is. So the plugins available > here can be used there, too. That's good news. Does that mean that yum has rhn support? I started shipping the kmdl plugin to ATrpms' users, but would prefer it to get into yum-utils as a subpackage. If approved should I send you a patch for CVS and one for the specfile? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Aug 14 15:43:48 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 14 Aug 2006 10:43:48 -0500 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060814153527.GE31585@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <20060814153527.GE31585@neu.nirvana> Message-ID: <44E09A34.7010708@math.unl.edu> Axel Thimm wrote: > Just to give the good example. Please do your voting and let's see > where we stand. My batteries are running out, repeating the same > arguments again and again isn't fun. So let's either do it or drown > it. > > On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote: >> Hi, >> >> I suggest to vote through email about replacing the current kernel >> scheme with the kmdl or similar scheme. I'd have to say that change here is warranted and Axel's proposal(s) make the most sense to me: afaict, a-g all +1 -- Rex From fedora at leemhuis.info Mon Aug 14 16:02:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Aug 2006 18:02:51 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155565609.31141.20.camel@localhost.localdomain> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> <1155565609.31141.20.camel@localhost.localdomain> Message-ID: <44E09EAB.8070101@leemhuis.info> Tom 'spot' Callaway schrieb: > On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote: >> Tom 'spot' Callaway schrieb: >>> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote: >>> >>> So far, the only technical reason that I've heard mentioned here against >>> adding kver to Name is that it would make debuginfo more complicated for >>> kmod packages (and I believe that someone posted a workaround method). >> You forgot the biggest "issue" (note the quotes): All the depsolvers >> would need special handling to install kmods for newly installed >> kernels. That works out of the box with the current scheme and IMHO is >> an important advantage of the current standard. Yes, there exists a >> yum-plugin already that handles it. But we would need something for >> up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. > > I'm not sure I see how this automatically works in the current kmod > scheme Example (without a special plugin): --- Installed are: kernel-2.6.17-1.2157_FC5 kmod-foo-1.2.2.6.17-1.2157_FC5 kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed to the repo Yum will install: kernel-2.6.17-1.2171_FC5 kmod-foo-1.2.2.6.17-1.2171_FC5 --- (or alternately, how it doesn't work in the kmod+kver scheme). Example (without a special plugin): --- Installed are: kernel-2.6.17-1.2157_FC5 kmod-foo-2.6.17-1.2157_FC5-1.2 kernel-2.6.17-1.2171_FC5 and kmod-foo-2.6.17-1.2171_FC5-1.2 are pushed to the repo Yum will install: kernel-2.6.17-1.2171_FC5 kmod-foo-2.6.17-1.2171_FC5-1.2 won't get installed because it a new package for yum whit a different name --- >>> In fact, I suspect that kmodtool could even include the necessary magic. >> Sure, that would be possible. But we'll hit other problems after this >> major scheme change. We probably hit some in the old livna days, but I >> forget most of them already (sorry -- maybe I can skip though bugzilla >> to fresh up my mind). But I think sticking to the current scheme and >> solving the "install-conflicts" problem together with the kabi stuff >> would be the better idea. > > Again, I tend to defer to people who know more about packaging kernel > modules than I do. I'll outline my idea in a more detailed mail I'll start preparing now. CU thl From fedora at leemhuis.info Mon Aug 14 16:10:15 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Aug 2006 18:10:15 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <44E09A34.7010708@math.unl.edu> References: <20060811105803.GA30245@neu.nirvana> <20060814153527.GE31585@neu.nirvana> <44E09A34.7010708@math.unl.edu> Message-ID: <44E0A067.9010209@leemhuis.info> Rex Dieter schrieb: > Axel Thimm wrote: >> On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote: >>> I suggest to vote through email about replacing the current kernel >>> scheme with the kmdl or similar scheme. > > I'd have to say that change here is warranted and Axel's proposal(s) > make the most sense to me: > afaict, a-g all +1 Rex, could you please describe why you think this scheme it better? I'm fine with changing details (I'm still unsure if the uname -r in NAME is a good thing or bad), but why throw everything over board that was developed, discussed and agreed on by the old FESCo? Are there any problems you're seeing with the current scheme? CU thl From rdieter at math.unl.edu Mon Aug 14 16:14:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 14 Aug 2006 11:14:50 -0500 Subject: [Fedora-packaging] Re: Re: Mail voting on kmdl adoption References: <20060811105803.GA30245@neu.nirvana> <20060814153527.GE31585@neu.nirvana> <44E09A34.7010708@math.unl.edu> <44E0A067.9010209@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > > > Rex Dieter schrieb: >> Axel Thimm wrote: >>> On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote: >>>> I suggest to vote through email about replacing the current kernel >>>> scheme with the kmdl or similar scheme. >> >> I'd have to say that change here is warranted and Axel's proposal(s) >> make the most sense to me: >> afaict, a-g all +1 > > Rex, could you please describe why you think this scheme it better? I *could* just parrot Axel's previous empteen mails on the subject... (: In short, I found myself agreeing with his analysis of the shortcomings of the current kmod scheme and advantages of his kmdl proposal. -- Rex From fedora at leemhuis.info Mon Aug 14 16:43:45 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Aug 2006 18:43:45 +0200 Subject: [Fedora-packaging] Mail voting on kmdl adoption In-Reply-To: <20060811105803.GA30245@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> Message-ID: <44E0A841.6050706@leemhuis.info> 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 From Axel.Thimm at ATrpms.net Mon Aug 14 16:56:15 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 Aug 2006 18:56:15 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <44E0A841.6050706@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> Message-ID: <20060814165615.GA2908@neu.nirvana> 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. 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. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 14 17:19:32 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Aug 2006 13:19:32 -0400 Subject: [Fedora-packaging] Mail voting on kmdl adoption In-Reply-To: <20060811105803.GA30245@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> Message-ID: <200608141319.32916.jkeating@redhat.com> On Friday 11 August 2006 06:58, Axel Thimm wrote: > I suggest to vote through email about replacing the current kernel > scheme with the kmdl or similar scheme. Perhaps I'm dumb, but after reading your wiki page I'm still not seeing where the current scheme really falls over. We have kmod packages treated like kernel packages in that they are install rather than upgrade. This is the same way that the kernel is handled, and if people do silly things with the rpm command line they can break their kernel just as easily as they can break their kernel modules. We have this handling in yum, which is the basis of every depsolver we support in Fedora / Red Hat. Yum is used by pup, puplet, pirut, and anaconda. All of these make use of the special casing we have in Yum and handle kmods correctly by installing rather than upgrading them. If other depsolvers don't, well that's really too bad and its up to those depsolvers to handle the packages correctly like they (should) handle kernel packages correctly. So, I guess I'm being dumb, and I need it spelled out in big foam letters as I'm just not getting it, and thus I can't vote on it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Aug 14 17:41:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Aug 2006 19:41:40 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060814165615.GA2908@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> Message-ID: <44E0B5D4.1030806@leemhuis.info> Axel Thimm schrieb: > 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 Sorry, "0" meant undecided for me. >> -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. "--verbose" please, seems I missed something here. I prefer to have the same stuff in RHEL and Fedora -- even if it of small use in Fedora. >> - 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??? Well, kmod packages in my experience need some updates now and then (e.g. special patches for a new kernel version). I prefer to save our users the download of a new userland package in that case. That by itself of course doesn't warrent the split. But together with the two other reasons I gave I think it's okay. (Note, I didn't like the split in the beginning when we created the current kmod standard. I really like it now that I got used to it). >> - 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. You mean https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html ? That stuff is what I meant with: --- [...] -- created manually; we tried that during the development of the kmod standard. We didn't like it [...] --- in my mail you replied to. >>> 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. Well, you would have to hardcode it also until the buildsys gains proper support for your scheme. The guidelines ever state that is an interim solution: # stuff to be implemented externally: [...] # hardcode for now: [...] >>> 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 "in your opinion" is missing here. Or I lost track completely here. Yes, there is the problem described in https://www.redhat.com/archives/fedora-packaging/2006-August/msg00079.htmlis But switching to a total different solution is not the only way to fix this. Further: I got not only one bug report due to this. I got many report due to problems when we had the "uname -r" in the name. If I'm missing other real "problems" please enlight me. tia! >, 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. The kmod scheme works fine in lvn for FC5, too. That's not years. But we had years with problems with the other scheme that used to have "uname -r" in the name. > And please consider that you are endorsing a standard for RHEL I do -- that's why I'm proposing a solution based on the current one that works on both FC and 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. GFS2 is in the Fedoras main kernel package for some time now. See http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?view=markup for details. I suspect that will be the case for RHEL, too. CU thl From fedora at leemhuis.info Mon Aug 14 18:06:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Aug 2006 20:06:51 +0200 Subject: [Fedora-packaging] get further rid of uname -r in the kmod stuff and solve the remaining kmod problem Message-ID: <44E0BBBB.4070103@leemhuis.info> Hi! As promised two hours ago a solution to solve the remaining problem with the current kmod standard. == Problem == So the *only* (*1) remaining problem of the current kmod standard IMHO and AFAICS is this case: Installed are: kernel-2.6.17-1.2157_FC5 kmod-foo-1.2.2.6.17-1.2157_FC5 kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed to the repo Yum will install: kernel-2.6.17-1.2171_FC5 kmod-foo-1.2.2.6.17-1.2171_FC5 kmod-foo-1.3.2.6.17-1.2171_FC5 is pushed to the repo Yum will install: kmod-foo-1.3.2.6.17-1.2171_FC5 *and remove* kmod-foo-1.2.2.6.17-1.2157_FC5 kmod-foo-1.2.2.6.17-1.2171_FC5 in the same transaction because the module location of kmod-foo-1.2.2.6.17-1.2171_FC5 and kmod-foo-1.3.2.6.17-1.2171_FC5 would conflict. *This remove is the problem Axel complains about.* Okay. This can be solved by having "uname -r" in the name and removing the "Provides: kernel-module". But this creates other problems, e.g. at least - "new kernel-modules don't get installed without sepcial plugin" - "uname -r is meaningless with the kabi stuff in RHEL". A special yum-plugin could handle this two, but I prefer a different solution. (*1) -- if I missed anything please tell me == Proposed solution == Install the kernel-module to /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko and remove the "Requires: kernel- Details: We avoid the file conflicts noted in "Problem" above due to the "VERSION-RELEASE" in the path. So yum will always install the module and there won't be any conflicts. But how will the kernel find the module there? "/sbin/weak-modules", the script from the kabi stuff can create links to the proper places. It does this already for modules installed in the proper place and kernels that have the compatible kabi. It would be needed to adjust some pathnames in the script, but that shouldn't be to hard. And why remove the Requires? Well, with the kabi stuff it might happen (not that often in Fedora, but on RHEL often) that a module runs fine on a newer kernel. We wouldn't have to build a new module in that case. *But* this requires would fire back because the kmod will get removed by the depsolver when the kernel is was build for gets uninstalled. Therefor it needs to be removed. == Remaining problem == When do old kmods get removed from the system? Yes, that's a remaining problem (that's why it's listed here (-; ). I'll talk to jcmasters and jeremy and will work out a solution if we agree to work further on this idea. I'm sure we'll find a solution. The installonlyn-plugin maybe could handle that together with the kabi stuff. weak-modules could mark a installed module as unused and the plugin (or another plugin) could remove it later. == EOF == CU thl From Axel.Thimm at ATrpms.net Mon Aug 14 18:05:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 Aug 2006 20:05:11 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <44E0B5D4.1030806@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> <44E0B5D4.1030806@leemhuis.info> Message-ID: <20060814180511.GB2908@neu.nirvana> On Mon, Aug 14, 2006 at 07:41:40PM +0200, Thorsten Leemhuis wrote: > >> -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. > > "--verbose" please, seems I missed something here. Then please check the archives it was after all an answer to a mail from you. Alternatively please outline what you suppose any kabi stuff will bring in other than a further delay? > I prefer to have the same stuff in RHEL and Fedora -- even if it of > small use in Fedora. I agree and ATrpms ships kmdls for RHEL3 and RHEL4 since years, too. Part of kmdl's design is so that RHEL3 is supported, too. So RHEL is not an issue with kmdls, more an argument in favour of them. > >> - 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??? > > Well, kmod packages in my experience need some updates now and then > (e.g. special patches for a new kernel version). I prefer to save our > users the download of a new userland package in that case. > > That by itself of course doesn't warrent the split. But together with > the two other reasons I gave I think it's okay. Which were debunked, too. And please add the confusion of users when say nvidia does not work. File a bug against kmdo-nvidia or nvidia? Check changelogs of which package for what change? > >> - 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. > > You mean > https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html > ? That stuff is what I meant with: > --- > [...] > -- created manually; we tried that during the development of the kmod > standard. We didn't like it > [...] > --- > in my mail you replied to. What is manual about it? It works fully transparently in the background like the usual debuginfo stuff does. There are no manual actions required or manual entries in specfiles. You don't even need to patch up redhat-rpm-macros. It can't be more automatic ... > >> 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 > > "in your opinion" is missing here. Or I lost track completely here. Everything is in my opinion of course, even that 2+2=4. Still the current scheme factually remains broken whether it's my opinion or not. > But switching to a total different solution is not the only way to fix > this. I showed inductively that uname-r-in-name is a neccessity. The other way is to patch up rpm to use a new rpmvercmp. Not ever going to happen IMO. The way you seem to prefer is to live with broken rpm semantics and try to cover up with plugins that try to save the day for yum but abandon rpm broken and only cover our eyes with dirt that yum is working. > Further: I got not only one bug report due to this. Lack of usage? Lack of updated packages? yum dependency calculation abort (wrongly) attributed to something else? User totally confused on the cause of havoc attributing it to his usage? You know when and *that* it triggers inevitably. You don't need bug reports for something proven to be the case. I neither have seen any bug reports on rm -fr / being bad ... > > And please consider that you are endorsing a standard for RHEL > > I do -- that's why I'm proposing a solution based on the current one > that works on both FC and 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. > > GFS2 is in the Fedoras main kernel package for some time now. See > http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel-2.6.spec?view=markup > for details. I suspect that will be the case for RHEL, too. Who said GFS2? GFS is "GFS1" introduced in RHEL3 and supported in RHEL4 and RHEL5, it denotes an online format as contrasted to actual GFS versioning (like 6.0 and 6.1). GFS will continue to live outside the kernel package and is required to support every productive GFS setup out there. There are no GFS2 productive setups to date (because there is no enterprise supported solution for GFS2 yet released, RHEL5 possibly layered would be the first) So it remains the current hertiage is a broken GFS setup for RHEL. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 14 18:16:13 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 Aug 2006 20:16:13 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <200608141319.32916.jkeating@redhat.com> References: <20060811105803.GA30245@neu.nirvana> <200608141319.32916.jkeating@redhat.com> Message-ID: <20060814181613.GC2908@neu.nirvana> On Mon, Aug 14, 2006 at 01:19:32PM -0400, Jesse Keating wrote: > On Friday 11 August 2006 06:58, Axel Thimm wrote: > > I suggest to vote through email about replacing the current kernel > > scheme with the kmdl or similar scheme. > > Perhaps I'm dumb, but after reading your wiki page I'm still not seeing where > the current scheme really falls over. We have kmod packages treated like > kernel packages in that they are install rather than upgrade. This is the > same way that the kernel is handled, and if people do silly things with the > rpm command line they can break their kernel just as easily as they can break > their kernel modules. No, the issue is that kernel modules packages are neither to be "coinstalled", nor to be "upgraded" if the package entity is not disambiguated w/ uname-r-in-name I've give such an exmaple before, try writing down an rpm command for the following situation: Installed: kernel-a module-2-for-a kernel-b module-1-for-b Now try to install module-2-for-b. For kmdls it's just rpm -U. For kmods it's impossible, you need to coinstall with module-2-for-a but upgrade module-1-for-b. That's why every depsolver suddenly needs a plugin to do anything at all with kmods. The plugin needs to take this awkward situation in account and undo things that yum considered sane to do (but yum was only following rpm logic). But the argument goes on that once you pull in a package "by mistake" you cannot undo it unless it is trivial e.g. has no further package depedencies like requires/obsoletes/conflict. These cascade further changes in yum's dependency resolver and undoing them in a plugin effectivly lead to redesigning yum in the plugin. Currently the plugin assumes that is not the case, which is the case with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will fail in these cases. And any plugin for any other depsolver will fail the same and rpm doesn't have plugins. The net result is a half-working yum, borken rpm, broken smart etc. In comtrast if the scheme respects rpm rules like the kmdl scheme does you don't need to undo yum's work, just add the coinstall support. It turns out that the plugin for kmdls was less than half the current plugin for kmods which performs less and is still broken as outlined above. > We have this handling in yum, which is the basis of every depsolver > we support in Fedora / Red Hat. Yum is used by pup, puplet, pirut, > and anaconda. All of these make use of the special casing we have > in Yum and handle kmods correctly by installing rather than > upgrading them. Thanks for the list. This means all of them are currently broken as outlined. And all of them can be fixed by following basic rpm rules like the kmdls do. The key point here is uname-r-in-name. > If other depsolvers don't, well that's really too bad and its up to > those depsolvers to handle the packages correctly like they (should) > handle kernel packages correctly. I agree, if rpm and yum/pup/etc *could* deal with it, but they don't. > So, I guess I'm being dumb, and I need it spelled out in big foam > letters as I'm just not getting it, and thus I can't vote on it. Is the example above & argumentation clear? If yes, and the wiki is not please suggest where to inject an example or soem more working in the wiki. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 14 18:23:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Aug 2006 14:23:42 -0400 Subject: [Fedora-packaging] get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <44E0BBBB.4070103@leemhuis.info> References: <44E0BBBB.4070103@leemhuis.info> Message-ID: <200608141423.46910.jkeating@redhat.com> On Monday 14 August 2006 14:06, Thorsten Leemhuis wrote: > Yum will install: > ?kmod-foo-1.3.2.6.17-1.2171_FC5 > *and remove* > ?kmod-foo-1.2.2.6.17-1.2157_FC5 > ?kmod-foo-1.2.2.6.17-1.2171_FC5 > in the same transaction because the module location of > kmod-foo-1.2.2.6.17-1.2171_FC5 and kmod-foo-1.3.2.6.17-1.2171_FC5 would > conflict. *This remove is the problem Axel complains about.* I could see it removing kmod-foo-1.2.2.6.17-1.2171_FC5, but why does it also remove kmod-foo-1.2.2.6.17-1.2157_FC5? Wouldn't that be in a different module tree? > == Proposed solution == > > Install the kernel-module to > > /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko > > and remove the > > "Requires: kernel- > > Details: > > We avoid the file conflicts noted in "Problem" above due to the > "VERSION-RELEASE" in the path. So yum will always install the module and > there won't be any conflicts. > > But how will the kernel find the module there? "/sbin/weak-modules", the > script from the kabi stuff can create links to the proper places. It > does this already for modules installed in the proper place and kernels > that have the compatible kabi. It would be needed to adjust some > pathnames in the script, but that shouldn't be to hard. > > And why remove the Requires? Well, with the kabi stuff it might happen > (not that often in Fedora, but on RHEL often) that a module runs fine on > a newer kernel. We wouldn't have to build a new module in that case. > *But* this requires would fire back because the kmod will get removed by > the depsolver when the kernel is was build for gets uninstalled. > Therefor it needs to be removed. Also, with the kabi stuff, the Requires should get done automatically to an ABI version. If the next kernel has an ABI change, and you rebuild the module, thats cool, it picks up the new ABI in the automatic Requires. No manual intervention. I would _really_ like to get JCM involved in this discussion, especially on the proper place to drop these modules so that a respin for one kernel won't remove modules from an older kernel. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 14 18:31:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Aug 2006 14:31:41 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060814181613.GC2908@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <200608141319.32916.jkeating@redhat.com> <20060814181613.GC2908@neu.nirvana> Message-ID: <200608141431.41597.jkeating@redhat.com> On Monday 14 August 2006 14:16, Axel Thimm wrote: > No, the issue is that kernel modules packages are neither to be > "coinstalled", nor to be "upgraded" if the package entity is not > disambiguated w/ uname-r-in-name > > I've give such an exmaple before, try writing down an rpm command for > the following situation: > > Installed: > > kernel-a > module-2-for-a > > kernel-b > module-1-for-b > > Now try to install module-2-for-b. For kmdls it's just rpm -U. For > kmods it's impossible, you need to coinstall with module-2-for-a but > upgrade module-1-for-b. > > That's why every depsolver suddenly needs a plugin to do anything at > all with kmods. The plugin needs to take this awkward situation in > account and undo things that yum considered sane to do (but yum was > only following rpm logic). Seems to me that we're really trying to beat around a deficiency in RPM. Creating whole new packages for every single kernel release is insane. New cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our entire infrastructure is based around the name of a package. Changing that for every single kernel update, or special casing it in every system is just silly. REALLY silly. I will absolutely vote against it. > But the argument goes on that once you pull in a package "by mistake" > you cannot undo it unless it is trivial e.g. has no further package > depedencies like requires/obsoletes/conflict. These cascade further > changes in yum's dependency resolver and undoing them in a plugin > effectivly lead to redesigning yum in the plugin. > > Currently the plugin assumes that is not the case, which is the case > with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will > fail in these cases. I have read these two paragraphs 5 times, and I still don't understand what you are saying. Examples work wonders. I'm lost in hyperbole land. > And any plugin for any other depsolver will fail the same and rpm > doesn't have plugins. The net result is a half-working yum, borken > rpm, broken smart etc. > > In comtrast if the scheme respects rpm rules like the kmdl scheme does > you don't need to undo yum's work, just add the coinstall support. It > turns out that the plugin for kmdls was less than half the current > plugin for kmods which performs less and is still broken as outlined > above. You're working around an issue in rpm by creating new packages all the time. That's not a solution, that's an ugly hack. > > We have this handling in yum, which is the basis of every depsolver > > we support in Fedora / Red Hat. ?Yum is used by pup, puplet, pirut, > > and anaconda. ?All of these make use of the special casing we have > > in Yum and handle kmods correctly by installing rather than > > upgrading them. > > Thanks for the list. This means all of them are currently broken as > outlined. And all of them can be fixed by following basic rpm rules > like the kmdls do. The key point here is uname-r-in-name. Or, instead of introducing the insanity of uname-r in name, we can put effort into adjusting rpm and yum to handle this sort of package situation correctly. > > If other depsolvers don't, well that's really too bad and its up to > > those depsolvers to handle the packages correctly like they (should) > > handle kernel packages correctly. > > I agree, if rpm and yum/pup/etc *could* deal with it, but they don't. > > > So, I guess I'm being dumb, and I need it spelled out in big foam > > letters as I'm just not getting it, and thus I can't vote on it. > > Is the example above & argumentation clear? If yes, and the wiki is > not please suggest where to inject an example or soem more working in > the wiki. Thanks, I've heard enough to make up my mind. -1 on the entire thing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at laiskiainen.org Mon Aug 14 18:41:03 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 14 Aug 2006 21:41:03 +0300 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <200608141431.41597.jkeating@redhat.com> References: <20060811105803.GA30245@neu.nirvana> <200608141319.32916.jkeating@redhat.com> <20060814181613.GC2908@neu.nirvana> <200608141431.41597.jkeating@redhat.com> Message-ID: <1155580863.32581.21.camel@weasel.turre.laiskiainen.org> On Mon, 2006-08-14 at 14:31 -0400, Jesse Keating wrote: > On Monday 14 August 2006 14:16, Axel Thimm wrote: > > No, the issue is that kernel modules packages are neither to be > > "coinstalled", nor to be "upgraded" if the package entity is not > > disambiguated w/ uname-r-in-name > > > > I've give such an exmaple before, try writing down an rpm command for > > the following situation: > > > > Installed: > > > > kernel-a > > module-2-for-a > > > > kernel-b > > module-1-for-b > > > > Now try to install module-2-for-b. For kmdls it's just rpm -U. For > > kmods it's impossible, you need to coinstall with module-2-for-a but > > upgrade module-1-for-b. > > > > That's why every depsolver suddenly needs a plugin to do anything at > > all with kmods. The plugin needs to take this awkward situation in > > account and undo things that yum considered sane to do (but yum was > > only following rpm logic). > > Seems to me that we're really trying to beat around a deficiency in RPM. > Creating whole new packages for every single kernel release is insane. New > cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our > entire infrastructure is based around the name of a package. Changing that > for every single kernel update, or special casing it in every system is just > silly. REALLY silly. I will absolutely vote against it. The entire infrastructure is based around the name of the SOURCE package which remains the same with kmdls just like with kmods, normal subpackage splits etc. - Panu - From fedora at leemhuis.info Mon Aug 14 18:47:18 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Aug 2006 20:47:18 +0200 Subject: [Fedora-packaging] get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <200608141423.46910.jkeating@redhat.com> References: <44E0BBBB.4070103@leemhuis.info> <200608141423.46910.jkeating@redhat.com> Message-ID: <44E0C536.8070000@leemhuis.info> Jesse Keating schrieb: > On Monday 14 August 2006 14:06, Thorsten Leemhuis wrote: >> Yum will install: >> kmod-foo-1.3.2.6.17-1.2171_FC5 >> *and remove* >> kmod-foo-1.2.2.6.17-1.2157_FC5 >> kmod-foo-1.2.2.6.17-1.2171_FC5 >> in the same transaction because the module location of >> kmod-foo-1.2.2.6.17-1.2171_FC5 and kmod-foo-1.3.2.6.17-1.2171_FC5 would >> conflict. *This remove is the problem Axel complains about.* > I could see it removing kmod-foo-1.2.2.6.17-1.2171_FC5, but why does it also > remove kmod-foo-1.2.2.6.17-1.2157_FC5? Wouldn't that be in a different > module tree? Well, normally it's a "install transaction" but when there is a potential file conflict it's changed to a "upgrade transaction" afaik -- and that will remove the old kmod as well because both old kmods have the same packagename. >> == Proposed solution == >> >> Install the kernel-module to >> >> /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko >> >> and remove the >> >> "Requires: kernel- >> >> Details: >> >> We avoid the file conflicts noted in "Problem" above due to the >> "VERSION-RELEASE" in the path. So yum will always install the module and >> there won't be any conflicts. >> >> But how will the kernel find the module there? "/sbin/weak-modules", the >> script from the kabi stuff can create links to the proper places. It >> does this already for modules installed in the proper place and kernels >> that have the compatible kabi. It would be needed to adjust some >> pathnames in the script, but that shouldn't be to hard. >> >> And why remove the Requires? Well, with the kabi stuff it might happen >> (not that often in Fedora, but on RHEL often) that a module runs fine on >> a newer kernel. We wouldn't have to build a new module in that case. >> *But* this requires would fire back because the kmod will get removed by >> the depsolver when the kernel is was build for gets uninstalled. >> Therefor it needs to be removed. > > Also, with the kabi stuff, the Requires should get done automatically to an > ABI version. If the next kernel has an ABI change, and you rebuild the > module, thats cool, it picks up the new ABI in the automatic Requires. No > manual intervention. That would solve the problem nicely. > I would _really_ like to get JCM involved in this discussion, especially on > the proper place to drop these modules so that a respin for one kernel won't > remove modules from an older kernel. +1 CU thl /me going to bed now soon From pmatilai at laiskiainen.org Mon Aug 14 18:46:39 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 14 Aug 2006 21:46:39 +0300 Subject: [Fedora-packaging] get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <44E0BBBB.4070103@leemhuis.info> References: <44E0BBBB.4070103@leemhuis.info> Message-ID: <1155581199.32581.25.camel@weasel.turre.laiskiainen.org> On Mon, 2006-08-14 at 20:06 +0200, Thorsten Leemhuis wrote: > == Remaining problem == > > When do old kmods get removed from the system? Yes, that's a remaining > problem (that's why it's listed here (-; ). I'll talk to jcmasters and > jeremy and will work out a solution if we agree to work further on this > idea. I'm sure we'll find a solution. The installonlyn-plugin maybe > could handle that together with the kabi stuff. weak-modules could mark > a installed module as unused and the plugin (or another plugin) could > remove it later. I don't see what's the problem here: Old module packages get removed when the kernels they depend on (through kabi-provides or otherwise) get removed, either manually or by installonlyn-plugin. - Panu - From jkeating at redhat.com Mon Aug 14 18:54:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Aug 2006 14:54:50 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155580863.32581.21.camel@weasel.turre.laiskiainen.org> References: <20060811105803.GA30245@neu.nirvana> <200608141431.41597.jkeating@redhat.com> <1155580863.32581.21.camel@weasel.turre.laiskiainen.org> Message-ID: <200608141454.50764.jkeating@redhat.com> On Monday 14 August 2006 14:41, Panu Matilainen wrote: > The entire infrastructure is based around the name of the SOURCE package > which remains the same with kmdls just like with kmods, normal > subpackage splits etc. Hrm, ok, so less impact on infrastructure. Its still a package that changes its name potentially with every rebuild which is still no good in my book. ESPECIALLY as a hack to work around other issues. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Mon Aug 14 19:15:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 14 Aug 2006 14:15:59 -0500 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <200608141431.41597.jkeating@redhat.com> (Jesse Keating's message of "Mon, 14 Aug 2006 14:31:41 -0400") References: <20060811105803.GA30245@neu.nirvana> <200608141319.32916.jkeating@redhat.com> <20060814181613.GC2908@neu.nirvana> <200608141431.41597.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Or, instead of introducing the insanity of uname-r in name, we can JK> put effort into adjusting rpm and yum to handle this sort of JK> package situation correctly. It seems like what we really need is some sort of two-dimensional versioning. I guess everyone will just laugh at me for suggesting it, but for a plugin/module "foo" having version "M" which works with "packageA" version "N", just call it "packageA-module-foo-M,N", teach the depsolvers how to deal with it, and get on with life. - J< From pmatilai at laiskiainen.org Mon Aug 14 19:17:07 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 14 Aug 2006 22:17:07 +0300 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <200608141454.50764.jkeating@redhat.com> References: <20060811105803.GA30245@neu.nirvana> <200608141431.41597.jkeating@redhat.com> <1155580863.32581.21.camel@weasel.turre.laiskiainen.org> <200608141454.50764.jkeating@redhat.com> Message-ID: <1155583027.32581.33.camel@weasel.turre.laiskiainen.org> On Mon, 2006-08-14 at 14:54 -0400, Jesse Keating wrote: > On Monday 14 August 2006 14:41, Panu Matilainen wrote: > > The entire infrastructure is based around the name of the SOURCE package > > which remains the same with kmdls just like with kmods, normal > > subpackage splits etc. > > Hrm, ok, so less impact on infrastructure. Its still a package that changes > its name potentially with every rebuild which is still no good in my book. > ESPECIALLY as a hack to work around other issues. It's not much worse than openssl :D Seriously, yes the changing package names are a a bit of a pain, silly things like scripts to prune out old packages from a repo suddenly need to be aware of version-in-name thing as well etc. Both schemes have their good points and weak points and both have been shown to work most of the time in real world, that's why I suggested flipping a coin over it earlier in this thread... - Panu - From rdieter at math.unl.edu Mon Aug 14 19:18:37 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 14 Aug 2006 14:18:37 -0500 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: References: <20060811105803.GA30245@neu.nirvana> <200608141319.32916.jkeating@redhat.com> <20060814181613.GC2908@neu.nirvana> <200608141431.41597.jkeating@redhat.com> Message-ID: <44E0CC8D.6010204@math.unl.edu> Jason L Tibbitts III wrote: >>>>>> "JK" == Jesse Keating writes: > > JK> Or, instead of introducing the insanity of uname-r in name, we can > JK> put effort into adjusting rpm and yum to handle this sort of > JK> package situation correctly. > > It seems like what we really need is some sort of two-dimensional > versioning. I guess everyone will just laugh at me for suggesting it, > but for a plugin/module "foo" having version "M" which works with > "packageA" version "N", just call it "packageA-module-foo-M,N", teach > the depsolvers how to deal with it, and get on with life. It may be just me, but I would categorize the latter effort closer to insanity than the former. -- Rex From jjneely at ncsu.edu Mon Aug 14 19:27:44 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 14 Aug 2006 15:27:44 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155563048.31141.8.camel@localhost.localdomain> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> Message-ID: <20060814192744.GF26953@anduril.unity.ncsu.edu> On Mon, Aug 14, 2006 at 08:44:08AM -0500, Tom 'spot' Callaway wrote: > On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote: > > On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote: > > > On Saturday 12 August 2006 08:14, Panu Matilainen wrote: > > > > Both choices have their weak and strong points. If it's impossible > > > > to decide based on technical merits alone... flip a coin or > > > > something, really. > > > > > > Or continue to use the current one that is being used by current > > > packages in Extras, and in RHEL. > > > > and which cannot be used for manual rpm installations, breaks all > > depsolvers, endangers your running setup or the total upgradablity of > > the system and the ugly workarounds trying to fix this turn out to > > introduce more bugs that they fix making the depsolver support a > > maintenance nightmare. > > To be fair, the only change to kmod that would be necessary to remove > all of this "it won't work for manual rpm installations" is the addition > of kver in the Name field. > > So far, the only technical reason that I've heard mentioned here against > adding kver to Name is that it would make debuginfo more complicated for > kmod packages (and I believe that someone posted a workaround method). > In fact, I suspect that kmodtool could even include the necessary magic. > > ~spot > -- > Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > No one has offered an explanation or yum plugin to handle scalability. A new kernel is released. How do I push out a new kernel module to all my machines? This scheme only appears to scale to 1 person with root on his home machine. I need to power an entire university. Because kmdl modules do not follow the kernel that adds yet another reason why upgrading to the latest kernel is painful and to be avoided. We all know where this slippery slope goes. Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jkeating at redhat.com Mon Aug 14 19:34:43 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Aug 2006 15:34:43 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155583027.32581.33.camel@weasel.turre.laiskiainen.org> References: <20060811105803.GA30245@neu.nirvana> <200608141454.50764.jkeating@redhat.com> <1155583027.32581.33.camel@weasel.turre.laiskiainen.org> Message-ID: <200608141534.43679.jkeating@redhat.com> On Monday 14 August 2006 15:17, Panu Matilainen wrote: > It's not much worse than openssl :D Openssl doesn't spawn a new package name 40x a release, and makes use of the accepted compat naming scheme. Not a fair comparison (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjneely at ncsu.edu Mon Aug 14 19:33:54 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 14 Aug 2006 15:33:54 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <44E09EAB.8070101@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> <1155565609.31141.20.camel@localhost.localdomain> <44E09EAB.8070101@leemhuis.info> Message-ID: <20060814193354.GG26953@anduril.unity.ncsu.edu> On Mon, Aug 14, 2006 at 06:02:51PM +0200, Thorsten Leemhuis wrote: > > > Tom 'spot' Callaway schrieb: > > On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote: > >> Tom 'spot' Callaway schrieb: > >>> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote: > >>> > >>> So far, the only technical reason that I've heard mentioned here against > >>> adding kver to Name is that it would make debuginfo more complicated for > >>> kmod packages (and I believe that someone posted a workaround method). > >> You forgot the biggest "issue" (note the quotes): All the depsolvers > >> would need special handling to install kmods for newly installed > >> kernels. That works out of the box with the current scheme and IMHO is > >> an important advantage of the current standard. Yes, there exists a > >> yum-plugin already that handles it. But we would need something for > >> up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. > > > > I'm not sure I see how this automatically works in the current kmod > > scheme > > Example (without a special plugin): > --- > Installed are: > kernel-2.6.17-1.2157_FC5 > kmod-foo-1.2.2.6.17-1.2157_FC5 > > kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed > to the repo > > Yum will install: > kernel-2.6.17-1.2171_FC5 > kmod-foo-1.2.2.6.17-1.2171_FC5 > --- > > (or alternately, how it doesn't work in the kmod+kver scheme). > > Example (without a special plugin): > --- > Installed are: > kernel-2.6.17-1.2157_FC5 > kmod-foo-2.6.17-1.2157_FC5-1.2 > > kernel-2.6.17-1.2171_FC5 and kmod-foo-2.6.17-1.2171_FC5-1.2 are pushed > to the repo > > Yum will install: > kernel-2.6.17-1.2171_FC5 > > kmod-foo-2.6.17-1.2171_FC5-1.2 won't get installed because it a new > package for yum whit a different name > --- > > >>> In fact, I suspect that kmodtool could even include the necessary magic. > >> Sure, that would be possible. But we'll hit other problems after this > >> major scheme change. We probably hit some in the old livna days, but I > >> forget most of them already (sorry -- maybe I can skip though bugzilla > >> to fresh up my mind). But I think sticking to the current scheme and > >> solving the "install-conflicts" problem together with the kabi stuff > >> would be the better idea. > > > > Again, I tend to defer to people who know more about packaging kernel > > modules than I do. > > I'll outline my idea in a more detailed mail I'll start preparing now. > > CU > thl > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging Thorsten, +1 This lack of functionality is a complete show stopper. I've been using a very similar method to the kmod example above for 6+ years. Its not been Pain Free(tm) but I have to have an automated system of deploying updates and kernel modules. Its just not an option or something that I will gladly re-invent. Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jjneely at ncsu.edu Mon Aug 14 19:49:50 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 14 Aug 2006 15:49:50 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060814153310.GD31585@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> <20060814153310.GD31585@neu.nirvana> Message-ID: <20060814194950.GH26953@anduril.unity.ncsu.edu> On Mon, Aug 14, 2006 at 05:33:10PM +0200, Axel Thimm wrote: > On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote: > > You forgot the biggest "issue" (note the quotes): All the depsolvers > > would need special handling to install kmods for newly installed > > kernels. That works out of the box with the current scheme and IMHO is > > an important advantage of the current standard. Yes, there exists a > > yum-plugin already that handles it. But we would need something for > > up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. > > o the yum-plugin for kmods is broken and possibly cannot be rectified, > see mail to Jack Ah, breakage. Tisk, tisk. Solve this one: Installed are: kernel-2.6.17-1.2157_FC5 kmod-foo-2.6.17-1.2157_FC5-1.2 foo-1.2-1_FC5 where kmod-foo-1.2.2.6.17-1.2157_FC5 requires foo = 1.2 Yum has: kernel-2.6.17-1.2171_FC5 kmod-foo-2.6.17-1.2171_FC5-1.3 foo-1.3_FC5 And kmod-foo-2.6.17-1.2171_FC5-1.2 requires foo = 1.3. So what happens here? # yum update We reboot into our new kernel and 10 minutes later we see that foo is totally broken because there's not a kernel module for it. # yum install kmod-foo-2.6.17-1.2171_FC5 Yum pulls in foo-1.3 to meet the requirements. Now we experiance pain as foo-1.2 and foo-1.3 are userland packages and cannot be co-installed. This affects both schemes. Is this a technical problem that can be fixed? > > o "out of the box" the current scheme is severely broken. In yum you get > file conflicts, in rpm total breakage and in smart/apt you get your > running kernel modules nuked. > I did this with Yup (of all horrid, gross, gangly things) 6 years ago with a bit of documentation/policy. > You make it sound like the kmdl scheme needs special handling, while > it's the other way round. The kmdl scheme does never jeopardize your > existing install and this inherits to all depsolvers and rpm. While > the kmod scheme violates basic rpm ordering rules and tried to rectify > with in-depsolver special handling *and* plugins and has already been > shown to be broken by design. > -- > Axel.Thimm at ATrpms.net The kmdl scheme *does* require depsolver modifications to work. I must be able to push out updated kernel modules to my clients in an automated fashion. Jack > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jjneely at ncsu.edu Mon Aug 14 19:54:06 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 14 Aug 2006 15:54:06 -0400 Subject: [Fedora-packaging] Mail voting on kmdl adoption In-Reply-To: <44E0A841.6050706@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> Message-ID: <20060814195406.GI26953@anduril.unity.ncsu.edu> 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 at redhat.com > 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 Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jjneely at ncsu.edu Mon Aug 14 19:58:13 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 14 Aug 2006 15:58:13 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060814165615.GA2908@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> Message-ID: <20060814195813.GJ26953@anduril.unity.ncsu.edu> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jjneely at ncsu.edu Mon Aug 14 20:11:11 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 14 Aug 2006 16:11:11 -0400 Subject: [Fedora-packaging] get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <44E0C536.8070000@leemhuis.info> References: <44E0BBBB.4070103@leemhuis.info> <200608141423.46910.jkeating@redhat.com> <44E0C536.8070000@leemhuis.info> Message-ID: <20060814201111.GK26953@anduril.unity.ncsu.edu> On Mon, Aug 14, 2006 at 08:47:18PM +0200, Thorsten Leemhuis wrote: > > > Jesse Keating schrieb: > > On Monday 14 August 2006 14:06, Thorsten Leemhuis wrote: > >> Yum will install: > >> kmod-foo-1.3.2.6.17-1.2171_FC5 > >> *and remove* > >> kmod-foo-1.2.2.6.17-1.2157_FC5 > >> kmod-foo-1.2.2.6.17-1.2171_FC5 > >> in the same transaction because the module location of > >> kmod-foo-1.2.2.6.17-1.2171_FC5 and kmod-foo-1.3.2.6.17-1.2171_FC5 would > >> conflict. *This remove is the problem Axel complains about.* > > I could see it removing kmod-foo-1.2.2.6.17-1.2171_FC5, but why does it also > > remove kmod-foo-1.2.2.6.17-1.2157_FC5? Wouldn't that be in a different > > module tree? > > Well, normally it's a "install transaction" but when there is a > potential file conflict it's changed to a "upgrade transaction" afaik -- > and that will remove the old kmod as well because both old kmods have > the same packagename. This is not correct. The current implentation will install the new module and add an erase transaction element for the old module requiring the same kernel. > > >> == Proposed solution == > >> > >> Install the kernel-module to > >> > >> /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko > >> > >> and remove the > >> > >> "Requires: kernel- > >> > >> Details: > >> > >> We avoid the file conflicts noted in "Problem" above due to the > >> "VERSION-RELEASE" in the path. So yum will always install the module and > >> there won't be any conflicts. > >> > >> But how will the kernel find the module there? "/sbin/weak-modules", the > >> script from the kabi stuff can create links to the proper places. It > >> does this already for modules installed in the proper place and kernels > >> that have the compatible kabi. It would be needed to adjust some > >> pathnames in the script, but that shouldn't be to hard. > >> > >> And why remove the Requires? Well, with the kabi stuff it might happen > >> (not that often in Fedora, but on RHEL often) that a module runs fine on > >> a newer kernel. We wouldn't have to build a new module in that case. > >> *But* this requires would fire back because the kmod will get removed by > >> the depsolver when the kernel is was build for gets uninstalled. > >> Therefor it needs to be removed. > > > > Also, with the kabi stuff, the Requires should get done automatically to an > > ABI version. If the next kernel has an ABI change, and you rebuild the > > module, thats cool, it picks up the new ABI in the automatic Requires. No > > manual intervention. > > That would solve the problem nicely. > > > I would _really_ like to get JCM involved in this discussion, especially on > > the proper place to drop these modules so that a respin for one kernel won't > > remove modules from an older kernel. > > +1 > > CU Generally, kabi sucks less, so +1 Right now I use the Requires: kernel-i686 = 2.6.14-1.1776_FC4 to figure out what kernel we match, but that's easy to fix. Jack > thl > > /me going to bed now soon > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From pmatilai at laiskiainen.org Mon Aug 14 20:11:46 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 14 Aug 2006 23:11:46 +0300 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060814195813.GJ26953@anduril.unity.ncsu.edu> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> <20060814195813.GJ26953@anduril.unity.ncsu.edu> Message-ID: <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote: > Again, show me how kmdl scales. A university/enterprise environment is > not a 3rd party extras repository. I pointed out earlier in this thread that we've used a scheme similar to kmdl at work (speaking of thousands of systems here) rather successfully for several years. And like I stated previously as well, this is just for the record, I'm not arguing for either scheme. It's not kmdl or kmod that scales, it's the processes for releasing kernel modules and the depsolver+plugin to handle them which need to "scale": a plugin can be smart enough to skip the kernel update if no corresponding kernel module for the new version can be found, or abort the entire update. But you'll need plugins for both schemes to catch the situation where somehow a new kernel slipped out without having kernel modules for it available, otherwise you can end up with unbootable system. - Panu - From skvidal at linux.duke.edu Mon Aug 14 20:16:22 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 14 Aug 2006 16:16:22 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> <20060814195813.GJ26953@anduril.unity.ncsu.edu> <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> Message-ID: <1155586582.565.27.camel@cutter> On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote: > On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote: > > > Again, show me how kmdl scales. A university/enterprise environment is > > not a 3rd party extras repository. > > I pointed out earlier in this thread that we've used a scheme similar to > kmdl at work (speaking of thousands of systems here) rather successfully > for several years. And like I stated previously as well, this is just > for the record, I'm not arguing for either scheme. > > It's not kmdl or kmod that scales, it's the processes for releasing > kernel modules and the depsolver+plugin to handle them which need to > "scale": a plugin can be smart enough to skip the kernel update if no > corresponding kernel module for the new version can be found, or abort > the entire update. But you'll need plugins for both schemes to catch the > situation where somehow a new kernel slipped out without having kernel > modules for it available, otherwise you can end up with unbootable > system. > monkey-wrench question: what happens if both versions of a kernel module work on the available kernel but work with different versions of the userland tools? -sv From jjneely at ncsu.edu Mon Aug 14 20:30:05 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 14 Aug 2006 16:30:05 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> <20060814195813.GJ26953@anduril.unity.ncsu.edu> <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> Message-ID: <20060814203005.GL26953@anduril.unity.ncsu.edu> On Mon, Aug 14, 2006 at 11:11:46PM +0300, Panu Matilainen wrote: > On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote: > > > Again, show me how kmdl scales. A university/enterprise environment is > > not a 3rd party extras repository. > > I pointed out earlier in this thread that we've used a scheme similar to > kmdl at work (speaking of thousands of systems here) rather successfully > for several years. And like I stated previously as well, this is just > for the record, I'm not arguing for either scheme. > > It's not kmdl or kmod that scales, it's the processes for releasing > kernel modules and the depsolver+plugin to handle them which need to > "scale": a plugin can be smart enough to skip the kernel update if no > corresponding kernel module for the new version can be found, or abort > the entire update. But you'll need plugins for both schemes to catch the > situation where somehow a new kernel slipped out without having kernel > modules for it available, otherwise you can end up with unbootable > system. > > - Panu - > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging Panu, I can agree with this. Can you point out some working code? Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jkeating at redhat.com Mon Aug 14 20:36:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Aug 2006 16:36:41 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155586582.565.27.camel@cutter> References: <20060811105803.GA30245@neu.nirvana> <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> <1155586582.565.27.camel@cutter> Message-ID: <200608141636.41582.jkeating@redhat.com> On Monday 14 August 2006 16:16, seth vidal wrote: > monkey-wrench question: > > ? what happens if both versions of a kernel module work on the available > kernel but work with different versions of the userland tools? Heee! You gotta go and make it difficult don't you... (: I haven't the brain bandwidth to think on this issue currently. Lets just try to Not Do This, as it hurts when I poke myself in the eyeball w/ my pen. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at laiskiainen.org Mon Aug 14 20:34:00 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 14 Aug 2006 23:34:00 +0300 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155586582.565.27.camel@cutter> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> <20060814195813.GJ26953@anduril.unity.ncsu.edu> <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> <1155586582.565.27.camel@cutter> Message-ID: <1155587640.32581.57.camel@weasel.turre.laiskiainen.org> On Mon, 2006-08-14 at 16:16 -0400, seth vidal wrote: > On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote: > > On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote: > > > > > Again, show me how kmdl scales. A university/enterprise environment is > > > not a 3rd party extras repository. > > > > I pointed out earlier in this thread that we've used a scheme similar to > > kmdl at work (speaking of thousands of systems here) rather successfully > > for several years. And like I stated previously as well, this is just > > for the record, I'm not arguing for either scheme. > > > > It's not kmdl or kmod that scales, it's the processes for releasing > > kernel modules and the depsolver+plugin to handle them which need to > > "scale": a plugin can be smart enough to skip the kernel update if no > > corresponding kernel module for the new version can be found, or abort > > the entire update. But you'll need plugins for both schemes to catch the > > situation where somehow a new kernel slipped out without having kernel > > modules for it available, otherwise you can end up with unbootable > > system. > > > > monkey-wrench question: > > what happens if both versions of a kernel module work on the available > kernel but work with different versions of the userland tools? S**t hits the fan, that's what happens... and neither scheme can protect against that. Similar things can happen with the main kernel itself.. you can update the kernel along with a userland (hal, udev or such) package which is incompatible with the running kernel yet rpm dependencies are satisfied. Runtime dependencies/provides would help a bit but then you'd have unresolvable deps on all the non-running kernels -> doesn't work either. - Panu - From jjneely at ncsu.edu Mon Aug 14 20:37:05 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 14 Aug 2006 16:37:05 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <200608141636.41582.jkeating@redhat.com> References: <20060811105803.GA30245@neu.nirvana> <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> <1155586582.565.27.camel@cutter> <200608141636.41582.jkeating@redhat.com> Message-ID: <20060814203705.GM26953@anduril.unity.ncsu.edu> On Mon, Aug 14, 2006 at 04:36:41PM -0400, Jesse Keating wrote: > On Monday 14 August 2006 16:16, seth vidal wrote: > > monkey-wrench question: > > > > ? what happens if both versions of a kernel module work on the available > > kernel but work with different versions of the userland tools? > > Heee! You gotta go and make it difficult don't you... (: > > I haven't the brain bandwidth to think on this issue currently. Lets just try > to Not Do This, as it hurts when I poke myself in the eyeball w/ my pen. > > -- > Jesse Keating > Release Engineer: Fedora Is it worth documenting this in the guidelines? > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From pmatilai at laiskiainen.org Mon Aug 14 20:55:50 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 14 Aug 2006 23:55:50 +0300 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060814203005.GL26953@anduril.unity.ncsu.edu> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> <20060814195813.GJ26953@anduril.unity.ncsu.edu> <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> <20060814203005.GL26953@anduril.unity.ncsu.edu> Message-ID: <1155588950.32581.74.camel@weasel.turre.laiskiainen.org> On Mon, 2006-08-14 at 16:30 -0400, Jack Neely wrote: > On Mon, Aug 14, 2006 at 11:11:46PM +0300, Panu Matilainen wrote: > > On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote: > > > > > Again, show me how kmdl scales. A university/enterprise environment is > > > not a 3rd party extras repository. > > > > I pointed out earlier in this thread that we've used a scheme similar to > > kmdl at work (speaking of thousands of systems here) rather successfully > > for several years. And like I stated previously as well, this is just > > for the record, I'm not arguing for either scheme. > > > > It's not kmdl or kmod that scales, it's the processes for releasing > > kernel modules and the depsolver+plugin to handle them which need to > > "scale": a plugin can be smart enough to skip the kernel update if no > > corresponding kernel module for the new version can be found, or abort > > the entire update. But you'll need plugins for both schemes to catch the > > situation where somehow a new kernel slipped out without having kernel > > modules for it available, otherwise you can end up with unbootable > > system. > > > Panu, > > I can agree with this. Can you point out some working code? The kernel-module plugin for apt in FE does something like that (it'll warn you in the above situation, could be made to block the update of course), but it only works with old fedora.us/livna.org style kernel-module-foo-`uname -r` packages, IIRC would need some tweaking for kmdl. I haven't bothered updating my plugins for any new schemes as I've waited for this very battle to sort itself out some day :) - Panu - From shiva at sewingwitch.com Mon Aug 14 22:25:18 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 14 Aug 2006 15:25:18 -0700 Subject: [Fedora-packaging] Pointer: Packaging discussion about Boost (C++) library Message-ID: <234839FDACB8256C803B5D4E@[10.169.6.226]> See the thread titled: Boost RPM spec file: Take 2 The initial poster points out differences in Boost and Fedora packaging philosophy and is attempting to create an RPM more in line with upstream packaging conventions. I'd recommend that the Fedora package maintainer (Benjamin Kosnik?) participate to explain the motivations behind any differences. From Axel.Thimm at ATrpms.net Mon Aug 14 23:00:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 01:00:53 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060814192744.GF26953@anduril.unity.ncsu.edu> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <20060814192744.GF26953@anduril.unity.ncsu.edu> Message-ID: <20060814230053.GD2908@neu.nirvana> On Mon, Aug 14, 2006 at 03:27:44PM -0400, Jack Neely wrote: > No one has offered an explanation or yum plugin to handle scalability. What about the plugin I submitted to this very list? > A new kernel is released. How do I push out a new kernel module to all > my machines? This scheme only appears to scale to 1 person with root on > his home machine. I need to power an entire university. yum update with the kmdl plugin is enough. You still need to be root on all the machines though ;) > Because kmdl modules do not follow the kernel that adds yet another > reason why upgrading to the latest kernel is painful and to be avoided. > We all know where this slippery slope goes. Of course they follow the kernel, that's what the plugin is for. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 14 23:04:59 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 01:04:59 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155586582.565.27.camel@cutter> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> <20060814195813.GJ26953@anduril.unity.ncsu.edu> <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> <1155586582.565.27.camel@cutter> Message-ID: <20060814230459.GE2908@neu.nirvana> On Mon, Aug 14, 2006 at 04:16:22PM -0400, seth vidal wrote: > On Mon, 2006-08-14 at 23:11 +0300, Panu Matilainen wrote: > > On Mon, 2006-08-14 at 15:58 -0400, Jack Neely wrote: > > > > > Again, show me how kmdl scales. A university/enterprise environment is > > > not a 3rd party extras repository. > > > > I pointed out earlier in this thread that we've used a scheme similar to > > kmdl at work (speaking of thousands of systems here) rather successfully > > for several years. And like I stated previously as well, this is just > > for the record, I'm not arguing for either scheme. > > > > It's not kmdl or kmod that scales, it's the processes for releasing > > kernel modules and the depsolver+plugin to handle them which need to > > "scale": a plugin can be smart enough to skip the kernel update if no > > corresponding kernel module for the new version can be found, or abort > > the entire update. But you'll need plugins for both schemes to catch the > > situation where somehow a new kernel slipped out without having kernel > > modules for it available, otherwise you can end up with unbootable > > system. > > > > monkey-wrench question: > > what happens if both versions of a kernel module work on the available > kernel but work with different versions of the userland tools? Can you explain? Do you mean two subsequent package versions of a kernel module, e.g. a version bump in the module's versioning side? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 14 23:08:22 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 01:08:22 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> References: <20060811105803.GA30245@neu.nirvana> <44E0A841.6050706@leemhuis.info> <20060814165615.GA2908@neu.nirvana> <20060814195813.GJ26953@anduril.unity.ncsu.edu> <1155586306.32581.45.camel@weasel.turre.laiskiainen.org> Message-ID: <20060814230822.GF2908@neu.nirvana> On Mon, Aug 14, 2006 at 11:11:46PM +0300, Panu Matilainen wrote: > But you'll need plugins for both schemes to catch the situation > where somehow a new kernel slipped out without having kernel modules > for it available, otherwise you can end up with unbootable system. The kmdl plugin has two modes that cover that: o yum install: Only triggers kmdl coinstallation if a kernel will be installed in this transactions and only for this kernel o yum update: Check for new available kmdls for already installed kernels kmdls will by definition - be it a 3rd party or an ISV/ISH - be shipped delayed. Maybe not for RHEL where selected partners get early access to final bits to prepare their add-ons, but certainly for non-premioum partners and for all Fedora land. Therefore any plugin needs to be able to asyncronously fill the gaps. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 14 23:26:44 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 01:26:44 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060814194950.GH26953@anduril.unity.ncsu.edu> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> <20060814153310.GD31585@neu.nirvana> <20060814194950.GH26953@anduril.unity.ncsu.edu> Message-ID: <20060814232644.GG2908@neu.nirvana> On Mon, Aug 14, 2006 at 03:49:50PM -0400, Jack Neely wrote: > On Mon, Aug 14, 2006 at 05:33:10PM +0200, Axel Thimm wrote: > > On Mon, Aug 14, 2006 at 04:06:36PM +0200, Thorsten Leemhuis wrote: > > > You forgot the biggest "issue" (note the quotes): All the depsolvers > > > would need special handling to install kmods for newly installed > > > kernels. That works out of the box with the current scheme and IMHO is > > > an important advantage of the current standard. Yes, there exists a > > > yum-plugin already that handles it. But we would need something for > > > up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. > > > > o the yum-plugin for kmods is broken and possibly cannot be rectified, > > see mail to Jack > > Ah, breakage. Tisk, tisk. Solve this one: Altready solved since long in ATrpms' everyday life. > Installed are: > kernel-2.6.17-1.2157_FC5 > kmod-foo-2.6.17-1.2157_FC5-1.2 > foo-1.2-1_FC5 > > where kmod-foo-1.2.2.6.17-1.2157_FC5 requires foo = 1.2 > > Yum has: > kernel-2.6.17-1.2171_FC5 > kmod-foo-2.6.17-1.2171_FC5-1.3 > foo-1.3_FC5 > > And kmod-foo-2.6.17-1.2171_FC5-1.2 requires foo = 1.3. You probably have a typo here, the first item is supposed to end with 1.3 > So what happens here? You are trying to do both a kernel upgrade and module version upgrade. You only get into that situation because you skipped the intermediate step (which can happen simultaneously): You don't only build mod-foo-2.6.17-1.2171_FC5-1.3, you also build kmod-foo-2.6.17-1.2157_FC5-1.3. > # yum update Updates everything to 1.3 > We reboot into our new kernel and 10 minutes later we see that foo is > totally broken because there's not a kernel module for it. Only if you messed up by simultaneous upgrading kernel and module version w/o offering interim versions. > # yum install kmod-foo-2.6.17-1.2171_FC5 > > Yum pulls in foo-1.3 to meet the requirements. Now we experiance pain > as foo-1.2 and foo-1.3 are userland packages and cannot be co-installed. Note that kernel modules have two version (evrs to be exact): o the kernel version: follows the kernel's example and allows going back and forth o the module version: follows a conventional package's upgrading If the new kernel is broken you can reboot to the previous one. If the module itself is bogus you need to downgrade as you do with conventional packages. > This affects both schemes. Is this a technical problem that can be > fixed? Not a problem with kmdls. > > You make it sound like the kmdl scheme needs special handling, while > > it's the other way round. The kmdl scheme does never jeopardize your > > existing install and this inherits to all depsolvers and rpm. While > > the kmod scheme violates basic rpm ordering rules and tried to rectify > > with in-depsolver special handling *and* plugins and has already been > > shown to be broken by design. > > The kmdl scheme *does* require depsolver modifications to work. I must be > able to push out updated kernel modules to my clients in an automated > fashion. Once again arguing in circles, but repetions works: o kmod scheme: requires workaround in yum core and requires a yum plugin to not start nuking running kernel modules or file conflicting or partial overwrites o kmdl scheme: requires trivial yum plugin to have new kernel installs automatically coinstall kmdls Note both say "requires", but the first is requires as in "requires, otherwise havoc is programmed", while the latter is "requires for added comfort" Yes, let's allow kmdls to become more comfortable, but don't compare neccessity of (trying to) unbreak things with adding automatism. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 14 23:31:42 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 01:31:42 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: References: <20060811105803.GA30245@neu.nirvana> <200608141319.32916.jkeating@redhat.com> <20060814181613.GC2908@neu.nirvana> <200608141431.41597.jkeating@redhat.com> Message-ID: <20060814233142.GH2908@neu.nirvana> On Mon, Aug 14, 2006 at 02:15:59PM -0500, Jason L Tibbitts III wrote: > >>>>> "JK" == Jesse Keating writes: > > JK> Or, instead of introducing the insanity of uname-r in name, we can > JK> put effort into adjusting rpm and yum to handle this sort of > JK> package situation correctly. > > It seems like what we really need is some sort of two-dimensional > versioning. I guess everyone will just laugh at me for suggesting it, I'm not, that's exactly the issue here. > but for a plugin/module "foo" having version "M" which works with > "packageA" version "N", just call it "packageA-module-foo-M,N", teach > the depsolvers how to deal with it, and get on with life. That can take half a decade, so we should find a solution for now and lobby with our experiences for rpmng's design. This is off-topic, but I really thing that at some time in the future our group could start thinking about setting up specifications for a new package manager trying to learn from rpm's deficiencies and trying to unearth a project for that. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Aug 14 23:57:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 01:57:03 +0200 Subject: [Fedora-packaging] Re: get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <44E0BBBB.4070103@leemhuis.info> References: <44E0BBBB.4070103@leemhuis.info> Message-ID: <20060814235703.GI2908@neu.nirvana> On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote: > /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko We already discussed that last week. You are moving the versioning problem of the modules away from rpm to module-init-tools. You need to encode evr into the path and then teach depmod or any helper application to order according to rpm's evr scheme. It's not an improvement, it's outsourcing a packaging/versioning problem to the wrong domain. And allow me to remark that for someone clinging to the current scheme because of stability issues two hours ago, suggesting a radical new scheme as a way out is a contradiction, even if the new scheme would really solve something. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 14 23:57:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Aug 2006 19:57:17 -0400 Subject: [Fedora-packaging] get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <20060814201111.GK26953@anduril.unity.ncsu.edu> References: <44E0BBBB.4070103@leemhuis.info> <44E0C536.8070000@leemhuis.info> <20060814201111.GK26953@anduril.unity.ncsu.edu> Message-ID: <200608141957.17676.jkeating@redhat.com> On Monday 14 August 2006 16:11, Jack Neely wrote: > > Well, normally it's a "install transaction" but when there is a > > potential file conflict it's changed to a "upgrade transaction" afaik -- > > and that will remove the old kmod as well because both old kmods have > > the same packagename. > > This is not correct. ?The current implentation will install the new > module and add an erase transaction element for the old module requiring > the same kernel. ? Wait, stop the presses. Isn't this the "root" of the problem that Axel is complaining about, that the kmod version of doing things will cause old modules for old kernels to get removed? If this isn't the case, then why are we talking about replacing the current standard? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 00:01:14 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 02:01:14 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <44E09EAB.8070101@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <1155329593.18928.17.camel@cutter> <1155384863.22205.5.camel@weasel.turre.laiskiainen.org> <200608120931.08171.jkeating@redhat.com> <20060812151808.GB22196@neu.nirvana> <1155563048.31141.8.camel@localhost.localdomain> <44E0836C.4030107@leemhuis.info> <1155565609.31141.20.camel@localhost.localdomain> <44E09EAB.8070101@leemhuis.info> Message-ID: <20060815000114.GJ2908@neu.nirvana> On Mon, Aug 14, 2006 at 06:02:51PM +0200, Thorsten Leemhuis wrote: > > > Tom 'spot' Callaway schrieb: > > On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote: > >> Tom 'spot' Callaway schrieb: > >>> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote: > >>> > >>> So far, the only technical reason that I've heard mentioned here against > >>> adding kver to Name is that it would make debuginfo more complicated for > >>> kmod packages (and I believe that someone posted a workaround method). > >> You forgot the biggest "issue" (note the quotes): All the depsolvers > >> would need special handling to install kmods for newly installed > >> kernels. That works out of the box with the current scheme and IMHO is > >> an important advantage of the current standard. Yes, there exists a > >> yum-plugin already that handles it. But we would need something for > >> up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. > > > > I'm not sure I see how this automatically works in the current kmod > > scheme > > Example (without a special plugin): > --- > Installed are: > kernel-2.6.17-1.2157_FC5 > kmod-foo-1.2.2.6.17-1.2157_FC5 > > kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed > to the repo > > Yum will install: > kernel-2.6.17-1.2171_FC5 > kmod-foo-1.2.2.6.17-1.2171_FC5 > --- Example: kmod-foo-1.3.2.6.17-1.2171_FC5 is pushed to the repo - yum update will bail out of file conflicts - OR will happily coinstall if the paths are disambiguated (worse) Example (yum w/o special plugin and special kernel-modules handling in core): - kmod-foo-1.2.2.6.17-1.2157_FC5 get nuked. Oops ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjneely at ncsu.edu Tue Aug 15 00:17:47 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 14 Aug 2006 20:17:47 -0400 Subject: [Fedora-packaging] get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <200608141957.17676.jkeating@redhat.com> References: <44E0BBBB.4070103@leemhuis.info> <44E0C536.8070000@leemhuis.info> <20060814201111.GK26953@anduril.unity.ncsu.edu> <200608141957.17676.jkeating@redhat.com> Message-ID: <20060815001747.GP26953@anduril.unity.ncsu.edu> On Mon, Aug 14, 2006 at 07:57:17PM -0400, Jesse Keating wrote: > On Monday 14 August 2006 16:11, Jack Neely wrote: > > > Well, normally it's a "install transaction" but when there is a > > > potential file conflict it's changed to a "upgrade transaction" afaik -- > > > and that will remove the old kmod as well because both old kmods have > > > the same packagename. > > > > This is not correct. ?The current implentation will install the new > > module and add an erase transaction element for the old module requiring > > the same kernel. ? > > Wait, stop the presses. > > Isn't this the "root" of the problem that Axel is complaining about, that the > kmod version of doing things will cause old modules for old kernels to get > removed? If this isn't the case, then why are we talking about replacing the > current standard? > > -- > Jesse Keating > Release Engineer: Fedora The fedorakmod.py implementation only removes old kernel modules when you have upgraded the kernel module within the same kernel version. Otherwise the packages would have file conflicts. So if you have installed: kmod-foo-1.2.2.6.17-1.2157_FC5 kmod-foo-1.2.2.6.17-1.2158_FC5 kmod-foo-1.2.2.6.17-1.2159_FC5 and Yum has kmod-foo-5.2.2.6.17-1.2158_FC5 in the repo you wind up with the following set installed: kmod-foo-1.2.2.6.17-1.2157_FC5 kmod-foo-5.2.2.6.17-1.2158_FC5 kmod-foo-1.2.2.6.17-1.2159_FC5 as kmod-foo-1.2.2.6.17-1.2158_FC5 and kmod-foo-5.2.2.6.17-1.2158_FC5 contain the same file paths. This is nicely solved by kabi. Jack > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From Axel.Thimm at ATrpms.net Tue Aug 15 00:22:28 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 02:22:28 +0200 Subject: [Fedora-packaging] kmod support - a diary of workarounds (was: get further rid of uname -r in the kmod stuff and solve the remaining kmod problem) In-Reply-To: <200608141957.17676.jkeating@redhat.com> References: <44E0BBBB.4070103@leemhuis.info> <44E0C536.8070000@leemhuis.info> <20060814201111.GK26953@anduril.unity.ncsu.edu> <200608141957.17676.jkeating@redhat.com> Message-ID: <20060815002228.GK2908@neu.nirvana> On Mon, Aug 14, 2006 at 07:57:17PM -0400, Jesse Keating wrote: > On Monday 14 August 2006 16:11, Jack Neely wrote: > > > Well, normally it's a "install transaction" but when there is a > > > potential file conflict it's changed to a "upgrade transaction" afaik -- > > > and that will remove the old kmod as well because both old kmods have > > > the same packagename. > > > > This is not correct. ?The current implentation will install the new > > module and add an erase transaction element for the old module requiring > > the same kernel. ? > > Wait, stop the presses. > > Isn't this the "root" of the problem that Axel is complaining about, that the > kmod version of doing things will cause old modules for old kernels to get > removed? If this isn't the case, then why are we talking about replacing the > current standard? The root of the problem is the 5 workaround steps I listed in another mail. a) You start with the kmod scheme (merging two evrs together ) and find out that this way you can only support exactly one kernel b) It looks like kmods are like kernels, e.g. always coinstall, adding Provides: kernel-module support to yum to tag all such packages as coinstallable. c) You find out that kmod are by design neither "upgrade", nor "coinstallable" class of packages. rpm/yum only know these two kind of packages. So now c1) yum installs only kernel modules for the latest module version and the latest kernel. No newer module version is installed for older kernels even if they are available in the repo. That's because yum only coinstalls *the* newest which is a merged evr scheme is moduleversion/kernelversion. yum cannot guess the two dimensional background of the problem since it only sees one common evr. c2) yum coinstalls kernel modules for the same kernels bailing out with file conflicts d) no problem, we have workarounds for workarounds for workarounds [...] Why not undo the "damage" that bad yum inflicted on us for being rpm compatible. Let's detect those coinstalls-that-should-be-none and start removing package in the plugin. Oops still not addressing the bug with yum + plugin not seeing kmods for previous kernels anymore at all! Where would we be if we wouldn't start adding more workarounds, so let's take a look into the crystal ball e) Jack persuades Seth to change the "kernel-module" yum-core behaviour from "kernel{,-flavour}" behaviour. The latter really wants yum to only see the latest version and coinstall it, but for the former we want yum to see them all and coinstall newer kernel modules for old kernels, too, e.g. trying to fix c1) f) Now suddenly yum sees too much, it also sees kernel modules that have a newer one installed (which may happen even today see [1]), so we need to remove these from the ongoing transaction g) It turned out that only some kernel modules are trivial enough to be removed on the fly in the transaction set. Many kernel modules have package dependencies that pull in or push out other packages. An old kernel module for instance "wrongly" selected for updating and later discarded by the plugin had pulled in incompatible firmware or it's older userland component. Now how to detect which package was pulled in or pushed out by the unwanted packages in the transaction set? Let's think of a hack and find a workaroung later, the alphabet is long enough. Hm, the alternative scheme only needed 99 lines of python for full unbroken yum support and no further yum-core manipulation? Hm, ... Hm, ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Tue Aug 15 00:33:14 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 14 Aug 2006 17:33:14 -0700 Subject: [Fedora-packaging] Re: get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <20060814235703.GI2908@neu.nirvana> References: <44E0BBBB.4070103@leemhuis.info> <20060814235703.GI2908@neu.nirvana> Message-ID: <1155601995.3665.20.camel@localhost> On Tue, 2006-08-15 at 01:57 +0200, Axel Thimm wrote: > On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote: > > /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko > > We already discussed that last week. You are moving the versioning > problem of the modules away from rpm to module-init-tools. > Yes and no. He's moving it to /sbin/weak-modules which seems like a logical place. weak-modules has to understand how to place kernel modules (or links to them) into the tree for depmod and friends to find them. Right now it does this for kabi. It's not a big conceptual stretch to think that it could do this for kmod as well. > You need to encode evr into the path and then teach depmod or any > helper application to order according to rpm's evr scheme. > Not necessarily. The helper application has to support a versioning scheme. We can make the ondisk directory layout match the helper's versioning scheme independent of the rpm evr. Certain versioning schemes on the part of the helper would be easier for us to work with, of course :-) > It's not an improvement, it's outsourcing a packaging/versioning > problem to the wrong domain. module-init-tools has to start supporting some sort of versioning scheme in order to support kabi. I'd argue that even without kabi, the tools should support a defined order in which they will choose what kernel modules to load. Leaving it undefined is a drawback for more than package managers. Axel, do you see any reason Thorsten's proposal wouldn't work? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue Aug 15 00:35:02 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 02:35:02 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <200608141431.41597.jkeating@redhat.com> References: <20060811105803.GA30245@neu.nirvana> <200608141319.32916.jkeating@redhat.com> <20060814181613.GC2908@neu.nirvana> <200608141431.41597.jkeating@redhat.com> Message-ID: <20060815003502.GL2908@neu.nirvana> On Mon, Aug 14, 2006 at 02:31:41PM -0400, Jesse Keating wrote: > Seems to me that we're really trying to beat around a deficiency in RPM. Yes, that's pinned down nicely by tibbs as making rpm two-dimensional. But that's what we've got and it is not going to change for a long time. > Creating whole new packages for every single kernel release is insane. New > cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our > entire infrastructure is based around the name of a package. Changing that > for every single kernel update, or special casing it in every system is just > silly. REALLY silly. I will absolutely vote against it. As outlined by Panu this is not the case. In fact the infrastructure and maintenance is halfed as there is really only one name, not two like it is today. The kmod standard need two bugzilla entries per package, two owner entries, two cvs modules. kmdls only need one. So may I take that as a vote in favour of a one-sepcfile design? :) > > But the argument goes on that once you pull in a package "by mistake" > > you cannot undo it unless it is trivial e.g. has no further package > > depedencies like requires/obsoletes/conflict. These cascade further > > changes in yum's dependency resolver and undoing them in a plugin > > effectivly lead to redesigning yum in the plugin. > > > > Currently the plugin assumes that is not the case, which is the case > > with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will > > fail in these cases. > > I have read these two paragraphs 5 times, and I still don't understand what > you are saying. Examples work wonders. I'm lost in hyperbole land. OK, suppose some kernel module scheme like kmod works against yum's depsolving. Since yum adhears to rpm orderign and the kmod scheme doesn't that's not difficult to achive. Now the setup is such that yum will either install too many or to few packages. Too few is good, you can always add to yum's transaction and yum will compute the new dependencies. Too much is really bad, because the pulled in packages will pull in more packages or push out others (due to Requires/Obsoletes/Conflicts). Let's get to an example: ipw3945 version X (the exmaple is real, but don't have me lookup the true versions please) requires ipw3945d Y (a userland daemon). ipw3945 X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X this will have pulled in ipw3945d-Y. Undoing this in some plugin code would only remove ipw3945-X, not ipw3945d-Y. Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc. > You're working around an issue in rpm by creating new packages all the time. > That's not a solution, that's an ugly hack. The packages are really distinct and have different functionality and depednencies. You need both evrs in the total package filename. Moving them to the rpm name turns to solve 95% of all issues. And the fears on increased infrastructure are unbased, you even save some. > Thanks, I've heard enough to make up my mind. -1 on the entire thing. OK, is that still the case after having seen that infrastructure is not bitten? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 00:53:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 02:53:03 +0200 Subject: [Fedora-packaging] Re: get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <1155601995.3665.20.camel@localhost> References: <44E0BBBB.4070103@leemhuis.info> <20060814235703.GI2908@neu.nirvana> <1155601995.3665.20.camel@localhost> Message-ID: <20060815005303.GM2908@neu.nirvana> On Mon, Aug 14, 2006 at 05:33:14PM -0700, Toshio Kuratomi wrote: > On Tue, 2006-08-15 at 01:57 +0200, Axel Thimm wrote: > > On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote: > > > /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko > > > > We already discussed that last week. You are moving the versioning > > problem of the modules away from rpm to module-init-tools. > > > Yes and no. He's moving it to /sbin/weak-modules which seems like a > logical place. weak-modules has to understand how to place kernel > modules (or links to them) into the tree for depmod and friends to find > them. Right now it does this for kabi. It's not a big conceptual > stretch to think that it could do this for kmod as well. > > > You need to encode evr into the path and then teach depmod or any > > helper application to order according to rpm's evr scheme. > > > Not necessarily. The helper application has to support a versioning > scheme. We can make the ondisk directory layout match the helper's > versioning scheme independent of the rpm evr. Certain versioning > schemes on the part of the helper would be easier for us to work with, > of course :-) Then what use would the evr be at all? yum is taught to ignore it and module-init-tools will ignore it, too. So if I issue a new release of the module it get's either coinstalled, or if there really is no 1-1 mapping it may even start overwrite the previous module. > > It's not an improvement, it's outsourcing a packaging/versioning > > problem to the wrong domain. > > module-init-tools has to start supporting some sort of versioning scheme > in order to support kabi. I'd argue that even without kabi, the tools > should support a defined order in which they will choose what kernel > modules to load. Leaving it undefined is a drawback for more than > package managers. > > > Axel, do you see any reason Thorsten's proposal wouldn't work? Inability to replace a broken module? Ignoring evrs on modules? E.g. I can never go back to a previous version if 3w-9xxx turns out to be broken? Solving a problem by moving it to another domain? kabi makes no sense for Fedora. It is soemthing for people wishing there existed a kernel abi like ISV/IHVs with mostly closed source content. Upstream kernel development has clearly stated that even due to political reasons there will not be a kernel api, it's documented in every kernel source and on every Fedora system in kernel-docs. Vendors that will keep their kernels stable, e.g. only apply security bugfixes, can say that their have some kind of kernel abi and even give it a vendor-specfic name/value. Like RHEL4 was exporting kabi = 4.0 or similar. This makes only sense for RHEL and SLES, Fedora's kabi changes with every kernel release. Even RHEL5 will change it's "kabi" with every quaterly release, just like RHEL4U4 shows us. There is no other way to support new drivers and introducing kernel abi *metrics* is not introducing a kernel api/abi, which only the kernel developers could introduce, which they deliberately won't. So kabi is of use only to ISV/IHVs with potentially closed source (or at least not commited upstream) of RHEL kernels within a quater of a year. For Fedora it's only an obstruction, and kernel modules falling under this category would not even make it into Fedora. Don't get me wrong, I'n neither arguing against RHEL, ISVs, closed source or anything, I'm just showing what the use is for to show that we can't expect much. What you can expect is indeed some limited recycling of kernel modules of previous kernel/kernel module installations especially on RHEL. But that's an orthogonal project to packaging them. weak-updates should check wherever kernel modules of the kernel package and the external kernel modules is placed and see whether the module is reusable. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Aug 15 01:02:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Aug 2006 21:02:01 -0400 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060815003502.GL2908@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <200608141431.41597.jkeating@redhat.com> <20060815003502.GL2908@neu.nirvana> Message-ID: <200608142102.01671.jkeating@redhat.com> On Monday 14 August 2006 20:35, Axel Thimm wrote: > As outlined by Panu this is not the case. In fact the infrastructure > and maintenance is halfed as there is really only one name, not two > like it is today. The kmod standard need two bugzilla entries per > package, two owner entries, two cvs modules. kmdls only need one. > > So may I take that as a vote in favour of a one-sepcfile design? :) Absolutely not. Userland is separate from the kernel module. Forcing the userland crud to be rebuilt and reshipped and redownloaded each and every time the kernel is updated (or kabi changes) is ridiculous. There is a big difference between a set of userland+kmod for each module set and a new package each and every time the kernel is updated. > > > But the argument goes on that once you pull in a package "by mistake" > > > you cannot undo it unless it is trivial e.g. has no further package > > > depedencies like requires/obsoletes/conflict. These cascade further > > > changes in yum's dependency resolver and undoing them in a plugin > > > effectivly lead to redesigning yum in the plugin. > > > > > > Currently the plugin assumes that is not the case, which is the case > > > with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will > > > fail in these cases. > > > > I have read these two paragraphs 5 times, and I still don't understand > > what you are saying. ?Examples work wonders. ?I'm lost in hyperbole land. > > OK, suppose some kernel module scheme like kmod works against yum's > depsolving. Since yum adhears to rpm orderign and the kmod scheme > doesn't that's not difficult to achive. > > Now the setup is such that yum will either install too many or to few > packages. Too few is good, you can always add to yum's transaction and > yum will compute the new dependencies. Too much is really bad, because > the pulled in packages will pull in more packages or push out others > (due to Requires/Obsoletes/Conflicts). > > Let's get to an example: > > ipw3945 version X (the exmaple is real, but don't have me lookup the > true versions please) requires ipw3945d Y (a userland daemon). ipw3945 > X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X > this will have pulled in ipw3945d-Y. Undoing this in some plugin code > would only remove ipw3945-X, not ipw3945d-Y. > > Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc. Are you really going to versionize the entire userland? Have a separate daemon for each possible module version? How does THAT work at boot time? When your userland moves beyond what your kernel can handle (udev updates, etc..) perhaps its time to update your kernel. If you can't, well then perhaps you shouldn't be using a distribution that moves quickly. And if you're changing the userland that fast on a RHEL product, well then you're using it wrong and tough ditty. > > You're working around an issue in rpm by creating new packages all the > > time. ? That's not a solution, that's an ugly hack. > > The packages are really distinct and have different functionality and > depednencies. You need both evrs in the total package filename. Moving > them to the rpm name turns to solve 95% of all issues. And the fears > on increased infrastructure are unbased, you even save some. > > > Thanks, I've heard enough to make up my mind. ?-1 on the entire thing. > > OK, is that still the case after having seen that infrastructure is > not bitten? Nope. The infrastructure bits were only a small part of my concern. Still a -1. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 01:26:02 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 03:26:02 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <200608142102.01671.jkeating@redhat.com> References: <20060811105803.GA30245@neu.nirvana> <200608141431.41597.jkeating@redhat.com> <20060815003502.GL2908@neu.nirvana> <200608142102.01671.jkeating@redhat.com> Message-ID: <20060815012602.GP2908@neu.nirvana> On Mon, Aug 14, 2006 at 09:02:01PM -0400, Jesse Keating wrote: > On Monday 14 August 2006 20:35, Axel Thimm wrote: > > As outlined by Panu this is not the case. In fact the infrastructure > > and maintenance is halfed as there is really only one name, not two > > like it is today. The kmod standard need two bugzilla entries per > > package, two owner entries, two cvs modules. kmdls only need one. > > > > So may I take that as a vote in favour of a one-sepcfile design? :) > > Absolutely not. Userland is separate from the kernel module. > Forcing the userland crud to be rebuilt and reshipped and > redownloaded each and every time the kernel is updated (or kabi > changes) is ridiculous. There is a big difference between a set of > userland+kmod for each module set and a new package each and every > time the kernel is updated. Yes, I agree, so it's nice that this is not the case with kmdls :) Just go over to ATrpms and have a look at the packages. You have many misunderstandings on the kmdl proposal and maybe looking at real packages may help. Testing them out with the kmdl plugin would be even better. > > Let's get to an example: > > > > ipw3945 version X (the exmaple is real, but don't have me lookup the > > true versions please) requires ipw3945d Y (a userland daemon). ipw3945 > > X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X > > this will have pulled in ipw3945d-Y. Undoing this in some plugin code > > would only remove ipw3945-X, not ipw3945d-Y. > > > > Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc. > > Are you really going to versionize the entire userland? No, the versions above are not kernel versions, you misinterpreted them. The example is all within the same kernel, say 2.6.17-Z if you like. > Have a separate daemon for each possible module version? Again a misinterpretation. The daemon has nothing to do with the kmdl scheme, it's part of the project. There is no daemon in the design. But you asked for real life examples and that is one. Instead of a daemon this might be the firmware packages etc, and no - the kmdls scheme doesn't need firmwares per module, neither. :) > How does THAT work at boot time? When your userland moves beyond > what your kernel can handle (udev updates, etc..) perhaps its time > to update your kernel. If you can't, well then perhaps you > shouldn't be using a distribution that moves quickly. And if you're > changing the userland that fast on a RHEL product, well then you're > using it wrong and tough ditty. All in the wrong context, you made some wrong assumptions and ended in a devastating picture of the kmdl scheme. I shudder myself from such a vision. :) > > > Thanks, I've heard enough to make up my mind. ?-1 on the entire thing. > Nope. The infrastructure bits were only a small part of my concern. Still > a -1. You are misinterpreting my explanations beyond recognition, so perhaps I should simply accept that. ;) If doubts come up, you know where to find me. It's 2 in favour 1 against for now. Still looking for 4 people which will give their +1. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Aug 15 05:42:53 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 Aug 2006 07:42:53 +0200 Subject: Proposal: reject the one-spec approach (was: Re: [Fedora-packaging] Mail voting on kmdl adoption) In-Reply-To: <20060811105803.GA30245@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> Message-ID: <44E15EDD.90909@leemhuis.info> Hi all! I think we fight to many battles at once. So let's start concentrate on one of the easy ones first. As the uname -r debatte is likely to take some time I choose the "one-spec approach" one. I'd like to propose that the packaging group rejects this part from Axels scheme: Axel Thimm schrieb: > > b) kernel module scheme needs one-specfile approach (for both usreland > and kernel modules) > We currently have a split with the current kmod standard, e.g. userland and kmod have their own packages (spot was one of the drivers behind it IIRC). Both approaches have small advantages and disadvantages (I don't think mention the pros and cons of each one here makes much sense), but there is nothing earth scattering that make one of the two much better. But the split - was agreed on some month ago by FESCo (the predecessor of the packaging committee in this respect). Why change it again without a good reason? - changeing all the existing specs over to a one-specfile approach will be a lot of work because -- it's already in production (in FE and LVN) -- we have a lot of packages under review that use the split approach; -- is time critical because we're already after test2 - packagers and some reviewers are familiar with it already - it works in the buildsystem already -- the kmdl scheme would need special handling that needs to be programmed So changing this will be lot's of trouble without a benefit. So let's reject this part now. CU thl From Axel.Thimm at ATrpms.net Tue Aug 15 08:20:40 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 10:20:40 +0200 Subject: Proposal: reject the one-spec approach (was: Re: [Fedora-packaging] Mail voting on kmdl adoption) In-Reply-To: <44E15EDD.90909@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <44E15EDD.90909@leemhuis.info> Message-ID: <20060815082040.GA13461@neu.nirvana> On Tue, Aug 15, 2006 at 07:42:53AM +0200, Thorsten Leemhuis wrote: > I think we fight to many battles at once. So let's start concentrate on > one of the easy ones first. As the uname -r debatte is likely to take > some time I choose the "one-spec approach" one. > -- it's already in production (in FE and LVN) > -- we have a lot of packages under review that use the split approach; There is exactly one (1) package in Fedora and lives only in FE5. > -- is time critical because we're already after test2 For this very one package ... > - packagers and some reviewers are familiar with it already I only count Ville and you. > - it works in the buildsystem already -- the kmdl scheme would need > special handling that needs to be programmed In a previous mail you admitted not being kernel agnostic yet because otherwise your kmods won't build. And I offered adding kmdl support to the buildsystem. > So changing this will be lot's of trouble without a benefit. So let's > reject this part now. No, please don't listen to the devil. :) Thorsten, this is part of the voting, it will be voted upon, if you allow people to do so. This guerilla tactics are becoming ugly. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Aug 15 08:38:46 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 Aug 2006 10:38:46 +0200 Subject: [Fedora-packaging] Re: Proposal: reject the one-spec approach In-Reply-To: <20060815082040.GA13461@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <44E15EDD.90909@leemhuis.info> <20060815082040.GA13461@neu.nirvana> Message-ID: <44E18816.6000209@leemhuis.info> Axel Thimm schrieb: > On Tue, Aug 15, 2006 at 07:42:53AM +0200, Thorsten Leemhuis wrote: >> I think we fight to many battles at once. So let's start concentrate on >> one of the easy ones first. As the uname -r debatte is likely to take >> some time I choose the "one-spec approach" one. > >> -- it's already in production (in FE and LVN) >> -- we have a lot of packages under review that use the split approach; > There is exactly one (1) package in Fedora and lives only in FE5. +2 more in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod) +7 under review +6 in lvn >> -- is time critical because we're already after test2 > For this very one package ... It's to late for FC6 and RHEL IMHO. >> - packagers and some reviewers are familiar with it already > I only count Ville and you. 7 packages under review (from different people afaics), jcmasters, nirik, f13, jeremy, tibbs >> - it works in the buildsystem already -- the kmdl scheme would need >> special handling that needs to be programmed > In a previous mail you admitted not being kernel agnostic yet because > otherwise your kmods won't build. The hardcoded stuff it optional and it works *now*. >> So changing this will be lot's of trouble without a benefit. So let's >> reject this part now. > No, please don't listen to the devil. :) :) > Thorsten, this is part of the voting, it will be voted upon, if you > allow people to do so. Sure. > This guerilla tactics are becoming ugly. That's why I think it's time that spot as leader of this group IMHO jumps in. Otherwise we waste a lot of time arguing without results. CU thl From Axel.Thimm at ATrpms.net Tue Aug 15 08:43:52 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 10:43:52 +0200 Subject: [Fedora-packaging] Re: Proposal: reject the one-spec approach In-Reply-To: <44E18816.6000209@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <44E15EDD.90909@leemhuis.info> <20060815082040.GA13461@neu.nirvana> <44E18816.6000209@leemhuis.info> Message-ID: <20060815084352.GB13461@neu.nirvana> On Tue, Aug 15, 2006 at 10:38:46AM +0200, Thorsten Leemhuis wrote: > >There is exactly one (1) package in Fedora and lives only in FE5. > > +2 more in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod) > > +7 under review > > +6 in lvn -67 in ATrpms Looks like you're raising this to an ATrpms vs livna issue? I thought we wanted to merge ... > >This guerilla tactics are becoming ugly. > > That's why I think it's time that spot as leader of this group IMHO > jumps in. Otherwise we waste a lot of time arguing without results. When he showed he tends to a uname-r-in-version solution you seem to have activated all your muscles against it even though you promised otherwise before. You still have your chance to reject it in fesco. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 08:46:34 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 10:46:34 +0200 Subject: [Fedora-packaging] Re: kmdl proposal and kmod flaws In-Reply-To: <44D861C3.3050708@leemhuis.info> References: <20060808092646.GE1475@neu.nirvana> <44D861C3.3050708@leemhuis.info> Message-ID: <20060815084634.GC13461@neu.nirvana> On Tue, Aug 08, 2006 at 12:04:51PM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > >I've created a wiki page outlining the kmdl design as well as showing > >the flaws of the current kernel module scheme ("kmod"): > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls > > Just FYI, I won't oppose this in general -- if people think this is the > way forward (*1) and if we get a buy in from Core developers, too, I'm > fine with working further on it. What exactly would it mean if you had opposed in general? I see you oppose this on every corner of the proposal, defending the kmod scheme more and more the more flaws are brought up. You need to be able to let leave for the sake of the project. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Aug 15 10:16:29 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 Aug 2006 12:16:29 +0200 Subject: [Fedora-packaging] Re: Proposal: reject the one-spec approach In-Reply-To: <20060815084352.GB13461@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <44E15EDD.90909@leemhuis.info> <20060815082040.GA13461@neu.nirvana> <44E18816.6000209@leemhuis.info> <20060815084352.GB13461@neu.nirvana> Message-ID: <44E19EFD.2080801@leemhuis.info> Axel Thimm schrieb: > On Tue, Aug 15, 2006 at 10:38:46AM +0200, Thorsten Leemhuis wrote: >>> There is exactly one (1) package in Fedora and lives only in FE5. >> +2 more in cvs that are not build ATM (thinkpad-lkmod and lirc-kmod) >> +7 under review >> +6 in lvn > -67 in ATrpms > > Looks like you're raising this to an ATrpms vs livna issue? I thought > we wanted to merge ... I hope we can still merge. >>> This guerilla tactics are becoming ugly. >> That's why I think it's time that spot as leader of this group IMHO >> jumps in. Otherwise we waste a lot of time arguing without results. > > When he showed he tends to a uname-r-in-version solution you seem to > have activated all your muscles against it even though you promised > otherwise before. I activated all my muscles for a complete switch from the current kmod standard to something else because - the current kmod standard was developed in half a year with a lot of work involved from me, scop, jeremy, warren, f13 and others. jcmaster (and other people I never have heard of) invested a lot of time in it for RHEL. Throwing that completely away would be painful, but I would do that if there are good reasons for it. I can't see them. Question to scop, jeremy, warren, f13, jcmaster: Do you see any reasons why we should throw away everything? - throwing it away this short before RHEL beta1 and FC6test3 is IMHO not acceptable -- especially because we don't have many experiences with it (well, scop, I and some others have experiences with the "uname -r" scheme, but at least mine were not as good as yours). Back to the uname-r-in-version thing: Well, I think the uname-r-in-version solution is not the best solution. But as I said earlier in this thread: "0" (e.g. undecided) currently if we only work for Fedora here. But that would mean that we change kmodtool to handle it as spot cuggested in the wiki. "-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" and "undecided". > You still have your chance to reject it in fesco. I'm not doing the FESCo decisions alone. CU thl From fedora at leemhuis.info Tue Aug 15 11:13:25 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 Aug 2006 13:13:25 +0200 Subject: [Fedora-packaging] Re: Proposal: reject the one-spec approach In-Reply-To: <44E19EFD.2080801@leemhuis.info> References: <20060811105803.GA30245@neu.nirvana> <44E15EDD.90909@leemhuis.info> <20060815082040.GA13461@neu.nirvana> <44E18816.6000209@leemhuis.info> <20060815084352.GB13461@neu.nirvana> <44E19EFD.2080801@leemhuis.info> Message-ID: <44E1AC55.7080305@leemhuis.info> Thorsten Leemhuis schrieb: > Axel Thimm schrieb: >> On Tue, Aug 15, 2006 at 10:38:46AM +0200, Thorsten Leemhuis wrote: >>>> This guerilla tactics are becoming ugly. >>> That's why I think it's time that spot as leader of this group IMHO >>> jumps in. Otherwise we waste a lot of time arguing without results. >> >> When he showed he tends to a uname-r-in-version solution you seem to >> have activated all your muscles against it even though you promised >> otherwise before. > > I activated all my muscles for s/for/against/ -- but that's pretty obvious probably ;-) > a complete switch from the current kmod > standard to something else because [...] CU thl From Axel.Thimm at ATrpms.net Tue Aug 15 11:32:20 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 13:32:20 +0200 Subject: [Fedora-packaging] Re: fedorakmod.py unfixable In-Reply-To: <20060812153310.GC22196@neu.nirvana> References: <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <20060812153310.GC22196@neu.nirvana> Message-ID: <20060815113220.GD13461@neu.nirvana> Hi Jack, On Sat, Aug 12, 2006 at 05:33:10PM +0200, Axel Thimm wrote: > can you please answer on the statement below that wrt fedorakmod.py > plugin if the wrongly tagged kernel module packages pull in other > packages through dependencies you're hosed up? > Please make a statement about that as this demonstrates that the > plugin has unfixable flaws - which is neither yum's not the plugin's > fault, it is just the mirroring of allowing an rpm-incompatible > kernel module scheme. > > I hope the correctness and maintenance issues here will persuade the > last kmdl opponent. :) I moved the issues to http://fedoraproject.org/wiki/AxelThimm/kmdls Please check the raised issues and make a statement. The kmod+yum+anyplugin setup just cannot work and it's the best for the packaging folks to hear that from a third person, too. Thanks. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 11:33:57 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 13:33:57 +0200 Subject: [Fedora-packaging] Re: kmod support - a diary of workarounds In-Reply-To: <20060815002228.GK2908@neu.nirvana> References: <44E0BBBB.4070103@leemhuis.info> <44E0C536.8070000@leemhuis.info> <20060814201111.GK26953@anduril.unity.ncsu.edu> <200608141957.17676.jkeating@redhat.com> <20060815002228.GK2908@neu.nirvana> Message-ID: <20060815113357.GE13461@neu.nirvana> Added to http://fedoraproject.org/wiki/AxelThimm/kmdls, search for pandora's box. On Tue, Aug 15, 2006 at 02:22:28AM +0200, Axel Thimm wrote: > On Mon, Aug 14, 2006 at 07:57:17PM -0400, Jesse Keating wrote: > > On Monday 14 August 2006 16:11, Jack Neely wrote: > > > > Well, normally it's a "install transaction" but when there is a > > > > potential file conflict it's changed to a "upgrade transaction" afaik -- > > > > and that will remove the old kmod as well because both old kmods have > > > > the same packagename. > > > > > > This is not correct. ?The current implentation will install the new > > > module and add an erase transaction element for the old module requiring > > > the same kernel. ? > > > > Wait, stop the presses. > > > > Isn't this the "root" of the problem that Axel is complaining about, that the > > kmod version of doing things will cause old modules for old kernels to get > > removed? If this isn't the case, then why are we talking about replacing the > > current standard? > > The root of the problem is the 5 workaround steps I listed in another > mail. > > a) You start with the kmod scheme (merging two evrs together ) and > find out that this way you can only support exactly one kernel > b) It looks like kmods are like kernels, e.g. always coinstall, adding > Provides: kernel-module support to yum to tag all such packages as > coinstallable. > c) You find out that kmod are by design neither "upgrade", nor > "coinstallable" class of packages. rpm/yum only know these two kind > of packages. So now > > c1) yum installs only kernel modules for the latest module version > and the latest kernel. No newer module version is installed for > older kernels even if they are available in the repo. That's > because yum only coinstalls *the* newest which is a merged evr > scheme is moduleversion/kernelversion. yum cannot guess the two > dimensional background of the problem since it only sees one > common evr. > > c2) yum coinstalls kernel modules for the same kernels bailing out > with file conflicts > > d) no problem, we have workarounds for workarounds for workarounds [...] > Why not undo the "damage" that bad yum inflicted on us for being > rpm compatible. Let's detect those coinstalls-that-should-be-none > and start removing package in the plugin. > > Oops still not addressing the bug with yum + plugin not seeing kmods > for previous kernels anymore at all! > > Where would we be if we wouldn't start adding more workarounds, so > let's take a look into the crystal ball > > e) Jack persuades Seth to change the "kernel-module" yum-core > behaviour from "kernel{,-flavour}" behaviour. The latter really > wants yum to only see the latest version and coinstall it, but for > the former we want yum to see them all and coinstall newer kernel > modules for old kernels, too, e.g. trying to fix c1) > > f) Now suddenly yum sees too much, it also sees kernel modules that > have a newer one installed (which may happen even today see [1]), > so we need to remove these from the ongoing transaction > > g) It turned out that only some kernel modules are trivial enough to > be removed on the fly in the transaction set. Many kernel modules > have package dependencies that pull in or push out other > packages. An old kernel module for instance "wrongly" selected for > updating and later discarded by the plugin had pulled in > incompatible firmware or it's older userland component. > > Now how to detect which package was pulled in or pushed out by the > unwanted packages in the transaction set? Let's think of a hack and > find a workaroung later, the alphabet is long enough. > > Hm, the alternative scheme only needed 99 lines of python for full > unbroken yum support and no further yum-core manipulation? > > Hm, ... > > Hm, ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 12:13:25 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 14:13:25 +0200 Subject: [Fedora-packaging] Re: get further rid of uname -r in the kmod stuff and solve the remaining kmod problem In-Reply-To: <20060815005303.GM2908@neu.nirvana> References: <44E0BBBB.4070103@leemhuis.info> <20060814235703.GI2908@neu.nirvana> <1155601995.3665.20.camel@localhost> <20060815005303.GM2908@neu.nirvana> Message-ID: <20060815121325.GF13461@neu.nirvana> I've added some bits of kabi discussion to the wiki: http://fedoraproject.org/wiki/AxelThimm/kmdls On Tue, Aug 15, 2006 at 02:53:03AM +0200, Axel Thimm wrote: > On Mon, Aug 14, 2006 at 05:33:14PM -0700, Toshio Kuratomi wrote: > > On Tue, 2006-08-15 at 01:57 +0200, Axel Thimm wrote: > > > On Mon, Aug 14, 2006 at 08:06:51PM +0200, Thorsten Leemhuis wrote: > > > > /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko > > > > > > We already discussed that last week. You are moving the versioning > > > problem of the modules away from rpm to module-init-tools. > > > > > Yes and no. He's moving it to /sbin/weak-modules which seems like a > > logical place. weak-modules has to understand how to place kernel > > modules (or links to them) into the tree for depmod and friends to find > > them. Right now it does this for kabi. It's not a big conceptual > > stretch to think that it could do this for kmod as well. > > > > > You need to encode evr into the path and then teach depmod or any > > > helper application to order according to rpm's evr scheme. > > > > > Not necessarily. The helper application has to support a versioning > > scheme. We can make the ondisk directory layout match the helper's > > versioning scheme independent of the rpm evr. Certain versioning > > schemes on the part of the helper would be easier for us to work with, > > of course :-) > > Then what use would the evr be at all? yum is taught to ignore it and > module-init-tools will ignore it, too. So if I issue a new release of > the module it get's either coinstalled, or if there really is no 1-1 > mapping it may even start overwrite the previous module. > > > > It's not an improvement, it's outsourcing a packaging/versioning > > > problem to the wrong domain. > > > > module-init-tools has to start supporting some sort of versioning scheme > > in order to support kabi. I'd argue that even without kabi, the tools > > should support a defined order in which they will choose what kernel > > modules to load. Leaving it undefined is a drawback for more than > > package managers. > > > > > > Axel, do you see any reason Thorsten's proposal wouldn't work? > > Inability to replace a broken module? Ignoring evrs on modules? > E.g. I can never go back to a previous version if 3w-9xxx turns out to > be broken? Solving a problem by moving it to another domain? > > kabi makes no sense for Fedora. It is soemthing for people wishing > there existed a kernel abi like ISV/IHVs with mostly closed source > content. Upstream kernel development has clearly stated that even due > to political reasons there will not be a kernel api, it's documented > in every kernel source and on every Fedora system in kernel-docs. > > Vendors that will keep their kernels stable, e.g. only apply security > bugfixes, can say that their have some kind of kernel abi and even > give it a vendor-specfic name/value. Like RHEL4 was exporting kabi = > 4.0 or similar. This makes only sense for RHEL and SLES, Fedora's kabi > changes with every kernel release. Even RHEL5 will change it's "kabi" > with every quaterly release, just like RHEL4U4 shows us. There is no > other way to support new drivers and introducing kernel abi *metrics* > is not introducing a kernel api/abi, which only the kernel developers > could introduce, which they deliberately won't. > > So kabi is of use only to ISV/IHVs with potentially closed source (or > at least not commited upstream) of RHEL kernels within a quater of a > year. For Fedora it's only an obstruction, and kernel modules falling > under this category would not even make it into Fedora. > > Don't get me wrong, I'n neither arguing against RHEL, ISVs, closed > source or anything, I'm just showing what the use is for to show that > we can't expect much. > > What you can expect is indeed some limited recycling of kernel modules > of previous kernel/kernel module installations especially on RHEL. But > that's an orthogonal project to packaging them. weak-updates should > check wherever kernel modules of the kernel package and the external > kernel modules is placed and see whether the module is reusable. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 12:36:47 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 14:36:47 +0200 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <20060815123406.GG13461@neu.nirvana> References: <20060815123406.GG13461@neu.nirvana> Message-ID: <20060815123647.GH13461@neu.nirvana> On Tue, Aug 15, 2006 at 02:34:06PM +0200, Axel Thimm wrote: > Especially if you are a kernel module package author or want to become > one: Please check the wiki and if you care about it join the > discussion at fedora-packaging - reply-to set to that list, please > don't scatter the discussion on fedora-extras and fedora-devel, I'm > only calling for participation in the discussion to get this nailed > once and for all. Thanks! I messed up with fedora-packaging's mail address, it's fedora-packaging at redhat.com, not fedora-packaging-list at redhat.com So please fix it before replying :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 12:34:06 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 14:34:06 +0200 Subject: [Fedora-packaging] Attention kernel module project packagers! Message-ID: <20060815123406.GG13461@neu.nirvana> Hi all, there is currently a discussion about replacing the current kernel module scheme ("kmod") with a new one ("kmdls"). This is because the current scheme has some unfixable flaws. The proposed new scheme is the one used at ATrpms, so if you ever used a kernel module package from there you know how it is setup. The kmdl approach has several nice features other than being resistant to the design issues of the current setup. * It is an interface/implementation design that can actually even be used for the current (broken) setup. The specfile remains invariant. * It uses one specfile/src.rpm for both userland and kernel modules, e.g. one set of sources/patches/changelogs/bugzilla entries/owners. * It is kernel and kernel-flavour agnostic, the same specfile/src.rpm can be used for any kernel/flavour combination, even for such that are yet to come. * Has full yum-support with a 99-line python plugin, works even w/o the plugin with a couple more keystrokes. * Is field-proven for several years and managed to never have to change the interface! More details are on http://fedoraproject.org/wiki/AxelThimm/kmdls It is important for FC6 and RHEL5 to make a decision on adopting it. Currently GFS is being packaged in the old scheme which is known to exhibit several flaws. An argument against adopting kmdls presented by Thorsten Leemhuis is that * it's too late now to fix it, we should live on with kmod bugs for RHEL5's life-cycle (ending 2012 ...) * too many packages for kmod are written (but actually there is only one in Fedora Extras 5, the rest is pending or in other repos and if other repos count, then ATrpms has several dozens of kmdls :) I think the flaws are severe enough to immediate block the current kmod standard especially it's propagation into RHEL. The wiki above shows that the design flaws propagate throughout any attemt to "fix" yum (note: yum is not broken, there the quotes in "fix") and finally end with the requirement that only one kernel can be supported in any point of time. This is neither acceptable by Fedora, and even less be RHEL. The number of packages following the kmod standard are quite few and I hope that the authors will not mind using the kmdl standard, but that's for you to say. Especially if you are a kernel module package author or want to become one: Please check the wiki and if you care about it join the discussion at fedora-packaging - reply-to set to that list, please don't scatter the discussion on fedora-extras and fedora-devel, I'm only calling for participation in the discussion to get this nailed once and for all. Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 12:56:13 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 14:56:13 +0200 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <1155646085.22871.43.camel@pmac.infradead.org> References: <20060815123406.GG13461@neu.nirvana> <1155646085.22871.43.camel@pmac.infradead.org> Message-ID: <20060815125613.GM13461@neu.nirvana> On Tue, Aug 15, 2006 at 01:48:05PM +0100, David Woodhouse wrote: > On Tue, 2006-08-15 at 14:34 +0200, Axel Thimm wrote: > > An argument against adopting kmdls presented by Thorsten Leemhuis is > > that > > > > * it's too late now to fix it, we should live on with kmod bugs for > > RHEL5's life-cycle (ending 2012 ...) > > > > * too many packages for kmod are written (but actually there is only one > > in Fedora Extras 5, the rest is pending or in other repos and if > > other repos count, then ATrpms has several dozens of kmdls :) > > I think this argument is invalid. We should ban _all_ module packages > from Core and Extras anyway. That's a valid viewpoint. Assuming Fedora Core/Extras indeed bans all external kernel module packages, does it have the authority/interest to maintain a kernel module packaging guide? If not who should? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 15 13:02:54 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 15:02:54 +0200 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <1155646309.3004.2.camel@zod.rchland.ibm.com> References: <20060815123406.GG13461@neu.nirvana> <1155646309.3004.2.camel@zod.rchland.ibm.com> Message-ID: <20060815130254.GN13461@neu.nirvana> On Tue, Aug 15, 2006 at 07:51:48AM -0500, Josh Boyer wrote: > > An argument against adopting kmdls presented by Thorsten Leemhuis is > > that > > > > * it's too late now to fix it, we should live on with kmod bugs for > > RHEL5's life-cycle (ending 2012 ...) > > Fedora is _not_ RHEL. Period. If they happen to use the same packaging > scheme for modules, fine. That doesn't mean that Fedora cannot change > it's standards during a particular RHEL's lifetime. I agree that Fedora is not RHEL and vice versa. But once any idiom is adopted into one of the two the other will have a very hard time to get by, the bar is raised quite a bit. Whether we like it or not (BTW I like it) the two distributions are closely related and influence each-other. > Therefore, I see no urgency in getting this changed. If kmdls is truly > a better way, then it can be adapted when it has been fully discussed. GFS is in FC6, too. Only the life-span of FC6 is shorter. Furthermore yum developers want to know what scheme will need to be supported. As argued in the wiki yum support for the current scheme is an endless story, while the new proposed scheme already has it's fully working plugin submitted. Do you really want to see developers burn more time in a lost cause? We could be using that developer time elsewhere. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Aug 15 13:27:34 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Aug 2006 09:27:34 -0400 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <1155646085.22871.43.camel@pmac.infradead.org> References: <20060815123406.GG13461@neu.nirvana> <1155646085.22871.43.camel@pmac.infradead.org> Message-ID: <200608150927.34829.jkeating@redhat.com> On Tuesday 15 August 2006 08:48, David Woodhouse wrote: > I think this argument is invalid. We should ban _all_ module packages > from Core and Extras anyway. I'm with David on this one. Packaging of modules is the path to insanity. It requires all kinds of weird hacks to how they are built, how they are named, how they are handled by rpm and depsolvers, they always lag, they always hold users behind when critical kernel fixes come out, etc, etc, etc... I personally feel (as does David) that if the module isn't good enough for upstream, then it would HAVE to live in the kernel package itself. If it's not good enough for the kernel package itself, then it isn't good enough for Fedora. (Same could be applied to RHEL, but that's a battle for a different list). Arguing over which ugly ass hack to apply to be able to package kernel modules is a bikeshed argument. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Aug 15 13:50:00 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Aug 2006 09:50:00 -0400 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <1155649223.22871.54.camel@pmac.infradead.org> References: <20060815123406.GG13461@neu.nirvana> <200608150927.34829.jkeating@redhat.com> <1155649223.22871.54.camel@pmac.infradead.org> Message-ID: <200608150950.00442.jkeating@redhat.com> On Tuesday 15 August 2006 09:40, David Woodhouse wrote: > I'm not necessarily suggesting that we shouldn't have an agreed method > of building kernel module packages at all -- just that we shouldn't have > any such packages in Core or Extras. > > There _are_ relatively sane (and legal, unlike nvidia/ati stuff) cases > where one might want to build a separate module -- like the NTFS modules > in Livna, for example. And other 'new drivers' which aren't yet > upstream. Of course you're right when you agree with me that those new > drivers shouldn't be in Core or Extras -- but that doesn't mean we > shouldn't provide a way to package them at all. Given that we don't want it on Core or Extras, I'm pretty happy to let random 3rd party packager do whatever they want for packaging modules. I'm not interested in dictating how they should handle this ugly hack. Your example about ntfs is not usable w/out the userland (ntfsprogs), which nobody wants to touch due to legal reasons, and would be obsoleted by FUSE anyway where the most recent ntfs support is done entirely in userspace. There are many more things the packaging committee can spend time worrying about. Packaging of kernel modules isn't one of them IMHO. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Aug 15 14:12:06 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 Aug 2006 16:12:06 +0200 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <1155650286.22871.72.camel@pmac.infradead.org> References: <20060815123406.GG13461@neu.nirvana> <200608150927.34829.jkeating@redhat.com> <1155649223.22871.54.camel@pmac.infradead.org> <200608150950.00442.jkeating@redhat.com> <1155650286.22871.72.camel@pmac.infradead.org> Message-ID: <44E1D636.1000502@leemhuis.info> David Woodhouse schrieb: > On Tue, 2006-08-15 at 09:50 -0400, Jesse Keating wrote: >> Given that we don't want it on Core or Extras, I'm pretty happy to >> let random 3rd party packager do whatever they want for packaging >> modules. I'm not interested in dictating how they should handle >> this ugly hack. >> >> Your example about ntfs is not usable w/out the userland >> (ntfsprogs), which nobody wants to touch due to legal reasons, and >> would be obsoleted by FUSE anyway where the most recent ntfs >> support is done entirely in userspace. >> >> There are many more things the packaging committee can spend time >> worrying about. Packaging of kernel modules isn't one of them >> IMHO. > > Yeah, that's a fair point. However, it would be useful if those who > _do_ care about kernel module packages would come to an agreement > about how it should be done, and that can be documented somewhere > central to Fedora -- like on the Fedora wiki. > > We can modify our kernel RPM and yum if appropriate in order to > support that agreed method. That already happend -- FESCo worked out and agreed on a propsoal last winter http://www.fedoraproject.org/wiki/Packaging/KernelModules It's working fine. CU thl From Axel.Thimm at ATrpms.net Tue Aug 15 15:17:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 17:17:05 +0200 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <44E1D636.1000502@leemhuis.info> References: <20060815123406.GG13461@neu.nirvana> <200608150927.34829.jkeating@redhat.com> <1155649223.22871.54.camel@pmac.infradead.org> <200608150950.00442.jkeating@redhat.com> <1155650286.22871.72.camel@pmac.infradead.org> <44E1D636.1000502@leemhuis.info> Message-ID: <20060815151705.GP13461@neu.nirvana> On Tue, Aug 15, 2006 at 04:12:06PM +0200, Thorsten Leemhuis wrote: > > > David Woodhouse schrieb: > >On Tue, 2006-08-15 at 09:50 -0400, Jesse Keating wrote: > >>Given that we don't want it on Core or Extras, I'm pretty happy to > >>let random 3rd party packager do whatever they want for packaging > >>modules. I'm not interested in dictating how they should handle > >>this ugly hack. > >> > >>Your example about ntfs is not usable w/out the userland > >>(ntfsprogs), which nobody wants to touch due to legal reasons, and > >>would be obsoleted by FUSE anyway where the most recent ntfs > >>support is done entirely in userspace. > >> > >>There are many more things the packaging committee can spend time > >>worrying about. Packaging of kernel modules isn't one of them > >>IMHO. > > > >Yeah, that's a fair point. However, it would be useful if those who > >_do_ care about kernel module packages would come to an agreement > >about how it should be done, and that can be documented somewhere > >central to Fedora -- like on the Fedora wiki. > > > >We can modify our kernel RPM and yum if appropriate in order to > >support that agreed method. > > That already happend -- FESCo worked out and agreed on a propsoal last > winter http://www.fedoraproject.org/wiki/Packaging/KernelModules > > It's working fine. No, it's not, proven in debates on fedora-packaging and here http://fedoraproject.org/wiki/AxelThimm/kmdls The proposal you worked out is leading to broken rpm and yum support. That's not working fine. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Aug 15 15:38:14 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 15 Aug 2006 10:38:14 -0500 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <20060815151705.GP13461@neu.nirvana> References: <20060815123406.GG13461@neu.nirvana> <200608150927.34829.jkeating@redhat.com> <1155649223.22871.54.camel@pmac.infradead.org> <200608150950.00442.jkeating@redhat.com> <1155650286.22871.72.camel@pmac.infradead.org> <44E1D636.1000502@leemhuis.info> <20060815151705.GP13461@neu.nirvana> Message-ID: <44E1EA66.6040602@math.unl.edu> Axel Thimm wrote: > On Tue, Aug 15, 2006 at 04:12:06PM +0200, Thorsten Leemhuis wrote: >>> We can modify our kernel RPM and yum if appropriate in order to >>> support that agreed method. >> That already happend -- FESCo worked out and agreed on a propsoal last >> winter http://www.fedoraproject.org/wiki/Packaging/KernelModules >> It's working fine. > No, it's not... Thorsten, Axel, In the hopes of furthering the discussion can we at least agree that the current kmod scheme works, at least to some people's perception of what that means. I hope, also, that we can agree that the current kmod scheme does have limitations/shortcomings. With that in mind, I think this (should) all boil down to the question: which weighs more heavily in your mind, the pain/suffering(*) of involved in 1. Adopting/changing-to a new (kmdl) standard 2. living with the limitations/shortcomings that come with using kmod. ? (*) Which brought to my mind one of my favorite movie quotes: "Life is pain, Highness. Anyone who says differently is selling something." -- Rex From jkeating at redhat.com Tue Aug 15 16:11:35 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Aug 2006 12:11:35 -0400 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <44E1EA66.6040602@math.unl.edu> References: <20060815123406.GG13461@neu.nirvana> <20060815151705.GP13461@neu.nirvana> <44E1EA66.6040602@math.unl.edu> Message-ID: <200608151211.41301.jkeating@redhat.com> On Tuesday 15 August 2006 11:38, Rex Dieter wrote: > With that in mind, I think this (should) all boil down to the question: > which weighs more heavily in your mind, the pain/suffering(*) of involved > in 1. ?Adopting/changing-to a new (kmdl) standard > 2. ?living with the limitations/shortcomings that come with using kmod. > ? 3. Kicking kernel module packages out of Core / Extras and moving the debate away from us so that we can focus on the more important things. I vote for #3. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Aug 15 17:33:07 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Aug 2006 13:33:07 -0400 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: References: <20060815123406.GG13461@neu.nirvana> <44E1EA66.6040602@math.unl.edu> Message-ID: <200608151333.07641.jkeating@redhat.com> On Tuesday 15 August 2006 13:28, Benny Amorsen wrote: > Would the same problems that we have with kernel modules appear with > e.g. apache modules, if having two different apache versions installed > was possible? Theoretically yes, however thankfully we don't really let two different apaches be installed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjneely at ncsu.edu Tue Aug 15 17:45:47 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Tue, 15 Aug 2006 13:45:47 -0400 Subject: [Fedora-packaging] Re: fedorakmod.py unfixable In-Reply-To: <20060815113220.GD13461@neu.nirvana> References: <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <20060812153310.GC22196@neu.nirvana> <20060815113220.GD13461@neu.nirvana> Message-ID: <20060815174547.GT26953@anduril.unity.ncsu.edu> On Tue, Aug 15, 2006 at 01:32:20PM +0200, Axel Thimm wrote: > Hi Jack, > > On Sat, Aug 12, 2006 at 05:33:10PM +0200, Axel Thimm wrote: > > can you please answer on the statement below that wrt fedorakmod.py > > plugin if the wrongly tagged kernel module packages pull in other > > packages through dependencies you're hosed up? > > > > Please make a statement about that as this demonstrates that the > > plugin has unfixable flaws - which is neither yum's not the plugin's > > fault, it is just the mirroring of allowing an rpm-incompatible > > kernel module scheme. > > > > I hope the correctness and maintenance issues here will persuade the > > last kmdl opponent. :) > > I moved the issues to http://fedoraproject.org/wiki/AxelThimm/kmdls > > Please check the raised issues and make a statement. The > kmod+yum+anyplugin setup just cannot work and it's the best for the > packaging folks to hear that from a third person, too. Thanks. > -- > Axel.Thimm at ATrpms.net Axel, I apologize for not making your requested statement earlier. I hope this email proves to be acceptable. I have read your Wiki article and I find several points that I do not agree with. I will focus on one of these points here. You state, in bold text, "[kmdl] doesn't have any design bugs." In fact, Seth, Jesse, Thorsten, myself and others have pointed out multiple times flaws in the kmdl kernel module packaging scheme. Some of these flaws equally affect both kmod and kmdl. Having read your numerous posts to this list regarding kmdl, the wiki article you have authored, and your Yum plugin to support kmdl I see a common theme. You are unwilling to admit that your scheme may not be absolutely perfect and are unwilling to work with others to compromise. In fact, Thorsten attempted to compromise again with you this morning and you immediately refused. The last two emails that you have sent in this thread addressed to me take this one step farther. You have requested that I make a statement regarding issues you have with the workings of the fedorakmod.py plugin. In and of itself, that is fine. However, you also tell me in both emails what my statement is to be and in the first justify why I will say such a statement. I find this attitude hostile and offensive. My statement is thus: Many people have spent a large amount of time working with the kmod standard in developing the standard to this point and preparing FC6, FE6, and RHEL5 to make use of this standard. The kmod standard represents a significant step forward in kernel module packaging compared to older methods that I and many others have used in the past. The proposed kmdl scheme does not offer a significant improvement in design or practice compared to the kmod standard. It is simply a different selection of pros and cons. Jack > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From rdieter at math.unl.edu Tue Aug 15 17:53:00 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 15 Aug 2006 12:53:00 -0500 Subject: [Fedora-packaging] Re: fedorakmod.py unfixable In-Reply-To: <20060815174547.GT26953@anduril.unity.ncsu.edu> References: <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <20060812153310.GC22196@neu.nirvana> <20060815113220.GD13461@neu.nirvana> <20060815174547.GT26953@anduril.unity.ncsu.edu> Message-ID: <44E209FC.4030307@math.unl.edu> Jack Neely wrote: > On Tue, Aug 15, 2006 at 01:32:20PM +0200, Axel Thimm wrote: > You (Axel) are unwilling to admit that your scheme may not be > absolutely perfect and are unwilling to work with others to compromise. My $0.02 again, I think *both* sides, to a certain degree, are guilty of this. -- Rex From Axel.Thimm at ATrpms.net Tue Aug 15 18:22:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 20:22:27 +0200 Subject: [Fedora-packaging] Re: fedorakmod.py unfixable In-Reply-To: <20060815174547.GT26953@anduril.unity.ncsu.edu> References: <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <20060812153310.GC22196@neu.nirvana> <20060815113220.GD13461@neu.nirvana> <20060815174547.GT26953@anduril.unity.ncsu.edu> Message-ID: <20060815182227.GB31789@neu.nirvana> On Tue, Aug 15, 2006 at 01:45:47PM -0400, Jack Neely wrote: > On Tue, Aug 15, 2006 at 01:32:20PM +0200, Axel Thimm wrote: > > Hi Jack, > > > > On Sat, Aug 12, 2006 at 05:33:10PM +0200, Axel Thimm wrote: > > > can you please answer on the statement below that wrt fedorakmod.py > > > plugin if the wrongly tagged kernel module packages pull in other > > > packages through dependencies you're hosed up? > > > > > > > Please make a statement about that as this demonstrates that the > > > plugin has unfixable flaws - which is neither yum's not the plugin's > > > fault, it is just the mirroring of allowing an rpm-incompatible > > > kernel module scheme. > > > > > > I hope the correctness and maintenance issues here will persuade the > > > last kmdl opponent. :) > > > > I moved the issues to http://fedoraproject.org/wiki/AxelThimm/kmdls > > > > Please check the raised issues and make a statement. The > > kmod+yum+anyplugin setup just cannot work and it's the best for the > > packaging folks to hear that from a third person, too. Thanks. > > Axel, > > I apologize for not making your requested statement earlier. I hope > this email proves to be acceptable. > > I have read your Wiki article and I find several points that I do not > agree with. I will focus on one of these points here. You state, in > bold text, "[kmdl] doesn't have any design bugs." In fact, Seth, > Jesse, Thorsten, myself and others have pointed out multiple times flaws > in the kmdl kernel module packaging scheme. Some of these flaws equally > affect both kmod and kmdl. Please show me the *flaws*! The kmdl scheme perfectly blends into rpm semantics. > Having read your numerous posts to this list regarding kmdl, the wiki > article you have authored, and your Yum plugin to support kmdl I see a > common theme. You are unwilling to admit that your scheme may not be > absolutely perfect and are unwilling to work with others to compromise. > In fact, Thorsten attempted to compromise again with you this morning > and you immediately refused. That's wrong. I myself had stated often enough that I don't like uname-r-in-name. It is not "perfect" it is a neccessity given the current packaging limitations. And how exactly does the kmdl plugin tell you that I'm unwilling to admit anything at all? > The last two emails that you have sent in this thread addressed to me > take this one step farther. You have requested that I make a statement > regarding issues you have with the workings of the fedorakmod.py plugin. Yes, please and the request stands. > In and of itself, that is fine. However, you also tell me in both > emails what my statement is to be and in the first justify why I will > say such a statement. I find this attitude hostile and offensive. Oh, no, please do make your statement on your behalf. You certainly don't need patronizing. > My statement is thus: Many people have spent a large amount of time > working with the kmod standard in developing the standard to this point > and preparing FC6, FE6, and RHEL5 to make use of this standard. The > kmod standard represents a significant step forward in kernel module > packaging compared to older methods that I and many others have used in > the past. The proposed kmdl scheme does not offer a significant > improvement in design or practice compared to the kmod standard. It is > simply a different selection of pros and cons. So where is the statement? You are talking abstractly about kmdls and kmods and I wrote explicitely about where and how fedorakmod.py is broken. I'd like a statement about the possibility of yum working properly with kmod. The thesis that is given in the wiki is - that fedorakmod is currently broken, - that any future attempt to fix it breaks it even more, - that it is therefore unfixable with limited man power That's where I'd like you to either stand up and say Axel's halucinating or to concurr with the outlayed facts. That's far more valuable than quoting "kmod standard represents a significant step forward", we want technical facts, not a marketing blob :) Please the request for making a statement about current and future yum support of kmods still stands. If you admit it's broken people will make easier a decision. If you prove it's not broken or if broken fixable with few steps then it will also help people decide. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjneely at ncsu.edu Tue Aug 15 18:52:17 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Tue, 15 Aug 2006 14:52:17 -0400 Subject: [Fedora-packaging] Re: fedorakmod.py unfixable In-Reply-To: <44E209FC.4030307@math.unl.edu> References: <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <20060812153310.GC22196@neu.nirvana> <20060815113220.GD13461@neu.nirvana> <20060815174547.GT26953@anduril.unity.ncsu.edu> <44E209FC.4030307@math.unl.edu> Message-ID: <20060815185217.GU26953@anduril.unity.ncsu.edu> On Tue, Aug 15, 2006 at 12:53:00PM -0500, Rex Dieter wrote: > Jack Neely wrote: > >On Tue, Aug 15, 2006 at 01:32:20PM +0200, Axel Thimm wrote: > >You (Axel) are unwilling to admit that your scheme may not be > >absolutely perfect and are unwilling to work with others to compromise. > > My $0.02 again, I think *both* sides, to a certain degree, are guilty of > this. You are probably right. Can Axel come up with examples that make kmod and my code break miserably? Yes. We've all stated that the kmod scheme isn't perfect. I remember none of us being overly happy when we agreed to it. However, I too can come up with examples that make kmdl and his Yum plugin break just as well. Several folks have discussed them. This hasn't swayed Axel. I'm starting to think that Jesse is right. Kernel modules don't belong here. We have a couple good suggestions and sem-workable code for them. Hopefully they will be supplanted by the kabi stuff in the near future as I think that shows a lot of promise. Perhaps offering several suggestions for packaging kernel modules to the community is what we do along with banning them from FC/FE. I don't like that at all but I'd agree to it. Jack > > -- Rex > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From Axel.Thimm at ATrpms.net Tue Aug 15 19:05:54 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 Aug 2006 21:05:54 +0200 Subject: [Fedora-packaging] Re: fedorakmod.py unfixable In-Reply-To: <20060815185217.GU26953@anduril.unity.ncsu.edu> References: <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <20060812153310.GC22196@neu.nirvana> <20060815113220.GD13461@neu.nirvana> <20060815174547.GT26953@anduril.unity.ncsu.edu> <44E209FC.4030307@math.unl.edu> <20060815185217.GU26953@anduril.unity.ncsu.edu> Message-ID: <20060815190554.GI31789@neu.nirvana> On Tue, Aug 15, 2006 at 02:52:17PM -0400, Jack Neely wrote: > Can Axel come up with examples that make kmod and my code break > miserably? Yes. We've all stated that the kmod scheme isn't perfect. > I remember none of us being overly happy when we agreed to it. > > However, I too can come up with examples that make kmdl and his Yum > plugin break just as well. Several folks have discussed them. This > hasn't swayed Axel. Can you point me to that? In the context of kmdl + yum-plugin. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From benny+usenet at amorsen.dk Tue Aug 15 17:28:31 2006 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 15 Aug 2006 19:28:31 +0200 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! References: <20060815123406.GG13461@neu.nirvana> <200608150927.34829.jkeating@redhat.com> <1155649223.22871.54.camel@pmac.infradead.org> <200608150950.00442.jkeating@redhat.com> <1155650286.22871.72.camel@pmac.infradead.org> <44E1D636.1000502@leemhuis.info> <20060815151705.GP13461@neu.nirvana> <44E1EA66.6040602@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> In the hopes of furthering the discussion can we at least agree RD> that the current kmod scheme works, at least to some people's RD> perception of what that means. I hope, also, that we can agree RD> that the current kmod scheme does have limitations/shortcomings. RD> With that in mind, I think this (should) all boil down to the RD> question: which weighs more heavily in your mind, the RD> pain/suffering(*) of involved in 1. Adopting/changing-to a new RD> (kmdl) standard 2. living with the limitations/shortcomings that RD> come with using kmod. ? Would the same problems that we have with kernel modules appear with e.g. apache modules, if having two different apache versions installed was possible? /Benny From lists at timj.co.uk Tue Aug 15 21:42:36 2006 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 15 Aug 2006 22:42:36 +0100 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <200608151211.41301.jkeating@redhat.com> References: <20060815123406.GG13461@neu.nirvana> <20060815151705.GP13461@neu.nirvana> <44E1EA66.6040602@math.unl.edu> <200608151211.41301.jkeating@redhat.com> Message-ID: <44E23FCC.2000402@timj.co.uk> Jesse Keating wrote: > 3. Kicking kernel module packages out of Core / Extras and moving the debate > away from us so that we can focus on the more important things. I vote for > #3. This one has come out of left-field to me. Nobody AFAIK has previously proposed throwing out kernel modules altogether. I also don't think it makes sense because, notwithstanding the RPM problems, there are plenty of useful kernel modules that exist and are maintained (for various reasons, good or bad, right or wrong) outside the kernel tree. I don't see why kernel modules are any less useful than other random FE packages, just because they're in kernel space. FE is supposed to be a maximal set of software, right? That's at odds with a rule disallowing any kernel modules. Why shouldn't kernel modules be included, exactly? Excluding them just because of the problems with packaging seems rather like throwing the baby out with the bath water. FWIW, although the kmod stuff seems "nicer" in a way, I've been relatively convinced by what Axel has had to say about kmdl. They're both trying to make the best of a bad job; kmdl seems to have slightly fewer problems. And for those that say RHEL is nothing to do with Fedora: true theoretically, but if you look at: a) the number of Fedora devs who are RH employees b) the number of Fedora users who also use/build packages for RHEL and derivatives either for work, fun or both then I think it's worth at least *considering* the potential annoyance/confusion of RHEL/Fedora having two different schemes. Regardless of the outcome I'd like to thank Axel in particular and all the other contributors to the debate so far for their time and energy. I don't think anyone finds this stuff terribly exciting as I think we'd all rather be *using* packages than debating the finer details of which packaging scheme is better than another, but this stuff is important in the big picture both of getting the best technical solution and making Fedora the best distro with a wide choice of well-packaged software. Whilst we shouldn't pander to any special interest, I do believe it's in all our interests to at least pay serious attention to the input from well-established third party contributors like Axel who have done so much in the past few years to bring a large base of add-on software to RHL/RHEL/Fedora. They have very useful practical experience of various techniques applied to a relatively large audience and this knowledge (and established packages) can only benefit Fedora. Tim From jkeating at redhat.com Tue Aug 15 22:03:29 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Aug 2006 18:03:29 -0400 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <44E23FCC.2000402@timj.co.uk> References: <20060815123406.GG13461@neu.nirvana> <200608151211.41301.jkeating@redhat.com> <44E23FCC.2000402@timj.co.uk> Message-ID: <200608151803.29216.jkeating@redhat.com> On Tuesday 15 August 2006 17:42, Tim Jackson wrote: > This one has come out of left-field to me. Nobody AFAIK has previously > proposed throwing out kernel modules altogether. David Woodhouse proposed it weeks ago. I've gotten tired enough of this discussion and noticed the ways that BOTH methods suck arse that I'm inclined to agree with David that packaging of kernel modules is just not something an RPM based distro is capable of handling in a clean way. There are more philosophical reasons to not allow kernel modules, but I go into that. > I also don't think it > makes sense because, notwithstanding the RPM problems, there are plenty > of useful kernel modules that exist and are maintained (for various > reasons, good or bad, right or wrong) outside the kernel tree. This doesn't mean there are room for them in the Fedora project. Bad reasons should be fixed. Good reasons (like illegal to be in kernel or closed source) are unacceptable for the Fedora project. Once free, always free. > I don't > see why kernel modules are any less useful than other random FE > packages, just because they're in kernel space. FE is supposed to be a > maximal set of software, right? No, a maximal set of ACCEPTABLE and non-forbidden software that can be maintained. There are "useful" things that aren't acceptable. Certain encryption methods due to US restrictions on the exporting of them. Emulators are not acceptable. Some forms of content are not allowed either: * Comic book art files * Religious texts * mp3 files (patent encumbered) > That's at odds with a rule disallowing > any kernel modules. Why shouldn't kernel modules be included, exactly? > Excluding them just because of the problems with packaging seems rather > like throwing the baby out with the bath water. Technical reasons: By nature they always lag. They will prevent a user from being able to update to new kernels, which could prevent them from getting critical security fixes. Without hand deselecting packages for updates, this could also prevent ANY updates from being applied. Worse, the updates (and new kernel) could be installed and the module would not be available, preventing the system from functioning. Supportability. External modules can and do introduce bugs into the running kernel. They can have adverse but hard to realize problems in a running system. The kernel gets the blame, and bugzilla gets overrun with false reports that have nothing to do with the kernel rpm, and everything to do with the addon module. Expecting the kernel maintainer to sort these out and triage takes away from his/her precious time. These are a couple really good reasons in my book to not allow it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Tue Aug 15 23:14:15 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 15 Aug 2006 19:14:15 -0400 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <200608151803.29216.jkeating@redhat.com> References: <20060815123406.GG13461@neu.nirvana> <200608151211.41301.jkeating@redhat.com> <44E23FCC.2000402@timj.co.uk> <200608151803.29216.jkeating@redhat.com> Message-ID: <1155683655.13127.3.camel@shuttle.piedmont.com> On Tue, 2006-08-15 at 18:03 -0400, Jesse Keating wrote: > > No, a maximal set of ACCEPTABLE and non-forbidden software that can be > maintained. There are "useful" things that aren't acceptable. Certain > encryption methods due to US restrictions on the exporting of them. > Emulators are not acceptable. Some forms of content are not allowed either: > > * > > Comic book art files > * > > Religious texts Doesn't FE have sword & gnomesword in it? Based on it's description it sounds like it contains religious text. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Wed Aug 16 00:16:26 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 15 Aug 2006 20:16:26 -0400 Subject: [Fedora-packaging] Kernel Module Packaging Standard Teleconference Message-ID: <44E263DA.2030806@redhat.com> After weeks of discourse on IRC and mailing list discussions, we seem to be unable to make progress toward an amicable agreement. What seems to be the issue is that RPM does not allow any clean solution to the kernel module packaging problem. Both kmod and kmdl are comprised of ugly hacks in order to overcome the design limitations of RPM. Both kmod and kmdl have pros and cons, and neither is a clearly agreed by all parties as being technically superior. The FESCO side is disconcerted by this situation because a great deal of effort over years was put into making and ratifying today's kmod standard. On the other hand, there is some hope for middle-ground because of stated willingness to further revise kmod to overcome remaining limitations. It is the decision of me, Max, and Spot, to put a hold on publishing any further kmod modules pending the result the Kernel Module Packaging Standard conference call. Time/date of this call is to be determined, but we are aiming for this Friday, August 18th at a time that is workable for both American EDT and Europe. Perhaps 1PM EDT would work, the usual timeslot of FESCO meetings? Perhaps this timeslot wont work. If you feel it is important to attend but you are unable to make this time, please make it known in this thread. In order to make this meeting manageable, we must limit the number of attendees. Invited are the existing members of the Fedora Packaging Committee, Thorsten Leemhuis and certain Red Hat employees relevant to this discussion. Please talk to me directly if you have been an active contributor to this in the past but are not included in this invitee list. My personal feeling is that it is way too late to throw out kmod, OTOH it is important that we discuss each point to see if kmod can be improved. If the packaging committee cannot come to key agreements, then the matter will be escalated to the Fedora Project Board who will make the key decisions. Warren Togami wtogami at redhat.com From fedora at leemhuis.info Wed Aug 16 04:47:33 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 Aug 2006 06:47:33 +0200 Subject: [Fedora-packaging] Kernel Module Packaging Standard Teleconference In-Reply-To: <44E263DA.2030806@redhat.com> References: <44E263DA.2030806@redhat.com> Message-ID: <44E2A365.1050102@leemhuis.info> Warren Togami schrieb: > After weeks of discourse on IRC and mailing list discussions, [...] > In order to make this meeting manageable, we must limit the number of > attendees. Invited are the existing members of the Fedora Packaging > Committee, Thorsten Leemhuis and certain Red Hat employees relevant to > this discussion. Please talk to me directly if you have been an active > contributor to this in the past but are not included in this invitee list. There were no discussions on IRC (Axel invited me once but I couldn't join it -- private matters were blocking, sorry). I really would prefer a IRC disussion over a Teleconference -- that's IMHO the better to coordinate and a lot easier for those of us that don't speak english that often. CU thl From wtogami at redhat.com Wed Aug 16 06:11:26 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 16 Aug 2006 02:11:26 -0400 Subject: [Fedora-packaging] Kernel Module Packaging Standard Teleconference In-Reply-To: <44E2A365.1050102@leemhuis.info> References: <44E263DA.2030806@redhat.com> <44E2A365.1050102@leemhuis.info> Message-ID: <44E2B70E.2030409@redhat.com> Thorsten Leemhuis wrote: > > > Warren Togami schrieb: >> After weeks of discourse on IRC and mailing list discussions, > > [...] > >> In order to make this meeting manageable, we must limit the number of >> attendees. Invited are the existing members of the Fedora Packaging >> Committee, Thorsten Leemhuis and certain Red Hat employees relevant to >> this discussion. Please talk to me directly if you have been an >> active contributor to this in the past but are not included in this >> invitee list. > > There were no discussions on IRC (Axel invited me once but I couldn't > join it -- private matters were blocking, sorry). I really would prefer > a IRC disussion over a Teleconference -- that's IMHO the better to > coordinate and a lot easier for those of us that don't speak english > that often. > Hmm, good point about English, it could very well make it difficult for us to communicate. The idea of the teleconference was our crazy American idea. That's how we often do things... The important thing is for someone neutral to drive the process, hopefully Spot can do it. The driver of this meeting must act as mediator. We must all stay away from recriminations and stick to the technical points. Go down all questions and concerns and discuss each point. If someone doesn't understand then implications must be explained. Then matters must come down to a vote after context is understood. Perhaps given this format, IRC may work better. We can think about this a bit more as we also figure out if all of the key players are available at that time on Friday. We'll see. Warren Togami wtogami at redhat.com From fedora at leemhuis.info Wed Aug 16 06:35:18 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 Aug 2006 08:35:18 +0200 Subject: [Fedora-packaging] Kernel Module Packaging Standard Teleconference In-Reply-To: <44E2B70E.2030409@redhat.com> References: <44E263DA.2030806@redhat.com> <44E2A365.1050102@leemhuis.info> <44E2B70E.2030409@redhat.com> Message-ID: <44E2BCA6.6050805@leemhuis.info> Warren Togami schrieb: > Thorsten Leemhuis wrote: >> Warren Togami schrieb: >>> After weeks of discourse on IRC and mailing list discussions, >> [...] >>> In order to make this meeting manageable, we must limit the number of >>> attendees. Invited are the existing members of the Fedora Packaging >>> Committee, Thorsten Leemhuis and certain Red Hat employees relevant >>> to this discussion. Please talk to me directly if you have been an >>> active contributor to this in the past but are not included in this >>> invitee list. >> There were no discussions on IRC (Axel invited me once but I couldn't >> join it -- private matters were blocking, sorry). I really would >> prefer a IRC disussion over a Teleconference -- that's IMHO the better >> to coordinate and a lot easier for those of us that don't speak >> english that often. > > Hmm, good point about English, it could very well make it difficult for > us to communicate. IRC IMHO has even one more benefit that would help in this especially in this case: You can paste URLs to mails in the archive or on the web. Further: multiple people can write in parallel (that's a advantage and a disadvantage at the same time). A disadvantage of telephone conferences: they often consume all of your attention -- in an IRC-Meeing you can go afk for one minute if there is a need to and read what happened in between > The important thing is for someone neutral to drive the process, > hopefully Spot can do it. The driver of this meeting must act as > mediator. We must all stay away from recriminations and stick to the > technical points. Go down all questions and concerns and discuss each > point. If someone doesn't understand then implications must be explained. Agreed. > Then matters must come down to a vote after context is understood. Just to make sure: One vote per "technical point"? > Perhaps given this format, IRC may work better. +1 > We can think about this > a bit more as we also figure out if all of the key players are available > at that time on Friday. We'll see. k CU thl From rc040203 at freenet.de Wed Aug 16 08:08:37 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 Aug 2006 10:08:37 +0200 Subject: [Fedora-packaging] Kernel Module Packaging Standard Teleconference In-Reply-To: <44E263DA.2030806@redhat.com> References: <44E263DA.2030806@redhat.com> Message-ID: <1155715718.27621.120.camel@mccallum.corsepiu.local> On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: > After weeks of discourse on IRC and mailing list discussions, we seem to > be unable to make progress toward an amicable agreement. > > What seems to be the issue is that RPM does not allow any clean solution > to the kernel module packaging problem. Both kmod and kmdl are > comprised of ugly hacks in order to overcome the design limitations of > RPM. Both kmod and kmdl have pros and cons, and neither is a clearly > agreed by all parties as being technically superior. > > The FESCO side is disconcerted by this situation because a great deal of > effort over years was put into making and ratifying today's kmod > standard. On the other hand, there is some hope for middle-ground > because of stated willingness to further revise kmod to overcome > remaining limitations. As I didn't have the time to follow all these discussions and threads, and to have a basis for such an IRC-conference, I would appreciate if Axel and Thorsten could write up a "my proposal at one glance" outline. I would be particularly interested in their proposals's macroscopic behavior and interaction with rpmbuild, mock, rpm -U|-I, the impact on yum/apt/smart. > If the packaging committee cannot come to key agreements, then the > matter will be escalated to the Fedora Project Board who will make the > key decisions. "Order di Mufti" as we call this in German, the worst of all management principles :( Ralf From Axel.Thimm at ATrpms.net Wed Aug 16 09:20:22 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 11:20:22 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <44E263DA.2030806@redhat.com> References: <44E263DA.2030806@redhat.com> Message-ID: <20060816092022.GA13101@neu.nirvana> Hi Warren, On Tue, Aug 15, 2006 at 08:16:26PM -0400, Warren Togami wrote: > After weeks of discourse on IRC and mailing list discussions, we > seem to be unable to make progress toward an amicable agreement. > [...] If the packaging committee cannot come to key agreements, > then the matter will be escalated to the Fedora Project Board who > will make the key decisions. there was a staged unbundled voting proposal last week: https://www.redhat.com/archives/fedora-packaging/2006-August/msg00061.html and there are three people that voted (2 in favor, one against), then Thorsten has strongly voiced concerns about the investment into the old scheme and people stopped voting while the discussions were up again. I'm in favor of anything that will speed up the voting process or bring in any decision, I think the idea of bringing together all relevant parties is a very good one. > In order to make this meeting manageable, we must limit the number of > attendees. Invited are the existing members of the Fedora Packaging > Committee, Thorsten Leemhuis and certain Red Hat employees relevant to > this discussion. Please talk to me directly if you have been an active > contributor to this in the past but are not included in this invitee list. I would like to suggest Jack Neely and Seth Vital. The latter as a neutral authority on yum and friends to judge on the technical issues raised and the former as the author of the yum support for kmod which IMHO is not working and connot be made to work as well as a big opponent of the new scheme. A working yum is a key point and it would be good to have a fast return of feedback. If they can be convinced that the kmod scheme is unsupportable from yum's POV we're already almost done. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Wed Aug 16 09:20:32 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 Aug 2006 11:20:32 +0200 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <1155683655.13127.3.camel@shuttle.piedmont.com> References: <20060815123406.GG13461@neu.nirvana> <200608151211.41301.jkeating@redhat.com> <44E23FCC.2000402@timj.co.uk> <200608151803.29216.jkeating@redhat.com> <1155683655.13127.3.camel@shuttle.piedmont.com> Message-ID: <1155720032.27621.124.camel@mccallum.corsepiu.local> On Tue, 2006-08-15 at 19:14 -0400, Brian Pepple wrote: > On Tue, 2006-08-15 at 18:03 -0400, Jesse Keating wrote: > > > > No, a maximal set of ACCEPTABLE and non-forbidden software that can be > > maintained. There are "useful" things that aren't acceptable. Certain > > encryption methods due to US restrictions on the exporting of them. > > Emulators are not acceptable. Some forms of content are not allowed either: > > > > * > > > > Comic book art files > > * > > > > Religious texts > > Doesn't FE have sword & gnomesword in it? Based on it's description it sounds like > it contains religious text. ... And these had been an issue when they had been under review. Ralf From Axel.Thimm at ATrpms.net Wed Aug 16 09:26:41 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 11:26:41 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <44E2BCA6.6050805@leemhuis.info> References: <44E263DA.2030806@redhat.com> <44E2A365.1050102@leemhuis.info> <44E2B70E.2030409@redhat.com> <44E2BCA6.6050805@leemhuis.info> Message-ID: <20060816092641.GB13101@neu.nirvana> On Wed, Aug 16, 2006 at 08:35:18AM +0200, Thorsten Leemhuis wrote: > > > Warren Togami schrieb: > >Thorsten Leemhuis wrote: > >>Warren Togami schrieb: > >>>After weeks of discourse on IRC and mailing list discussions, > >> [...] > >>>In order to make this meeting manageable, we must limit the number of > >>>attendees. Invited are the existing members of the Fedora Packaging > >>>Committee, Thorsten Leemhuis and certain Red Hat employees relevant > >>>to this discussion. Please talk to me directly if you have been an > >>>active contributor to this in the past but are not included in this > >>>invitee list. > >>There were no discussions on IRC (Axel invited me once but I couldn't > >>join it -- private matters were blocking, sorry). I really would > >>prefer a IRC disussion over a Teleconference -- that's IMHO the better > >>to coordinate and a lot easier for those of us that don't speak > >>english that often. > > > >Hmm, good point about English, it could very well make it difficult for > >us to communicate. I wouldn't mind and the main disputants here are non-English natives both. It would be probably the rest not understanding our pronounciation ;) > IRC IMHO has even one more benefit that would help in this especially in > this case: You can paste URLs to mails in the archive or on the web. We can fire up an IRC session in parallel to paste in things. > Further: multiple people can write in parallel (that's a advantage and a > disadvantage at the same time). A disadvantage of telephone conferences: > they often consume all of your attention -- in an IRC-Meeing you can go > afk for one minute if there is a need to and read what happened in between That's the real disadvantage of IRC: You wait for someone's reply who went on doing other things and while waiting you decide to do other stuff yourself. In a typical IRC session there is a round-about in dialogs of 5/minute while voice gets up to 15/minute. I'm in for any form, IRC sessions have the big advantage of being archivable and searchable. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 16 10:43:01 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 12:43:01 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155715718.27621.120.camel@mccallum.corsepiu.local> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> Message-ID: <20060816104301.GC13101@neu.nirvana> On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote: > On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: > As I didn't have the time to follow all these discussions and threads, > and to have a basis for such an IRC-conference, I would appreciate if > Axel and Thorsten could write up a "my proposal at one glance" outline. I setup an executive summary of the comparison for you and for other people external to the discussion until now who would like to join in on Friday: http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance and the details remain under http://fedoraproject.org/wiki/AxelThimm/kmdls So if something looks unclear in the tabular summary please check the second link for a more verbose version. > I would be particularly interested in their proposals's macroscopic > behavior and interaction with rpmbuild, mock, rpm -U|-I, the impact on > yum/apt/smart. I tried to add every issue that has been raised to date. And I have even rated the issues in an objective and fair manner as possible (I added all arguments against kmdls and even rated them negative). I invite anyone to add his ratings, too. While the single items are all factually correct (nobody really denies the technical background anymore) the differences between kmdl and kmod opponents are in the personal weighing of consequences. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jcm at redhat.com Wed Aug 16 10:59:05 2006 From: jcm at redhat.com (Jon Masters) Date: Wed, 16 Aug 2006 11:59:05 +0100 Subject: [Fedora-packaging] Re: fedorakmod.py unfixable In-Reply-To: <20060815185217.GU26953@anduril.unity.ncsu.edu> References: <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> <44CCD892.5060306@leemhuis.info> <20060806182430.GB27561@neu.nirvana> <20060807140013.GK5520@anduril.unity.ncsu.edu> <20060807145414.GH27561@neu.nirvana> <20060812153310.GC22196@neu.nirvana> <20060815113220.GD13461@neu.nirvana> <20060815174547.GT26953@anduril.unity.ncsu.edu> <44E209FC.4030307@math.unl.edu> <20060815185217.GU26953@anduril.unity.ncsu.edu> Message-ID: <1155725945.9148.481.camel@localhost.localdomain> On Tue, 2006-08-15 at 14:52 -0400, Jack Neely wrote: > I'm starting to think that Jesse is right. Kernel modules don't belong > here. We have a couple good suggestions and sem-workable code for them. > Hopefully they will be supplanted by the kabi stuff in the near future as > I think that shows a lot of promise. Ok. A few comments here. I'm sorry I've not shouted too much before but I'm trying to listen rather than come into this group with too strong an opinion. I am very interested in discussing what we can do in the longer term about module packaging via IRC/whatever if it's useful toward reaching consensus, but I'm the new guy here so you tell me! :-) At the moment, the kABI stuff is a small addition to kmods. I changed the kmodtool slightly (couple of lines of patch, attached a version) so that we depend upon kABI and remove the dependency on a particular kernel package version. All of that is in rawhide right now and has actually been for a while - but not so useful with no "stable" kABI. I modified the kernel package build so that a new tool, kabitool, determines the groupings of ABI dependencies that are generated (it's all to work around limitations in RPM for the moment) and can take a config file that specifies these groupings too - so in the future, we could group things like the module struct, printk and other stuff that changes little but is a common dep. into its own dep. grouping. That would help when not having a stable kABI, but only a little. Still, we don't have a stable kABI in Fedora (and that includes locking hierarchies that aren't automatically checked at the moment) so I am keen to avoid overselling ABI matching to the Fedora user base. I am, however working on some patches (as upstream maintainer of m-i-t) to allow depmod to be given explicit module priorities for multiple matching names under /lib/modules. This will allow us to override which modules will be selected by insmod/modprobe through a simple conf.d. I am hoping to get that stuff out into rawhide this week and available. Jon. -- Jon Masters Phone: +44 7776 131337 Red Hat UK, Ltd. Email: jcm at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: kmodtool Type: application/x-shellscript Size: 5959 bytes Desc: not available URL: From jamatos at fc.up.pt Wed Aug 16 11:28:45 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Wed, 16 Aug 2006 12:28:45 +0100 Subject: [Fedora-packaging] Re: Attention kernel module project packagers! In-Reply-To: <1155720032.27621.124.camel@mccallum.corsepiu.local> References: <20060815123406.GG13461@neu.nirvana> <1155683655.13127.3.camel@shuttle.piedmont.com> <1155720032.27621.124.camel@mccallum.corsepiu.local> Message-ID: <200608161228.45407.jamatos@fc.up.pt> On Wednesday 16 August 2006 10:20, Ralf Corsepius wrote: > ... And these had been an issue when they had been under review. AFAIR the packages only have the readers, not the texts. > Ralf -- Jos? Ab?lio From skvidal at linux.duke.edu Wed Aug 16 12:51:46 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 16 Aug 2006 08:51:46 -0400 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <20060816092022.GA13101@neu.nirvana> References: <44E263DA.2030806@redhat.com> <20060816092022.GA13101@neu.nirvana> Message-ID: <1155732707.6762.37.camel@cutter> On Wed, 2006-08-16 at 11:20 +0200, Axel Thimm wrote: > I would like to suggest Jack Neely and Seth Vital. The latter as a > neutral authority on yum and friends to judge on the technical issues > raised and the former as the author of the yum support for kmod which > IMHO is not working and connot be made to work as well as a big > opponent of the new scheme. A working yum is a key point and it would > be good to have a fast return of feedback. If they can be convinced > that the kmod scheme is unsupportable from yum's POV we're already > almost done. umm, no. I'm not getting dragged into this. What the kmod plugin does is what it does and it has worked for me for the cases I have (which is only openafs). But I'm not going to be a judge of anything. I'm not on the packaging committee, anyway. -sv -sv From ville.skytta at iki.fi Wed Aug 16 13:46:10 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 16 Aug 2006 16:46:10 +0300 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <20060816104301.GC13101@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> Message-ID: <1155735970.15307.250.camel@localhost.localdomain> On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote: > I setup an executive summary of the comparison for you and for other > people external to the discussion until now who would like to join in > on Friday: > > http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance I'm almost certainly unable to join any meeting before next week (including tomorrow's packaging and fesco meetings) and will have only very limited access to mail during that time too. It's unlikely that my general opinion about this stuff would change, so it's not really necessary for me to attend the meeting -- don't postpone it for me. To reiterate: if consensus says change is needed, and there's competent manpower available to take care of things *soon*, so be it. The only things I feel strongly about are that rejecting module packages from FC/FE altogether would be profoundly odd at this point, and that the scope of the discussion needs to be limited to whether uname-r gets moved to the packages' names and its direct unavoidable consequences -- the only real technical design issue. Everything else in the "kmdl" proposal is more or less cosmetics and implementation details, and adopting it would mean throwing away quite a bit of work (reinventing the wheel from the POV of the current scheme and its adopters) from several parties for questionable gain. http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName This draft has potential. If it comes down to a vote, mine can be registered as: * -1 for rejecting module packages * +0.5 for moving uname-r *if* there is strong evidence that it will be acceptable for all major stakeholders (Fedora, RHEL, kerneldrivers.org in particular), -0.5 otherwise * -1 to other kmdl change suggestions (BTW, this is off topic, but if this discussion fails to produce useful widely accepted results, I wouldn't outright reject DKMS or DKMS-like mechanisms as an alternative; while these don't meet everyone's requirements, they'd be vastly better than nothing at all.) > While the single items are all factually correct Strong words. The above summary and the detailed doc contains several inaccuracies and omissions (eg. about agnosticity, flexibility, buildsys support, kabi, support(ability) in other distros etc), luckily mostly in the less important parts. I guess this is due to not understanding all aspects of the current scheme and the environment it is designed to work in. I won't spend time detailing those because I don't have time to do that right now, and even if I had, IMO there are no real reasons to consider/discuss its adoption besides the uname-r move bit. (Yes, sucky statement, but shrug, it's the best I can do in the time I have available for this at the moment.) From fedora at leemhuis.info Wed Aug 16 14:18:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 Aug 2006 16:18:28 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155735970.15307.250.camel@localhost.localdomain> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155735970.15307.250.camel@localhost.localdomain> Message-ID: <44E32934.6040009@leemhuis.info> Ville Skytt? schrieb: > On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote: > and that the > scope of the discussion needs to be limited to whether uname-r gets > moved to the packages' names and its direct unavoidable consequences -- > the only real technical design issue. I agree that this is the only "only real technical design issue" of the current standard. But I'd don't think that we hastily should change this detail. Two weeks should be enough to look at this precise problem closer and work out and test the solutions (one solution of course is uname-r, but I *currently* think it's not the best one -- especially not for RHEL, where the uname -r might be confusing). I roughly another way how this might be fixed in https://www.redhat.com/archives/fedora-packaging/2006-August/msg00086.html already. > Everything else in the "kmdl" > proposal is more or less cosmetics and implementation details, and > adopting it would mean throwing away quite a bit of s/a bit/a lot of/ IMHO -- it were probably around 15 to 20 IRC meetings IIRC (probably even more) and a lot of traffic on the mailinglists where FESCo (including jeremy and spot) discussed each and every detail in depth. We even evaluated most of the stuff that's made different in the kmdl scheme during that phase. We for example looked at a debuginfo solution similar to the one in Axels kmdls and chose not to use it; we looked at a one srpm approach for both userland and kernel-module and decided to split. That are -- as scop outlined above -- implementation details that are already used in some packages in Extras, under Review for Extras and another repo that's using the same scheme. We IMHO shouldn't change them without a good reason. > work (reinventing > the wheel from the POV of the current scheme and its adopters) from > several parties for questionable gain. Otherwise I'm strongly in agreement with that paragraph. [...] CU thl From bpepple at fedoraproject.org Wed Aug 16 14:18:58 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 16 Aug 2006 10:18:58 -0400 Subject: [Fedora-packaging] Re: Forbidden software in FE In-Reply-To: <1155720032.27621.124.camel@mccallum.corsepiu.local> References: <20060815123406.GG13461@neu.nirvana> <200608151211.41301.jkeating@redhat.com> <44E23FCC.2000402@timj.co.uk> <200608151803.29216.jkeating@redhat.com> <1155683655.13127.3.camel@shuttle.piedmont.com> <1155720032.27621.124.camel@mccallum.corsepiu.local> Message-ID: <1155737938.20909.5.camel@shuttle.piedmont.com> On Wed, 2006-08-16 at 11:20 +0200, Ralf Corsepius wrote: > On Tue, 2006-08-15 at 19:14 -0400, Brian Pepple wrote: > > > > Doesn't FE have sword & gnomesword in it? Based on it's description it sounds like > > it contains religious text. > ... And these had been an issue when they had been under review. > Yeah, looks like this was approved for FE back when we were doing reviews on the mailing list. Do these packages need to be looked at again to make sure that they should be in FE? I actually haven't used them, so I'm not sure if they actually contain forbidden content. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Wed Aug 16 16:46:51 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 16 Aug 2006 09:46:51 -0700 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <20060816104301.GC13101@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> Message-ID: <1155746811.2662.6.camel@localhost> On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote: > On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote: > > On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: > > As I didn't have the time to follow all these discussions and threads, > > and to have a basis for such an IRC-conference, I would appreciate if > > Axel and Thorsten could write up a "my proposal at one glance" outline. > > I setup an executive summary of the comparison for you and for other > people external to the discussion until now who would like to join in > on Friday: > > http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance > > and the details remain under May I suggest comparing kmdls to thl's revised kmods? As it stands there are bugs with the kmod standard that should be addressed so I'd vote +1 for changing the standard. But I'm not understanding the problems with thl's revisions that you are seeing so I'd vote -1 for kmdls and +1 for the revised kmods. A comparison against the revised kmod proposal would help to clarify that portion. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Wed Aug 16 16:54:44 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 16 Aug 2006 09:54:44 -0700 Subject: [Fedora-packaging] Kernel Module Packaging Standard Teleconference In-Reply-To: <44E263DA.2030806@redhat.com> References: <44E263DA.2030806@redhat.com> Message-ID: <1155747284.2662.12.camel@localhost> On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: > It is the decision of me, Max, and Spot, to put a hold on publishing any > further kmod modules pending the result the Kernel Module Packaging > Standard conference call. Time/date of this call is to be determined, > but we are aiming for this Friday, August 18th at a time that is > workable for both American EDT and Europe. Perhaps 1PM EDT would work, > the usual timeslot of FESCO meetings? Perhaps this timeslot wont work. > If you feel it is important to attend but you are unable to make this > time, please make it known in this thread. I'm not able to make a teleconference during business hours (17:00-01:00UTC). I can make an IRC meeting during that time on Friday, though. I'd say you could tie my vote to Ville's in this case but I see he's not going to be available for the meeting on Friday so I'd rather attend if possible. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Wed Aug 16 17:09:48 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 19:09:48 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155746811.2662.6.camel@localhost> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> Message-ID: <20060816170948.GC20037@neu.nirvana> On Wed, Aug 16, 2006 at 09:46:51AM -0700, Toshio Kuratomi wrote: > On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote: > > On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote: > > > On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: > > > As I didn't have the time to follow all these discussions and threads, > > > and to have a basis for such an IRC-conference, I would appreciate if > > > Axel and Thorsten could write up a "my proposal at one glance" outline. > > > > I setup an executive summary of the comparison for you and for other > > people external to the discussion until now who would like to join in > > on Friday: > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance > > > > and the details remain under > > May I suggest comparing kmdls to thl's revised kmods? I already commented to the new suggestion by Thorsten in the appropriate thread. I won't start writing a wiki page for each new suggestion, maybe the people tosing them should invest some time and write wiki docs comparing to kmdls. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 16 17:16:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 19:16:05 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155735970.15307.250.camel@localhost.localdomain> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155735970.15307.250.camel@localhost.localdomain> Message-ID: <20060816171605.GD20037@neu.nirvana> On Wed, Aug 16, 2006 at 04:46:10PM +0300, Ville Skytt? wrote: > On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote: > * +0.5 for moving uname-r *if* there is strong evidence that it will be > acceptable for all major stakeholders (Fedora, RHEL, kerneldrivers.org > in particular), -0.5 otherwise chicken and egg problem? > > While the single items are all factually correct > > Strong words. The above summary and the detailed doc contains several > inaccuracies and omissions (eg. about agnosticity, flexibility, buildsys > support, kabi, support(ability) in other distros etc), luckily mostly in > the less important parts. I guess this is due to not understanding all > aspects of the current scheme and the environment it is designed to work > in. I won't spend time detailing those because I don't have time to do > that right now, and even if I had, IMO there are no real reasons to > consider/discuss its adoption besides the uname-r move bit. (Yes, sucky > statement, but shrug, it's the best I can do in the time I have > available for this at the moment.) Yes, it's quite lame. If you accuse the write-up of inaccuracies/ommisions you have to go into details. Even defusing that it's not about the important parts is not enough. No, really, I don't have time to waste myself, still I deliver for every statement I make. If you don't people may consider it FUD. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 16 17:29:20 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 19:29:20 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <20060816170948.GC20037@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> Message-ID: <20060816172920.GE20037@neu.nirvana> On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote: > On Wed, Aug 16, 2006 at 09:46:51AM -0700, Toshio Kuratomi wrote: > > On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote: > > > On Wed, Aug 16, 2006 at 10:08:37AM +0200, Ralf Corsepius wrote: > > > > On Tue, 2006-08-15 at 20:16 -0400, Warren Togami wrote: > > > > As I didn't have the time to follow all these discussions and threads, > > > > and to have a basis for such an IRC-conference, I would appreciate if > > > > Axel and Thorsten could write up a "my proposal at one glance" outline. > > > > > > I setup an executive summary of the comparison for you and for other > > > people external to the discussion until now who would like to join in > > > on Friday: > > > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance > > > > > > and the details remain under > > > > May I suggest comparing kmdls to thl's revised kmods? > > I already commented to the new suggestion by Thorsten in the > appropriate thread. I won't start writing a wiki page for each new > suggestion, maybe the people tosing them should invest some time and > write wiki docs comparing to kmdls. I dislike rejecting people, so I looked again at the new proposal ... Just to make it clear the actual changes wrt kmod are: o use kabi-version instead of uname-r o disambiguate the file paths of the modules, so modules of different module versions are coinstallable *for the same kernel/kabi*!!! In fact this scheme is far more broken than the old kmod scheme: o The 'only-last-kernel-supported' simply becomes 'only-last-kabi-supported'. For Fedora it's the same anyway. So you still have issues with - no (security) updates for old kernels (or kabis) - old kernels/kabis can get their module nuked or effectively disabled. o Currently there is a file conflicst guard of not having different modules for the same kernel coinstalled. The disambiguation in the file path lifts this safety pin and suddenly we can end up with several different module versions for the same kernel!!! The kabi stuff is for using modules built for different kernels/kabis, not to have several modules of different versions coinstalled for the same kernel/kabi. We certainly want to have foo-2 kernel modules for kernel/kabi X to replace foo-1 for the same kernel/kabi and not coinstall. So that's not going to lead anywhere. We'd better stay with kmod scheme than doing that. And please stop throwing new kernel modules schemes to me :=) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 16 17:44:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 19:44:31 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060811105803.GA30245@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> Message-ID: <20060816174431.GF20037@neu.nirvana> On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote: > I suggest to vote through email [...] 5 voted, 5 still to go. Can the remaining committee members do their voting business, please? Maybe we get this rejected and all can be happy again ;) http://fedoraproject.org/wiki/AxelThimm/kmdls/voting I added Ville's votes (and copied them verbatim for Toshio on his wish) but the first because he made it indirectly dependent on the outcome: Ville & Toshio you need to decide on the first item, if you are not sure better reject than accept, but don't conditionalize, it makes vote counting difficult. :) Note: Don't use "0", it's the same as "-1" in fedora-packaging. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Aug 16 18:09:22 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 Aug 2006 20:09:22 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <20060816172920.GE20037@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> Message-ID: <44E35F52.6030901@leemhuis.info> Axel Thimm schrieb: > On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote: > o The 'only-last-kernel-supported' simply becomes > 'only-last-kabi-supported'. For Fedora it's the same anyway. > So you still have issues with > - no (security) updates for old kernels (or kabis) I was one of those that wanted to build stuff for older kernels in the past. But a lot of people disliked that idea (I can look it up in the archives if someone is interested who that was; most were from RH iirc) and only wanted to support the latest shipped kernel. If we really want to support older kernels then we need "uname -r" (or kabi, or another identifier) in the %{NAME} *or* a plugin that handles the stuff manually. I think I prefer the "uname -r/kabi" approach in that case. The question is: do we want to build new kernel modules for old kernels that might have known security problems? Old kernels also get deleted from the servers normally soon and thus aren't all available for the buildsys anymore (only the current one and the one before that are on the servers in the update repo). Building modules for all the kernels we ever shipped would take a lot of build time and space on the servers. A middle way -- build for all kernels still available wold be an compromise if we want to build for more that kernel-current. Axel, sorry, I'm not sure if I understand that "security" reference above. I understood this currently like this: problem in module -> push out a updated module and the latest kernel gets a fixed module, olders remain unfixed. But hey, older kernels often (not always) had security problems in any case -- that's why there was a new one. Or did I get something wrong here? > - old kernels/kabis can get their module nuked or effectively > disabled. Nope. > o Currently there is a file conflicst guard of not having different > modules for the same kernel coinstalled. The disambiguation in the > file path lifts this safety pin and suddenly we can end up with > several different module versions for the same kernel!!! Nope, /sbin/weak-modules {cs}hould handle this. CU thl From jkeating at redhat.com Wed Aug 16 18:19:04 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Aug 2006 14:19:04 -0400 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <44E35F52.6030901@leemhuis.info> References: <44E263DA.2030806@redhat.com> <20060816172920.GE20037@neu.nirvana> <44E35F52.6030901@leemhuis.info> Message-ID: <200608161419.04458.jkeating@redhat.com> On Wednesday 16 August 2006 14:09, Thorsten Leemhuis wrote: > If we really want to support older kernels then we need "uname -r" (or > kabi, or another identifier) in the %{NAME} *or* a plugin that handles > the stuff manually. I think I prefer the "uname -r/kabi" approach in > that case. Or you can make the package available in the repo, but the end user who is stuck on an old kernel can by hand yum install the specific version they need. Not exactly pretty, but functional, and is just one more part of the pain that is dealing with external modules and pinning to a given kernel. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Aug 16 18:37:42 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 Aug 2006 20:37:42 +0200 Subject: [Fedora-packaging] kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file Message-ID: <44E365F6.9020604@leemhuis.info> Hi all! There are ways to many things to discuss with the current proposed schemes for packaging kernel-modules. That's why I'd like to break it up into pieces and give some details of the different implementation details. I choose to start with the "One specfile approach vs. splitted spec files" discussion because that's a bit easier to discuss then the "uname -r" stuff where even I'm still unsure how to proceed. Axel, could you please take a look at this? Did I miss anything (I surely did)? I tried to concentrate on the technical details. == One specfile approach vs. splitted spec file == Mainly a matter of taste. Some prefer the one specfile approach that's used by kmdls, other the slitted approach used by kmods. The differences: * debuginfo packages for kmdls won't get created with the automatic stuff that rpm normally uses; a script/macro that is mainly an enhanced copy of the stuff that's used by rpm currently handles that (see https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html); that could be easily integrated into the standard macros shipped by FC / RHEL * the one-specfile approach needs some sort of mechanism to make sure that * the userland part normally isn't build for i586 and i686 because that's normally unneeded * the kernel-modules can't be build for i386 because there is no i386 kernel in FC) This is realized by %if %else %endif constructs in the spec file with the "kmdl_userland" define (see http://fedoraproject.org/wiki/AxelThimm/kmdls for details), that needs to be set by the buildsys when rpmbuild is called to build stuff * the buildsys must queue the rebuild of a kmdl srpm multiple times to get modules for all kernel flavours build in the kmdl case -- the kmods scheme can build all in one step. The variants and the kernel-version are currently hardcoded in the kmod standard because the Extras buildsys doesn't support passing the variants and the kernel version to rpmbuild call yet. Axel says that the kmod scheme is not "kernel {version,flavor} agnostic" due to this hardcoding. But this hardcoding currently allow us to build the kmods without other changes in the buildsys; kmdls can't get build without special support in the buildsys due to the needed "rebuild one srpm multiple times" * the kmod standard has the disadvantage that there are multiple srpms (e.g. one for kernel 2157 and one for kernel 2174). But this way we make sure that the Note: There is a really big area where parts/ideas of one approach could be moved over to the other and the other way around. E.g. kmods could get rid of the "kversion" in "%{RELEASE}" of the SRPMS and create the debuginfo packages manually just like kmdls do -- that would solve the "multiple SRPMS" problem. kmdls also could hardcode the kversion and kflavor stuff and use loops just like kmods -- then they would be buildable with the current buildsys. From toshio at tiki-lounge.com Wed Aug 16 18:44:56 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 16 Aug 2006 11:44:56 -0700 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <20060816172920.GE20037@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> Message-ID: <1155753896.2662.64.camel@localhost> On Wed, 2006-08-16 at 19:29 +0200, Axel Thimm wrote: > Just to make it clear the actual changes wrt kmod are: > > o use kabi-version instead of uname-r > o disambiguate the file paths of the modules, so modules of different > module versions are coinstallable *for the same kernel/kabi*!!! > > In fact this scheme is far more broken than the old kmod scheme: > > o The 'only-last-kernel-supported' simply becomes > 'only-last-kabi-supported'. For Fedora it's the same anyway. > So you still have issues with > - no (security) updates for old kernels (or kabis) Okay. I haven't seen anything to contradict this yet, only a conflict over whether this is a problem or not. (If I'm wrong, somebody point me to the archives or restate the rebuttal) Even if kmdls were accepted, are we planning on having the buildsystem build for multiple kernels? > - old kernels/kabis can get their module nuked or effectively > disabled. > How? Will not get overwritten (which is how I think the term "nuked" has been used in this thread.) Effectively disabled: What leads you to that conclusion? > o Currently there is a file conflicst guard of not having different > modules for the same kernel coinstalled. The disambiguation in the > file path lifts this safety pin and suddenly we can end up with > several different module versions for the same kernel!!! > But they are not being used. If we treat the kernel modules the same as the kernel itself, then this is expected. It could even be considered desirable: Upgraded modules doesn't work? Re-symlink the old module and you're set. > The kabi stuff is for using modules built for different kernels/kabis, > not to have several modules of different versions coinstalled for the > same kernel/kabi. We certainly want to have foo-2 kernel modules for > kernel/kabi X to replace foo-1 for the same kernel/kabi and not > coinstall. > I don't think that's a given. If I installed a new module from source, I'd like the option to coinstall with whatever I had on the system before so I could recover the system if I had to. With packaging it's not as important because I could download the old package and reinstall. Although I think we are removing old packages from the repository. What if the module from January is the last one that worked for me and the next ten do not? (Of course, I may be stuck with an old kernel then, as well... Like I said, I'm not sold either way.) Also, if I'm rebuilding my kernels from fedora source with some local changes to the kernel.config, a plan that places all external modules into a common directory and then makes symlinks to the relative kernel directories would help me use prebuilt kernel modules. > And please stop throwing new kernel modules schemes to me :=) The problem is we're here debating 1) Can kmods be saved and 2) if they can't be saved, do we want kmdls to replace them verbatim? So as you throw problems at the new proposals, people are going to update the proposals to try to fix those problems. In the end we'll all agree that there is an actual problem that no amount of fixing can actually solve, or we'll look at the two proposals and say this pile of hacks is less appealing to me than this one for [insert arbitrary reason here]. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Wed Aug 16 19:57:00 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 Aug 2006 21:57:00 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <44E35F52.6030901@leemhuis.info> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <44E35F52.6030901@leemhuis.info> Message-ID: <44E3788C.9070201@leemhuis.info> Thorsten Leemhuis schrieb: > Axel Thimm schrieb: >> On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote: >> - old kernels/kabis can get their module nuked or effectively >> disabled. > Nope. Correction: effectively disabled is correct. CU thl From Axel.Thimm at ATrpms.net Wed Aug 16 20:11:44 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 22:11:44 +0200 Subject: [Fedora-packaging] Re: kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file In-Reply-To: <44E365F6.9020604@leemhuis.info> References: <44E365F6.9020604@leemhuis.info> Message-ID: <20060816201144.GC27375@neu.nirvana> On Wed, Aug 16, 2006 at 08:37:42PM +0200, Thorsten Leemhuis wrote: > Axel, could you please take a look at this? Did I miss anything (I > surely did)? I tried to concentrate on the technical details. BTW this has nothing to do with the one-specfile approach but nonetheless: > * the buildsys must queue the rebuild of a kmdl srpm multiple times to > get modules for all kernel flavours build in the kmdl case -- the kmods > scheme can build all in one step. The variants and the kernel-version > are currently hardcoded in the kmod standard because the Extras buildsys > doesn't support passing the variants and the kernel version to rpmbuild > call yet. Axel says that the kmod scheme is not "kernel > {version,flavor} agnostic" due to this hardcoding. But this hardcoding > currently allow us to build the kmods without other changes in the > buildsys; kmdls can't get build without special support in the buildsys > due to the needed "rebuild one srpm multiple times" Bundeling many flavours in one build is bad, hardcoded or not. Having 4 dozens of kmdls around my belt I know that some kmdls don't build at all on some flavours, the xen family currently displaying this quite nicely, about 30-40% of kmdls are not buildable on them. When a flavour fails to build it is either so by design, so nothing can be done, or the kmdl can be fixed on package-level or upstream, or the kernel can be fixed. Therefore you don't want the specfile to dictate which flavours to build for, you want it to get this information from the buildsystem (or not at all, the information about the flavour is not even needed in kmdl schemes ...) Also flavours may come and go within a distribution's life cycle. For example a few weeks ago "xen" was added to FC5 along "xen0". No need to touch specfile/src.rpm/userland in the kmdl scheme to add supportfor the newcomer. For example the sole representant of kmods in FE is em8300. Where is his "xen" flavour? And don't forget custom kernel packages and support for them. I forgot to mention this: ATrpms has contributed swsups2 kernels for FC4 and FC5. By having the specfile/src.rpm kernel and flavour agnostic *and* unbundled I can use the same specfile/src.rpm/userland for these extras kernels/flavours, too. CCRMA has a set of their own kernels, too. So true kernel/flavour agnosticism and non-bundling of builds is a true blessing. Now about the buildsystem: My home-brewn buildsys has about 20 lines of code to support multiple builds of the kmdl src.rpm, I don't expect extending FC's and FE's buildsystem to be rocket science (BTW I did study physics, so I'm good at rocket science ;) and I offered to put my man hours into this (unless it get's all burned up before ...) It's better to extend the buildsystem than to have hardcoded kernels & flavours in all kmdl specfiles/src.rpm, have to unneccessarily rebuild src.rpm, be forced to split subpackages into twin src.rpms and the like. These are all unneccessary hacks, let's attack the real problem, extending the buildsystem. > * the kmod standard has the disadvantage that there are multiple srpms > (e.g. one for kernel 2157 and one for kernel 2174). But this way we make > sure that the This mail looks unfinished. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 16 20:30:54 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 22:30:54 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155753896.2662.64.camel@localhost> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <1155753896.2662.64.camel@localhost> Message-ID: <20060816203054.GD27375@neu.nirvana> On Wed, Aug 16, 2006 at 11:44:56AM -0700, Toshio Kuratomi wrote: > On Wed, 2006-08-16 at 19:29 +0200, Axel Thimm wrote: > > o The 'only-last-kernel-supported' simply becomes > > 'only-last-kabi-supported'. For Fedora it's the same anyway. > > So you still have issues with > > - no (security) updates for old kernels (or kabis) > > Okay. I haven't seen anything to contradict this yet, only a conflict > over whether this is a problem or not. (If I'm wrong, somebody point me > to the archives or restate the rebuttal) > > Even if kmdls were accepted, are we planning on having the buildsystem > build for multiple kernels? > > > - old kernels/kabis can get their module nuked or effectively > > disabled. > > > How? > > Will not get overwritten (which is how I think the term "nuked" has been > used in this thread.) I answered to this on fedora-devel. I also added this to the wiki. But still let's give an example (versions are faked and simplified, I don't want to go hunting them, but the example is bitter real): ipw2200-1 requires userland package ipw2200-firmware-1 We have two kernels, "a" the old one, "b" the new one. So kmod would deliver something like ipw2200-kmod-1-a and ipw2200-kmod-1-b For the two kernels before the module upgrade. Now the following three packages hit the repo ipw2200-kmod-2-a and ipw2200-kmod-2-b ipw2200-firmware-2 And the kmods require the new firmware. In the kmdl scheme they would both get installed and the old ones uninstalled (same for the firmware). %post %postun would also perform the proper install/upgrade distinction (another thing kmods fail, you cannot know whether this is an upgrade of install in the specfile, but that's another story). yum + the current yum plugn support will only try to install/upgrade ipw2200-kmod-2-b and ipw2200-firmware-2, kernel "a" became invisible to the upgrade. But ipw2200-kmod-1-a has a hard dependency on ipw2200-firmware-1 which is just being upgraded to a new version. Therefore the only way out is to uninstall ipw2200-kmod-1-a. So you have your old kernel's kmdo nuked. > Effectively disabled: What leads you to that conclusion? If the dependency was (wrongly) not strict, then the kmod is not nuked, but does not work anymore due to the new firmware => effectively disabled. > > o Currently there is a file conflicst guard of not having different > > modules for the same kernel coinstalled. The disambiguation in the > > file path lifts this safety pin and suddenly we can end up with > > several different module versions for the same kernel!!! > But they are not being used. If we treat the kernel modules the same as > the kernel itself, then this is expected. No, you're fallen for the dual nature of kernel modules. They carry a kernel evr and need to be coinstallable wrt that, but they carry their own evr, too, which needs to be in upgrade-mode like all other packages. Any argument to not do so would propagate to all other packages, too (hey, what if ipw2200-2 is broken, I want a fallback to ipw2200-1 vs hey, what if openoffice-3.0.1 is borken, I want a fallback to openoffice-3.0.0). > > And please stop throwing new kernel modules schemes to me :=) > > The problem is we're here debating 1) Can kmods be saved and 2) if they > can't be saved, do we want kmdls to replace them verbatim? > > So as you throw problems at the new proposals, people are going to > update the proposals to try to fix those problems. In the end we'll all > agree that there is an actual problem that no amount of fixing can > actually solve, or we'll look at the two proposals and say this pile of > hacks is less appealing to me than this one for [insert arbitrary reason > here]. Agreed, but I expect some more homework being done before throwing it out. I usually spend more time in writing an analysis of those hourly proposals than it took the author to think about them. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 16 20:36:34 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 Aug 2006 22:36:34 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <44E35F52.6030901@leemhuis.info> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <44E35F52.6030901@leemhuis.info> Message-ID: <20060816203634.GE27375@neu.nirvana> On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Wed, Aug 16, 2006 at 07:09:48PM +0200, Axel Thimm wrote: > > > o The 'only-last-kernel-supported' simply becomes > > 'only-last-kabi-supported'. For Fedora it's the same anyway. > > So you still have issues with > > - no (security) updates for old kernels (or kabis) > > If we really want to support older kernels then we need "uname -r" (or > kabi, or another identifier) in the %{NAME} *or* a plugin that handles > the stuff manually. I think I prefer the "uname -r/kabi" approach in > that case. > > The question is: do we want to build new kernel modules for old kernels > that might have known security problems? Do we want to keep those kernels in the repo? Whatever the policy for kernels it mirrors to the kernel module support. If a kernel is not worth installing, remove it from the repo and the associated kmdls. > Building modules for all the kernels we ever shipped No, that's not the idea. Only what is considered a sane transition time from kernel to kernel. > Axel, sorry, I'm not sure if I understand that "security" reference > above. I understood this currently like this: problem in module -> push > out a updated module and the latest kernel gets a fixed module, olders > remain unfixed. But hey, older kernels often (not always) had security > problems in any case -- that's why there was a new one. Or did I get > something wrong here? In Fedora??? 30% of kernel updates are not security related, and often some kernels are brown bag releases, so many people back up to the previous kernel. Supporting the last kernel is important. > > - old kernels/kabis can get their module nuked or effectively > > disabled. > > Nope. Yep. > > o Currently there is a file conflicst guard of not having different > > modules for the same kernel coinstalled. The disambiguation in the > > file path lifts this safety pin and suddenly we can end up with > > several different module versions for the same kernel!!! > > Nope, /sbin/weak-modules {cs}hould handle this. So adding evr semantics to module-init-tools? BTW where is the epoch in your file path suggestion? ... Gotcha! :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jcm at redhat.com Wed Aug 16 22:04:31 2006 From: jcm at redhat.com (Jon Masters) Date: Wed, 16 Aug 2006 23:04:31 +0100 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <20060816203634.GE27375@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <44E35F52.6030901@leemhuis.info> <20060816203634.GE27375@neu.nirvana> Message-ID: <1155765871.9148.540.camel@localhost.localdomain> On Wed, 2006-08-16 at 22:36 +0200, Axel Thimm wrote: > On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote: > > Axel Thimm schrieb: > > Nope, /sbin/weak-modules {cs}hould handle this. > So adding evr semantics to module-init-tools? BTW where is the epoch > in your file path suggestion? ... > Gotcha! :) I'm already adding a conf.d to m-i-t (but still toying with the exact implementation to be figured out over this week) so you can specify the priorities for individual /lib/modules directories. This is actually to solve another problem, which is that sometimes you might want to use kmods to override the built in kernel modules, sometimes not but you might also want to *explicitly* set behavior in the module RPM. You could (a)buse this to override the ordering of modules if we switched to a new packaging system. Right now, the ordering of directories in our m-i-t is: * Try /lib/modules/*/updates - if there, the admin did it. * Try /lib/modules/*/extra - if there, it's in a current kmod. * Try /lib/modules/* - if in the kernel, cool. * Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it when looking to find compatible modules on kmod remove/install. With kabi checking enabled (if you package with kABI deps) then you get for free the compatibility links automatically added/removed on module install/remove so older kernels can use a more recent kmod. You will be able to ultimately instruct module-init-tools to always use the version of a module in weak-updates over the built-in kernel and thereby get a given module to always be available to all compatible installed kernels. My personal opinion is that it's too late to change kmods drastically in FC6. I think now we're all starting to think about the overall packaging process again that we should have discussions this week about what to do in FC7 and beyond - unless there's a major flaw in kmods (and I don't think we can count any of the existing arguments as sufficient reason to rip out the current status quo at T2 stage) we should leave it for FC6. Jon. -- Jon Masters Phone: +44 7776 131337 Red Hat UK, Ltd. Email: jcm at redhat.com From rc040203 at freenet.de Thu Aug 17 02:02:04 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 Aug 2006 04:02:04 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155735970.15307.250.camel@localhost.localdomain> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155735970.15307.250.camel@localhost.localdomain> Message-ID: <1155780125.27621.166.camel@mccallum.corsepiu.local> On Wed, 2006-08-16 at 16:46 +0300, Ville Skytt? wrote: > On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote: > > > I setup an executive summary of the comparison for you and for other > > people external to the discussion until now who would like to join in > > on Friday: > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance > > I'm almost certainly unable to join any meeting before next week Similar applies to me. I'll probably be unable to join any meeting before mid Sept. unless it takes place late at night CET. > To reiterate: if consensus says change is needed, and there's competent > manpower available to take care of things *soon*, so be it. The only > things I feel strongly about are that rejecting module packages from > FC/FE altogether would be profoundly odd at this point, and that the > scope of the discussion needs to be limited to whether uname-r gets > moved to the packages' names and its direct unavoidable consequences -- > the only real technical design issue. Everything else in the "kmdl" > proposal is more or less cosmetics and implementation details, and > adopting it would mean throwing away quite a bit of work (reinventing > the wheel from the POV of the current scheme and its adopters) from > several parties for questionable gain. > > http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName > This draft has potential. I disagree on this. It is way too narrowly focused on implementation details of kmod. What we needed is strict and narrow conventions on kernel-module NEVRs to assure proper interaction with installers. All the rest is implementation details. Forcing a specific template to me is actionism, because kernel-module rpms are NOT really different from other RPMs, IMO. They are more complex and require strict conventions on their "rpm API", that's all. /me ducks Ralf From tibbs at math.uh.edu Thu Aug 17 04:23:58 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 16 Aug 2006 23:23:58 -0500 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155780125.27621.166.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Thu, 17 Aug 2006 04:02:04 +0200") References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155735970.15307.250.camel@localhost.localdomain> <1155780125.27621.166.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> I disagree on this. It is way too narrowly focused on RC> implementation details of kmod. To some degree I agree with this. RC> What we needed is strict and narrow conventions on kernel-module RC> NEVRs to assure proper interaction with installers. Well, it's more than that; we have to ensure proper interaction with the buildsys and there may be restrictions on file locations and such. But beyond those things I agree that a bit of leeway is reasonable. Of course, this stuff is _hard_, and the templates are a great idea because it allows packagers to just plug the details in. But that's different from saying that the spec MUST conform to that template. So perhaps we could approach this issue from the other direction: what NEVR convention(s) and file locations are required so that rpm, yum and the like will properly handle the modules, including parallel installs without conflict? What do the spec(s) need to have so that the buildsys can build them for all supported kernel versions and variants? - J< From tibbs at math.uh.edu Thu Aug 17 04:34:55 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 16 Aug 2006 23:34:55 -0500 Subject: [Fedora-packaging] The .pc and pkgconfig issue Message-ID: I know a month or so ago we voted to add a bit to the guidelines reinforcing the necessity of -devel packages with .pc files requiring pkgconfig. I went to file a bug about a core package that wasn't doing this (which resulted in bustage of a package I was reviewing): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202280 It seems Matthias Clasen (mclasen at redhat.com) wants to debate this and I'm not sure what to do. I don't have any arguments other than directory ownership and "that's what the committee decided". - J< From rc040203 at freenet.de Thu Aug 17 04:41:18 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 Aug 2006 06:41:18 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155735970.15307.250.camel@localhost.localdomain> <1155780125.27621.166.camel@mccallum.corsepiu.local> Message-ID: <1155789678.7629.11.camel@mccallum.corsepiu.local> On Wed, 2006-08-16 at 23:23 -0500, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> I disagree on this. It is way too narrowly focused on > RC> implementation details of kmod. > > To some degree I agree with this. > > RC> What we needed is strict and narrow conventions on kernel-module > RC> NEVRs to assure proper interaction with installers. > > Well, it's more than that; we have to ensure proper interaction with > the buildsys and there may be restrictions on file locations and such. Agreed, like we agree upon "apps go to %{_bindir}", "libs go to %{_libdir}", we need a clear and strict convention on where kernel-modules need to be installed. How to handle accompanying userspace libs/apps, whether to use split or unified srpms/specs, how many kernel-modules to build simultaneously from one spec are implementation details, each with different pros and cons. > But beyond those things I agree that a bit of leeway is reasonable. > > Of course, this stuff is _hard_, and the templates are a great idea > because it allows packagers to just plug the details in. But that's > different from saying that the spec MUST conform to that template. Exactly. It's a particular rpm's macroscopic behavior as viewed by the installers that matters. > So perhaps we could approach this issue from the other direction: what > NEVR convention(s) and file locations are required so that rpm, yum > and the like will properly handle the modules, including parallel > installs without conflict? What do the spec(s) need to have so that > the buildsys can build them for all supported kernel versions and > variants? Fully agreed, sounds very reasonable to me. Ralf From fedora at leemhuis.info Thu Aug 17 05:31:59 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 Aug 2006 07:31:59 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <20060816203054.GD27375@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <1155753896.2662.64.camel@localhost> <20060816203054.GD27375@neu.nirvana> Message-ID: <44E3FF4F.9050009@leemhuis.info> Axel Thimm schrieb: > [...] > I answered to this on fedora-devel. I also added this to the wiki. But > still let's give an example (versions are faked and simplified, I > don't want to go hunting them, but the example is bitter real): > > ipw2200-1 requires userland package ipw2200-firmware-1 > > We have two kernels, "a" the old one, "b" the new one. So kmod would > deliver something like > > ipw2200-kmod-1-a and > ipw2200-kmod-1-b > > For the two kernels before the module upgrade. Now the following three > packages hit the repo > > ipw2200-kmod-2-a and > ipw2200-kmod-2-b > ipw2200-firmware-2 > > And the kmods require the new firmware. You can package both the old and the new firmware in one package. We did it in livna for ipw2200 because people might still run older Fedora Kernels that requires the new firmware, while the up2date kernel requires the new firmware. CU thl From fedora at leemhuis.info Thu Aug 17 05:47:41 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 Aug 2006 07:47:41 +0200 Subject: [Fedora-packaging] Re: kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file In-Reply-To: <20060816201144.GC27375@neu.nirvana> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> Message-ID: <44E402FD.4000301@leemhuis.info> Axel Thimm schrieb: > On Wed, Aug 16, 2006 at 08:37:42PM +0200, Thorsten Leemhuis wrote: >> Axel, could you please take a look at this? Did I miss anything (I >> surely did)? I tried to concentrate on the technical details. > > BTW this has nothing to do with the one-specfile approach As I said in my mail: Note: There is a really big area where parts/ideas of one approach could be moved over to the other and the other way around. [...] > but nonetheless: >> * the buildsys must queue the rebuild of a kmdl srpm multiple times to >> get modules for all kernel flavours build in the kmdl case -- the kmods >> scheme can build all in one step. The variants and the kernel-version >> are currently hardcoded in the kmod standard because the Extras buildsys >> doesn't support passing the variants and the kernel version to rpmbuild >> call yet. Axel says that the kmod scheme is not "kernel >> {version,flavor} agnostic" due to this hardcoding. But this hardcoding >> currently allow us to build the kmods without other changes in the >> buildsys; kmdls can't get build without special support in the buildsys >> due to the needed "rebuild one srpm multiple times" > > Bundeling many flavours in one build is bad, hardcoded or not. I disagree. > Having > 4 dozens of kmdls around my belt I know that some kmdls don't build at > all on some flavours, the xen family currently displaying this quite > nicely, about 30-40% of kmdls are not buildable on them. When a > flavour fails to build it is either so by design, so nothing can be > done, or the kmdl can be fixed on package-level or upstream, or the > kernel can be fixed. Therefore you don't want the specfile to dictate > which flavours to build for, you want it to get this information from > the buildsystem (or not at all, the information about the flavour is > not even needed in kmdl schemes ...) Sure, but that *can* be filtered within kmod spec file if we want to. It it could also be done by the buildsys (that's what I'd prefer). In your case the buildsys would have to do it. So none of the two is really better then the other. Just a matter of taste. > Also flavours may come and go within a distribution's life cycle. For > example a few weeks ago "xen" was added to FC5 along "xen0". No need > to touch specfile/src.rpm/userland in the kmdl scheme to add > supportfor the newcomer. For example the sole representant of kmods in > FE is em8300. Where is his "xen" flavour? You'd have to ask scop. Maybe it didn't build, don't know. But just as above: there is no difference between kmdls and kmods when the buildsys handles that. In the kmod case the buildsys can simply run rpmbuild kmod-foo.src.rpm --define 'kversion 2.6.17-1.2145_FC5' --define 'kvariants "" smp xen xen0 XenU bigsmp never_have_heard_of_flavor' and it's build as long as never_have_heard_of_flavor exists -- no modifications to the specfile needed. > And don't forget custom kernel packages and support for them. I forgot > to mention this: ATrpms has contributed swsups2 kernels for FC4 and > FC5. By having the specfile/src.rpm kernel and flavour agnostic *and* > unbundled I can use the same specfile/src.rpm/userland for these > extras kernels/flavours, too. CCRMA has a set of their own kernels, > too. This works for kmod, too, as long as the custom kernel follows the FC kernel scheme exactly. > So true kernel/flavour agnosticism and non-bundling of builds is a > true blessing. As I said: There is no real difference between kmods and kmdls here if the buildsys handles everything. [...] >> * the kmod standard has the disadvantage that there are multiple srpms >> (e.g. one for kernel 2157 and one for kernel 2174). But this way we make >> sure that the > This mail looks unfinished. Yeap. It should end with: But this way we make sure that the SRPMS listed by "rpm -qi" really is the source rpm that was used to build stuff. Some people wanted that, but that's no big deal. CU thl From Axel.Thimm at ATrpms.net Thu Aug 17 07:01:57 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 Aug 2006 09:01:57 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155765871.9148.540.camel@localhost.localdomain> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <44E35F52.6030901@leemhuis.info> <20060816203634.GE27375@neu.nirvana> <1155765871.9148.540.camel@localhost.localdomain> Message-ID: <20060817070157.GG27375@neu.nirvana> On Wed, Aug 16, 2006 at 11:04:31PM +0100, Jon Masters wrote: > > So adding evr semantics to module-init-tools? BTW where is the epoch > > in your file path suggestion? ... > > Gotcha! :) > > I'm already adding a conf.d to m-i-t (but still toying with the exact > implementation to be figured out over this week) so you can specify the > priorities for individual /lib/modules directories. This is actually to > solve another problem, which is that sometimes you might want to use > kmods to override the built in kernel modules, sometimes not but you > might also want to *explicitly* set behavior in the module RPM. > > You could (a)buse this to override the ordering of modules if we > switched to a new packaging system. Right now, the ordering of > directories in our m-i-t is: > > * Try /lib/modules/*/updates - if there, the admin did it. Or any of 67 kmdls from ATrpms. > * Try /lib/modules/*/extra - if there, it's in a current kmod. > * Try /lib/modules/* - if in the kernel, cool. > * Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it > when looking to find compatible modules on kmod remove/install. The suggestion Thorsten is implying is that you should try under /lib/modules/*/foo/1/1.2.3/2 /lib/modules/*/foo/1/1.2.3/1 /lib/modules/*/foo/1/1.2.2/1 /lib/modules/*/foo/0/10/1 in that order for several coinstalled versions of foo *for the same kernel* (the folder names are epoch/version/release), and you would have to use rpmvercmp to compare the folder names. That's a package problem that is being pushed to the wrong domain. For the same kernel (or kabi) the module should have one version installed. Otherwise the argument of having multiple versions of anything, not only kernel modules applies. > With kabi checking enabled (if you package with kABI deps) then you get > for free the compatibility links automatically added/removed on module > install/remove so older kernels can use a more recent kmod. You will be > able to ultimately instruct module-init-tools to always use the version > of a module in weak-updates over the built-in kernel and thereby get a > given module to always be available to all compatible installed kernels. The relation is different between what you and Thorsten think. It's many kernel modules *for* the same kernel vs many kernel modules *from different* kernels/kabis. The kabi solution tries to recycle kernel modules from foreign kernels where possible as given by kabi metrics, it hs nothing to do with kernel module upgrades within the same kernel (as going from foo-1.2.2-1 to foo-1.2.3-1 in the example above). Using the kabi mechanisms for that would be wrong. Just to make it clearer: These pile of kernel modules would share the same kernel abi, e.g. their value for recycling is the same, if foo-1.2.2-1 for kernel X can be recycled, so can foo-1.2.3-1 for the same kernel, so why pick the old package at all? If the argument is because the newer package might be broken, then the same applies to any other non-kernel related package and we're not going to allow several coinstallations of gcc/glibc/openoffice etc and have the PATH/linker decide on evr semantics. If the newer pakcage is broken, downgrade to the previous is the typical solution, not coinstall all under the sun :) > My personal opinion is that it's too late to change kmods drastically in > FC6. I agree, my suggestion is not to change, but to dump :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Aug 17 07:09:50 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 Aug 2006 09:09:50 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <44E3FF4F.9050009@leemhuis.info> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <1155753896.2662.64.camel@localhost> <20060816203054.GD27375@neu.nirvana> <44E3FF4F.9050009@leemhuis.info> Message-ID: <20060817070950.GH27375@neu.nirvana> On Thu, Aug 17, 2006 at 07:31:59AM +0200, Thorsten Leemhuis wrote: > > > Axel Thimm schrieb: > >[...] > >I answered to this on fedora-devel. I also added this to the wiki. But > >still let's give an example (versions are faked and simplified, I > >don't want to go hunting them, but the example is bitter real): > > > >ipw2200-1 requires userland package ipw2200-firmware-1 > > > >We have two kernels, "a" the old one, "b" the new one. So kmod would > >deliver something like > > > >ipw2200-kmod-1-a and > >ipw2200-kmod-1-b > > > >For the two kernels before the module upgrade. Now the following three > >packages hit the repo > > > >ipw2200-kmod-2-a and > >ipw2200-kmod-2-b > >ipw2200-firmware-2 > > > >And the kmods require the new firmware. > > You can package both the old and the new firmware in one package. We did > it in livna for ipw2200 because people might still run older Fedora > Kernels that requires the new firmware, while the up2date kernel > requires the new firmware. What if the package's files shares the same names? Like for instance ipw3945 and ipw3945d (I love real-life examples)? What if the kmdl is dependend on the exact version of the userland (like nvidia)? Don't we suggest to any decent packager to do have sane versioning in his subpackaging for a good reason? Bundling packages into one is a bad thing, especially when they are the same package of a different version!!! That's the problem with pandora's box (see the wiki): You have piles and piles of workarounds/hacks to fix previous bugs of the basic design problems and evey new "fix" is generating more bugs. Maybe it's not pandora's box, but more like a Hydra. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Aug 17 07:12:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 Aug 2006 09:12:08 +0200 Subject: [Fedora-packaging] Re: kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file In-Reply-To: <44E402FD.4000301@leemhuis.info> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <44E402FD.4000301@leemhuis.info> Message-ID: <20060817071208.GI27375@neu.nirvana> On Thu, Aug 17, 2006 at 07:47:41AM +0200, Thorsten Leemhuis wrote: > >Also flavours may come and go within a distribution's life cycle. For > >example a few weeks ago "xen" was added to FC5 along "xen0". No need > >to touch specfile/src.rpm/userland in the kmdl scheme to add > >supportfor the newcomer. For example the sole representant of kmods in > >FE is em8300. Where is his "xen" flavour? > > You'd have to ask scop. Maybe it didn't build, don't know. If it builds for xen0 it builds for xen. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Thu Aug 17 09:21:49 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 17 Aug 2006 12:21:49 +0300 Subject: [Fedora-packaging] Re: kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file In-Reply-To: <20060817071208.GI27375@neu.nirvana> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <44E402FD.4000301@leemhuis.info> <20060817071208.GI27375@neu.nirvana> Message-ID: <1155806509.15307.306.camel@localhost.localdomain> On Thu, 2006-08-17 at 09:12 +0200, Axel Thimm wrote: > On Thu, Aug 17, 2006 at 07:47:41AM +0200, Thorsten Leemhuis wrote: > > >FE is em8300. Where is his "xen" flavour? > > > > You'd have to ask scop. Maybe it didn't build, don't know. > > If it builds for xen0 it builds for xen. I'm not aware of any problems building it, but nor am I knowledgeable enough about Xen to be able to tell whether shipping this particular module package for the FC5 "xen" variant makes sense in the first place even if it compiles fine. So I just followed what GFS and friends do and didn't build for "xen". Maybe that's a bug? Some info about the different xen variants from the POV of for which of them in general it makes sense to ship hardware device drivers such as this one would be nice. WAG: xen0 and xen yes, xenU no? And if the module is not a hardware device driver but something else, then in general ship+build for all xen*? From ville.skytta at iki.fi Thu Aug 17 09:45:37 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 17 Aug 2006 12:45:37 +0300 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155789678.7629.11.camel@mccallum.corsepiu.local> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155735970.15307.250.camel@localhost.localdomain> <1155780125.27621.166.camel@mccallum.corsepiu.local> <1155789678.7629.11.camel@mccallum.corsepiu.local> Message-ID: <1155807937.15307.319.camel@localhost.localdomain> On Thu, 2006-08-17 at 06:41 +0200, Ralf Corsepius wrote: > On Wed, 2006-08-16 at 23:23 -0500, Jason L Tibbitts III wrote: > > So perhaps we could approach this issue from the other direction: what > > NEVR convention(s) and file locations are required so that rpm, yum > > and the like will properly handle the modules, including parallel > > installs without conflict? What do the spec(s) need to have so that > > the buildsys can build them for all supported kernel versions and > > variants? > Fully agreed, sounds very reasonable to me. I think this pretty much just another way of saying the same thing I posted in https://www.redhat.com/archives/fedora-packaging/2006-August/msg00170.html : focus on the only real technical design issue now, and just reuse the implementation work which is already done as much as possible. Also, the packaging draft linked to in the above message and the current "standard" doc from which it is derived from should already contain all the above info. Maybe it just needs some restructuring and clarifications in order to prominently specify what part of it is the interface and what is the supporting reference implementation that makes it possible to ship such packages with the current infrastructure. From Axel.Thimm at ATrpms.net Thu Aug 17 11:14:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 Aug 2006 13:14:27 +0200 Subject: [Fedora-packaging] OT: xen vs xen0 (was: kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file) In-Reply-To: <1155806509.15307.306.camel@localhost.localdomain> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <44E402FD.4000301@leemhuis.info> <20060817071208.GI27375@neu.nirvana> <1155806509.15307.306.camel@localhost.localdomain> Message-ID: <20060817111427.GC5485@neu.nirvana> On Thu, Aug 17, 2006 at 12:21:49PM +0300, Ville Skytt? wrote: > On Thu, 2006-08-17 at 09:12 +0200, Axel Thimm wrote: > > On Thu, Aug 17, 2006 at 07:47:41AM +0200, Thorsten Leemhuis wrote: > > > >FE is em8300. Where is his "xen" flavour? > > > > > > You'd have to ask scop. Maybe it didn't build, don't know. > > > > If it builds for xen0 it builds for xen. > > I'm not aware of any problems building it, but nor am I knowledgeable > enough about Xen to be able to tell whether shipping this particular > module package for the FC5 "xen" variant makes sense in the first place > even if it compiles fine. So I just followed what GFS and friends do > and didn't build for "xen". Maybe that's a bug? If GFS didn't build for xen, but for xen0, it's a bug in GFS or the associated buildsystem. Maybe exactly the design issues I'm referring to of hardwiring the flavours in the specfile/src.rpm, or maybe something else, in any case a bug. :) > Some info about the different xen variants from the POV of for which of > them in general it makes sense to ship hardware device drivers such as > this one would be nice. WAG: xen0 and xen yes, xenU no? And if the > module is not a hardware device driver but something else, then in > general ship+build for all xen*? Rules of thumb: o Everything *should* build under xen and xen0, they are both domain0 kernels (but see below) o Not everything even makes sense under xenU (e.g. nvidia-graphics), this is the guest kernel. If something does not work with xen or xen0 it's either a bug in these flavours (forgetting to export something, or exporting an updated symbol/signature of say 2.6.18 on 2.6.17, this has bitten me quite some times like the premature _xmit_lock* changes) or a bug in the upstream kernel module project. But wrt xen vs xen0: iff it builds on one of them then it builds on the other. That's 99.9% sure. Just for reference, here are the differences between those two: -CONFIG_HIGHMEM4G=y -# CONFIG_HIGHMEM64G is not set +# CONFIG_HIGHMEM4G is not set +CONFIG_HIGHMEM64G=y @@ -3078,2 +3079,2 @@ -CONFIG_XEN_BLKDEV_BACKEND=y -CONFIG_XEN_NETDEV_BACKEND=y +CONFIG_XEN_BLKDEV_BACKEND=m +CONFIG_XEN_NETDEV_BACKEND=m @@ -3103,0 +3105,8 @@ +# CONFIG_NOHIGHMEM is not set +# CONFIG_HIGHMEM4G is not set +CONFIG_HIGHMEM64G=y +CONFIG_HIGHMEM=y +CONFIG_XEN_BLKDEV_BACKEND=m +CONFIG_XEN_NETDEV_BACKEND=m +CONFIG_XEN_BLKDEV_FRONTEND=m +CONFIG_XEN_NETDEV_FRONTEND=m -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Aug 17 11:22:59 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 Aug 2006 13:22:59 +0200 Subject: [Fedora-packaging] flexibility of kmdl interface (was: Kernel Module Packaging Standard Teleconference) In-Reply-To: <1155780125.27621.166.camel@mccallum.corsepiu.local> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155735970.15307.250.camel@localhost.localdomain> <1155780125.27621.166.camel@mccallum.corsepiu.local> Message-ID: <20060817112259.GD5485@neu.nirvana> On Thu, Aug 17, 2006 at 04:02:04AM +0200, Ralf Corsepius wrote: > > http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName > > This draft has potential. > I disagree on this. It is way too narrowly focused on implementation details of kmod. > > What we needed is strict and narrow conventions on kernel-module NEVRs > to assure proper interaction with installers. > > All the rest is implementation details. Forcing a specific template to > me is actionism, because kernel-module rpms are NOT really different > from other RPMs, IMO. They are more complex and require strict > conventions on their "rpm API", that's all. Very nice! :) Please check out the kmdl interface in the wiki. It is that abstract and flexible that it could even be used with the buggy kmod scheme. It is alse rather free-floating syntax, so you can bolster your rpms just the way you are used to, you just need to make use of a couple macros (like declaring that this package contains kmdls, or a macro that points to the kernel source). No further helper applications/scripts are needed. The kmdl interface even allows a complete transparent switch to any kabi scheme. E.g. if all of Fedora Extras uses kmdls and a uname-r-in-name, and suddenly the RHEL folks want to reuse all of these kmdls, but with a kabi-version-in-name, they can use the same specfile/src.rpm unchanged! And someone in the future trying to test the kmod scheme bugs, can even also just modify a couple of macros in the kmdl implementation and suddenly the kmdls are named/versioned like kmods! And even though there is so much flexibility in the kmdl interface scheme it still remains extremely KISS and distro-agnostic. If you like the kmdl proposal is two-fold o kmdl interface proposal o kmdl implementation proposal It's all hidden in the largish wiki text and in the piles of mails. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Aug 17 11:36:14 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 Aug 2006 13:36:14 +0200 Subject: [Fedora-packaging] kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <20060816201144.GC27375@neu.nirvana> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> Message-ID: <20060817113614.GE5485@neu.nirvana> On Wed, Aug 16, 2006 at 10:11:44PM +0200, Axel Thimm wrote: > And don't forget custom kernel packages and support for them. I forgot > to mention this: ATrpms has contributed swsups2 kernels for FC4 and > FC5. By having the specfile/src.rpm kernel and flavour agnostic *and* > unbundled I can use the same specfile/src.rpm/userland for these > extras kernels/flavours, too. CCRMA has a set of their own kernels, > too. I have added this argument to the wiki. kmdls allow you to bolster your oen kernel package called my-special-kernel-2.6.18-111 and support it with kmdls. Background: custom kernel packages should always either change the main name of the rpm package or introduce themselves as a new flavour otherwise they get rpm-sorted into the same upgrade path like vendor kernels which neither the vendor, nor the author of the custom kernel package wants to happen. kmdls fully support custom kernel rpms. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Aug 17 11:40:19 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 Aug 2006 13:40:19 +0200 Subject: [Fedora-packaging] kmod: $1 in %post and firends broken (was: Kernel Module Packaging Standard Teleconference) In-Reply-To: <20060816203054.GD27375@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <1155753896.2662.64.camel@localhost> <20060816203054.GD27375@neu.nirvana> Message-ID: <20060817114019.GF5485@neu.nirvana> On Wed, Aug 16, 2006 at 10:30:54PM +0200, Axel Thimm wrote: > In the kmdl scheme they would both get installed and the old ones > uninstalled (same for the firmware). %post %postun would also perform > the proper install/upgrade distinction (another thing kmods fail, you > cannot know whether this is an upgrade of install in the specfile, but > that's another story). The argument is rather obvious, but before people ask: $1 is the number of packages with the same name existing after this rpm operation and is used in scriplets to decide whether this package is a first-time install, an upgrade or a final deletion. For kmdls this is the number of kmdls for this kernel/kabi, for kmods it for all kernels, therefore the kmod can never know whether it's a first time install/upgrade/deletion for the kernel it's being installed in. E.g. usage of $1 in kmods'scriplets is broken. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Aug 17 11:41:32 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 17 Aug 2006 06:41:32 -0500 Subject: [Fedora-packaging] The .pc and pkgconfig issue In-Reply-To: References: Message-ID: <44E455EC.6020003@math.unl.edu> Jason L Tibbitts III wrote: > I know a month or so ago we voted to add a bit to the guidelines > reinforcing the necessity of -devel packages with .pc files requiring > pkgconfig. I went to file a bug about a core package that wasn't > doing this (which resulted in bustage of a package I was reviewing): > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202280 > > It seems Matthias Clasen (mclasen at redhat.com) wants to debate this and > I'm not sure what to do. I don't have any arguments other than > directory ownership and "that's what the committee decided". The other reason is that .pc files are pretty much useless if pkgconfig isn't there. IMO, the policy/guideline is in place, and it's our (packaging comittee) resposibility to lay the smack on anyone who refuses to play ball. Now, if Matthias disagrees with the policy, it is certainly within his right to raise the issue for more debate (which folks *should* do if they disagree with the policies), but until policy is changed, he's expected to follow that policy just like everyone else. (bugzilla updated) -- Rex From jkeating at redhat.com Thu Aug 17 11:51:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 Aug 2006 07:51:23 -0400 Subject: [Fedora-packaging] The .pc and pkgconfig issue In-Reply-To: References: Message-ID: <200608170751.26768.jkeating@redhat.com> On Thursday 17 August 2006 00:34, Jason L Tibbitts III wrote: > It seems Matthias Clasen (mclasen at redhat.com) wants to debate this and > I'm not sure what to do. ?I don't have any arguments other than > directory ownership and "that's what the committee decided". My comments (put in bugzilla and discussed on IRC last night) Until such time as the filesystem package owns the %{_libdir}/pkgconfig directory, this guideline will stand. If filesystem owns the directory and we remove the fact that many packages could end up owning it, we can revisit this issue and possible remove the necessity on pkgconfig for any file that drops a .pc file. However the former needs to happen before we discuss the latter. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjneely at ncsu.edu Thu Aug 17 17:51:53 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Thu, 17 Aug 2006 13:51:53 -0400 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155765871.9148.540.camel@localhost.localdomain> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <44E35F52.6030901@leemhuis.info> <20060816203634.GE27375@neu.nirvana> <1155765871.9148.540.camel@localhost.localdomain> Message-ID: <20060817175153.GJ26953@anduril.unity.ncsu.edu> On Wed, Aug 16, 2006 at 11:04:31PM +0100, Jon Masters wrote: > On Wed, 2006-08-16 at 22:36 +0200, Axel Thimm wrote: > > On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote: > > > Axel Thimm schrieb: > > > > Nope, /sbin/weak-modules {cs}hould handle this. > > > So adding evr semantics to module-init-tools? BTW where is the epoch > > in your file path suggestion? ... > > Gotcha! :) > > I'm already adding a conf.d to m-i-t (but still toying with the exact > implementation to be figured out over this week) so you can specify the > priorities for individual /lib/modules directories. This is actually to > solve another problem, which is that sometimes you might want to use > kmods to override the built in kernel modules, sometimes not but you > might also want to *explicitly* set behavior in the module RPM. > > You could (a)buse this to override the ordering of modules if we > switched to a new packaging system. Right now, the ordering of > directories in our m-i-t is: > > * Try /lib/modules/*/updates - if there, the admin did it. > * Try /lib/modules/*/extra - if there, it's in a current kmod. > * Try /lib/modules/* - if in the kernel, cool. > * Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it > when looking to find compatible modules on kmod remove/install. > > With kabi checking enabled (if you package with kABI deps) then you get > for free the compatibility links automatically added/removed on module > install/remove so older kernels can use a more recent kmod. You will be > able to ultimately instruct module-init-tools to always use the version > of a module in weak-updates over the built-in kernel and thereby get a > given module to always be available to all compatible installed kernels. > > My personal opinion is that it's too late to change kmods drastically in > FC6. I think now we're all starting to think about the overall packaging > process again that we should have discussions this week about what to do > in FC7 and beyond - unless there's a major flaw in kmods (and I don't > think we can count any of the existing arguments as sufficient reason to > rip out the current status quo at T2 stage) we should leave it for FC6. > > Jon. > > -- > Jon Masters Phone: +44 7776 131337 > Red Hat UK, Ltd. Email: jcm at redhat.com > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging Jon, Do I understand this correctly? Grub doesn't know anything about RPM versioning but it knows what kernel to boot because the kernel package / up2date / whatever runs a tool that says make this the default kernel. I've gleaned so far that the mit tool will be used similarly with kernel module packages to say "use this module as the default in kernel version foo." The user/admin can use the mit tool or whatever to adjust which modules get used with his own packages or configuration management tools as is needed by his requirements. Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From chris.stone at gmail.com Thu Aug 17 19:07:25 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 17 Aug 2006 12:07:25 -0700 Subject: [Fedora-packaging] The .pc and pkgconfig issue In-Reply-To: <200608170751.26768.jkeating@redhat.com> References: <200608170751.26768.jkeating@redhat.com> Message-ID: On 8/17/06, Jesse Keating wrote: > On Thursday 17 August 2006 00:34, Jason L Tibbitts III wrote: > > It seems Matthias Clasen (mclasen at redhat.com) wants to debate this and > > I'm not sure what to do. I don't have any arguments other than > > directory ownership and "that's what the committee decided". > > My comments (put in bugzilla and discussed on IRC last night) > > Until such time as the filesystem package owns the %{_libdir}/pkgconfig > directory, this guideline will stand. If filesystem owns the directory and we > remove the fact that many packages could end up owning it, we can revisit this > issue and possible remove the necessity on pkgconfig for any file that drops a > .pc file. However the former needs to happen before we discuss the latter. This doesn't make any sense at all. It doesn't make any sense to have /usr/lib[64]/pkgconfig owned by filesystem. And even, for the sake of argument, that it did. You will still be requireing that every package that include a devel package with a .pc also Require pkgconfig in order to parse that .pc file. So by changing the directory ownership from one package to another (which makes absolutely no sense whatsoever) still gains you absolutely nothing, or actually gains you more problems than what we originally had. QED. End of stupid discussion. From jkeating at redhat.com Thu Aug 17 19:35:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 Aug 2006 15:35:54 -0400 Subject: [Fedora-packaging] The .pc and pkgconfig issue In-Reply-To: References: <200608170751.26768.jkeating@redhat.com> Message-ID: <200608171535.55055.jkeating@redhat.com> On Thursday 17 August 2006 15:07, Christopher Stone wrote: > It doesn't make any sense to have /usr/lib[64]/pkgconfig owned by > filesystem. > > And even, for the sake of argument, that it did. > > You will still be requireing that every package that include a devel > package with a .pc also Require pkgconfig in order to parse that .pc > file. ?So by changing the directory ownership from one package to > another (which makes absolutely no sense whatsoever) still gains you > absolutely nothing, or actually gains you more problems than what we > originally had. You'll note that I said 'discuss'. We have things like filesystem owning /usr/libexec/ which isn't part of the FHS (yet) but used by a lot of our packages. Some folks have asked that filesystem own %{_libdir}/pkgconfig/ too. I haven't stated whether or not this is a good idea, just that it has been requested. I also didn't say we'd automatically remove the need for Requires: pkgconfig, I said we'd discuss it. As a preemptive strike, we discussed it in our meeting this week and decided that we wouldn't change the guidelines at all, things that have a .pc file should have a Require: pkgconfig, end of story. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Aug 18 02:42:16 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 17 Aug 2006 21:42:16 -0500 Subject: [Fedora-packaging] mixed-use-of-spaces-and-tabs Message-ID: Does anyone else find this rpmlint warning annoying? Do we really care that much about how packagers make things line up, or whether they make things line up at all? I can see a problem with mixing tabs and spaces on a single line, but the warning triggers when it finds both three consecutive spaces and a single tab anywhere in the specfile. - J< From wtogami at redhat.com Fri Aug 18 03:20:28 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 17 Aug 2006 23:20:28 -0400 Subject: [Fedora-packaging] Friday 1PM EDT IRC Meeting Message-ID: <44E531FC.1060503@redhat.com> It seems that most of the stakeholders would prefer an IRC meeting instead of a teleconference call. We will meet in #fedora-packaging at 1PM EDT Friday (same time of day as FESCO meetings) to discuss this topic. Warren Togami wtogami at redhat.com From ville.skytta at iki.fi Fri Aug 18 10:11:57 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 18 Aug 2006 13:11:57 +0300 Subject: [Fedora-packaging] kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <20060817113614.GE5485@neu.nirvana> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> Message-ID: <1155895917.2784.16.camel@localhost.localdomain> On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote: > I have added this argument to the wiki. kmdls allow you to bolster > your oen kernel package called my-special-kernel-2.6.18-111 and > support it with kmdls. [...] > kmdls fully support custom kernel rpms. This is one new example about the inaccuracies/omissions of the current Wiki docs and belongs in the area I don't think makes sense to even discuss at the moment, but because "FUD" appeared in one of the responses to my previous message, I'll bite: And kmods don't because they require specific Provides from the target kernel? Requires: /boot/vmlinuz-* is a no go, it's non-portable (example: ia64) and not arch-qualified (example: possible i586/i686 modules/kernel mismatch). If the argument is that implementation of the kmdl macros can be changed according to what's available in the target system, so can kmodtool and the related macros. From ville.skytta at iki.fi Fri Aug 18 10:17:22 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 18 Aug 2006 13:17:22 +0300 Subject: [Fedora-packaging] kmod: $1 in %post and firends broken (was: Kernel Module Packaging Standard Teleconference) In-Reply-To: <20060817114019.GF5485@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <1155753896.2662.64.camel@localhost> <20060816203054.GD27375@neu.nirvana> <20060817114019.GF5485@neu.nirvana> Message-ID: <1155896242.2784.22.camel@localhost.localdomain> On Thu, 2006-08-17 at 13:40 +0200, Axel Thimm wrote: > usage of $1 in kmods'scriplets is broken. Why would it be necessary to use it in the first place? From ville.skytta at iki.fi Fri Aug 18 10:25:03 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 18 Aug 2006 13:25:03 +0300 Subject: [Fedora-packaging] mixed-use-of-spaces-and-tabs In-Reply-To: References: Message-ID: <1155896703.2784.27.camel@localhost.localdomain> On Thu, 2006-08-17 at 21:42 -0500, Jason L Tibbitts III wrote: > Does anyone else find this rpmlint warning annoying? Some people sure do: http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/19 http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/37 Whether it gets filtered in the future or not, implementation improvements are welcome, preferably posted to the above upstream tracker. From Axel.Thimm at ATrpms.net Fri Aug 18 10:34:47 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 Aug 2006 12:34:47 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <1155895917.2784.16.camel@localhost.localdomain> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> Message-ID: <20060818103447.GB27801@neu.nirvana> On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skytt? wrote: > On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote: > > > I have added this argument to the wiki. kmdls allow you to bolster > > your oen kernel package called my-special-kernel-2.6.18-111 and > > support it with kmdls. > [...] > > kmdls fully support custom kernel rpms. > > This is one new example about the inaccuracies/omissions of the current > Wiki docs and belongs in the area I don't think makes sense to even > discuss at the moment, but because "FUD" appeared in one of the > responses to my previous message, I'll bite: FUD appeared due to making vague statements against something w/o backing them up. You yourself described that as "sucks". > And kmods don't because they require specific Provides from the target > kernel? Requires: /boot/vmlinuz-* is a no go, it's non-portable > (example: ia64) and not arch-qualified (example: possible i586/i686 > modules/kernel mismatch). arch is no issue, it's the same mechanism as for the kernel itself (so if it is an issue you have much bigger problems to worry about - still even then the kmdls would arch-match with the kernel), and ia64 has yet to become an official FC distribution. Currently it is banned onto the shoulders of IBM. BTW I've been asked to rebuild ATrpms for ia64 and maybe they'll even ship ia64 hardware to me. The current choice covers all sensible archs and all sensible distributions including RHEL3 and even RHL7.3-RH9 (probably even earlier). It also covers Mandriva, SuSE and most other rpm distributions. Yes, who cares about RH9, but a lot still care about RHEL and allowing access to other distributions increases the cross-distribution acceptance and make chances for a common standard even better. And to cut to the chase: Ever tried to support special kernel rpms like swsusp2 or ccrma's low-latency kernels? I did and know it works for kmdl and will fail with kmod. > If the argument is that implementation of the kmdl macros can be changed > according to what's available in the target system, so can kmodtool and > the related macros. W/o a src.rpm/userland rebuild including evr bumps and w/o having to split src.rpms per distro? That's a very big difference. You can use kmdl src.rpm today on RHEL3 or SuSE w/o a change. And on any arbitray custom kernel package, which was what this point is about. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Aug 18 10:54:06 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 18 Aug 2006 12:54:06 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <20060818103447.GB27801@neu.nirvana> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> Message-ID: <44E59C4E.3040205@leemhuis.info> Axel Thimm schrieb: > On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skytt? wrote: >> On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote: [ignoring the FUD debatte] [ignoring the arch debatte] > And to cut to the chase: Ever tried to support special kernel rpms > like swsusp2 or ccrma's low-latency kernels? I did and know it works > for kmdl and will fail with kmod. I looked into this once and I'd like to give people a bit more background from my point of view: Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. But that's not directly a bug/problem in kmod. kmods would work if the swsusp2 kernel would be packaged exactly in the same way as the FC kernels are packaged. But that's not the case. CU thl From Axel.Thimm at ATrpms.net Fri Aug 18 10:58:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 Aug 2006 12:58:27 +0200 Subject: [Fedora-packaging] Re: kmod: $1 in %post and firends broken (was: Kernel Module Packaging Standard Teleconference) In-Reply-To: <1155896242.2784.22.camel@localhost.localdomain> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <1155753896.2662.64.camel@localhost> <20060816203054.GD27375@neu.nirvana> <20060817114019.GF5485@neu.nirvana> <1155896242.2784.22.camel@localhost.localdomain> Message-ID: <20060818105827.GC27801@neu.nirvana> On Fri, Aug 18, 2006 at 01:17:22PM +0300, Ville Skytt? wrote: > On Thu, 2006-08-17 at 13:40 +0200, Axel Thimm wrote: > > > usage of $1 in kmods'scriplets is broken. > > Why would it be necessary to use it in the first place? Don't you see any neccessity in having kmdls able to distinguish between being first time installed/upgraded/removed? I'm not making use of $1 in kmdls, but I can very well think of some use cases: o storage drivers that need to place themselves in initrd (actually that is a missing feature often reported on qla modules at ATrpms) o creating device drivers for systems w/o dynamic /dev (like RHEL3) o signaling a daemon to either start/reload firmware/stop like the case with ipw3945 & daemon - additionally needs a check whether the operation is for the running kernel. This is also an unfinshed item of ATrpms' kmdls for ipw3945 (there is additionally a racing during installation of kmdls and the daemon and needs to be addressed upstream, but that's off-topic) You can think of other situations where you do want to know whether this package is upgrade/first-time installed/removed. But to be fair exactly because $1 is not in present use I rated this bug low in the ratings column. Dropping mechanisms to support a broken scheme just because you don't yet have a current need for that mechanism is wrong. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Aug 18 11:03:38 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 18 Aug 2006 14:03:38 +0300 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <20060818103447.GB27801@neu.nirvana> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> Message-ID: <1155899018.2784.38.camel@localhost.localdomain> On Fri, 2006-08-18 at 12:34 +0200, Axel Thimm wrote: > arch is no issue [...] and ia64 has yet to become an official FC > distribution. [...] The current choice covers all sensible archs and > all sensible distributions [...] 'nuff said, thanks. From Axel.Thimm at ATrpms.net Fri Aug 18 11:11:38 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 Aug 2006 13:11:38 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <44E59C4E.3040205@leemhuis.info> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> <44E59C4E.3040205@leemhuis.info> Message-ID: <20060818111138.GD27801@neu.nirvana> On Fri, Aug 18, 2006 at 12:54:06PM +0200, Thorsten Leemhuis wrote: > > > Axel Thimm schrieb: > > On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skytt? wrote: > >> On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote: > > [ignoring the FUD debatte] > > [ignoring the arch debatte] > > > And to cut to the chase: Ever tried to support special kernel rpms > > like swsusp2 or ccrma's low-latency kernels? I did and know it works > > for kmdl and will fail with kmod. > > I looked into this once and I'd like to give people a bit more > background from my point of view: > > Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. > But that's not directly a bug/problem in kmod. kmods would work if the > swsusp2 kernel would be packaged exactly in the same way as the FC > kernels are packaged. But that's not the case. which was done deliberately to not conflict with having the same name with a Fedora package, just as the highest mandate coming from Fedora to 3rd parties is, right? Just FYI FC4 packages do still have the same name with FC, "kernel", which means that once you start using a swsups2 kernel your normal vendor kernels don't get updated because swsups2 is evr-newer. And CCRMA's kernel had been following the "kernel" naming, but have lower evr that the vendor's, which mean that yum doesn't ever upgrade the CCRMA kernel. CCRMA therefore had to replace FC's yum with a pathced version. So both cases in 'packaged exactly in the same way as the FC kernels' are rather disastrous and in automatic conflict with other FC credos like no replacing of core packages like kernel/yum. Pick your choice in kmod land: o lock in onto custom kernels due to exact naming with the vendor's o no updates to your custom kernel due to exact naming with the vendor's o no support for custom kernels due to different naming with the vendor's ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Aug 18 11:14:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 Aug 2006 13:14:05 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <1155899018.2784.38.camel@localhost.localdomain> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> <1155899018.2784.38.camel@localhost.localdomain> Message-ID: <20060818111405.GE27801@neu.nirvana> On Fri, Aug 18, 2006 at 02:03:38PM +0300, Ville Skytt? wrote: > On Fri, 2006-08-18 at 12:34 +0200, Axel Thimm wrote: > > > arch is no issue [...] and ia64 has yet to become an official FC > > distribution. [...] The current choice covers all sensible archs and > > all sensible distributions [...] > > 'nuff said, thanks. Removing quoting is a serious form of misquoting. I gave explanations to the above in what you removed. As you quote them the statement sounds far different that in the proper context. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Aug 18 11:30:06 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 18 Aug 2006 13:30:06 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <20060818111138.GD27801@neu.nirvana> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> <44E59C4E.3040205@leemhuis.info> <20060818111138.GD27801@neu.nirvana> Message-ID: <44E5A4BE.8050506@leemhuis.info> Axel Thimm schrieb: > On Fri, Aug 18, 2006 at 12:54:06PM +0200, Thorsten Leemhuis wrote: >> >> Axel Thimm schrieb: >>> On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skytt? wrote: >>>> On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote: >>> And to cut to the chase: Ever tried to support special kernel rpms >>> like swsusp2 or ccrma's low-latency kernels? I did and know it works >>> for kmdl and will fail with kmod. >> I looked into this once and I'd like to give people a bit more >> background from my point of view: >> >> Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. >> But that's not directly a bug/problem in kmod. kmods would work if the >> swsusp2 kernel would be packaged exactly in the same way as the FC >> kernels are packaged. But that's not the case. > > which was done deliberately to not conflict with having the same name > with a Fedora package, just as the highest mandate coming from Fedora > to 3rd parties is, right? Right, but it can be done in different ways, e.g. in a ways, that follows the general naming and file-placing behavior from the Fedora kernels or in ways that differ -- in case of the swsusp the latter was chosen. CU thl From Axel.Thimm at ATrpms.net Fri Aug 18 11:38:45 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 Aug 2006 13:38:45 +0200 Subject: [Fedora-packaging] Re: kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file In-Reply-To: <44E402FD.4000301@leemhuis.info> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <44E402FD.4000301@leemhuis.info> Message-ID: <20060818113845.GG27801@neu.nirvana> On Thu, Aug 17, 2006 at 07:47:41AM +0200, Thorsten Leemhuis wrote: > >Also flavours may come and go within a distribution's life cycle. For > >example a few weeks ago "xen" was added to FC5 along "xen0". No need > >to touch specfile/src.rpm/userland in the kmdl scheme to add > >supportfor the newcomer. For example the sole representant of kmods in > >FE is em8300. Where is his "xen" flavour? > > You'd have to ask scop. Maybe it didn't build, don't know. But just as > above: there is no difference between kmdls and kmods when the buildsys > handles that. In the kmod case the buildsys can simply run > > rpmbuild kmod-foo.src.rpm --define 'kversion 2.6.17-1.2145_FC5' --define > 'kvariants "" smp xen xen0 XenU bigsmp never_have_heard_of_flavor' > > and it's build as long as never_have_heard_of_flavor exists -- no > modifications to the specfile needed. And adding to my reply: It first looks as if the kmod scheme could now build some flavours apart form others. But due to the bundling of building all flavours together and sharing *one* debuginfo package for all kmods this is impossible, or possible, but would nuke the "old" debuginfo package from the previous build. kmdls have one debuginfo per kmdl, therefore you can build flavour/kernels/custon kernels/custom flavours at your own pace w/o the need to rebuild all each time. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Aug 18 12:55:18 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 Aug 2006 14:55:18 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <44E5A4BE.8050506@leemhuis.info> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> <44E59C4E.3040205@leemhuis.info> <20060818111138.GD27801@neu.nirvana> <44E5A4BE.8050506@leemhuis.info> Message-ID: <20060818125518.GH27801@neu.nirvana> On Fri, Aug 18, 2006 at 01:30:06PM +0200, Thorsten Leemhuis wrote: > > > Axel Thimm schrieb: > > On Fri, Aug 18, 2006 at 12:54:06PM +0200, Thorsten Leemhuis wrote: > >> > >> Axel Thimm schrieb: > >>> On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skytt? wrote: > >>>> On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote: > >>> And to cut to the chase: Ever tried to support special kernel rpms > >>> like swsusp2 or ccrma's low-latency kernels? I did and know it works > >>> for kmdl and will fail with kmod. > >> I looked into this once and I'd like to give people a bit more > >> background from my point of view: > >> > >> Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. > >> But that's not directly a bug/problem in kmod. kmods would work if the > >> swsusp2 kernel would be packaged exactly in the same way as the FC > >> kernels are packaged. But that's not the case. > > > > which was done deliberately to not conflict with having the same name > > with a Fedora package, just as the highest mandate coming from Fedora > > to 3rd parties is, right? > > Right, but it can be done in different ways, e.g. in a ways, that > follows the general naming and file-placing behavior from the Fedora > kernels or in ways that differ -- in case of the swsusp the latter was > chosen. Just outline a way that custom kernel packages could be created Fedora-conform and be supported by kmods, because I just stated in the mail you replied to, that this is impossible: If you follow Fedora compliance you lose kmod support, if you follow kmod compliance you lose Fedora compliance. I also showed real life examples for all cases. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Aug 18 13:02:10 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Aug 2006 09:02:10 -0400 Subject: [Fedora-packaging] Friday 1PM EDT IRC Meeting In-Reply-To: <44E531FC.1060503@redhat.com> References: <44E531FC.1060503@redhat.com> Message-ID: <200608180902.10325.jkeating@redhat.com> On Thursday 17 August 2006 23:20, Warren Togami wrote: > We will meet in #fedora-packaging at 1PM EDT Friday (same time of day as > FESCO meetings) to discuss this topic. I may be signing papers on a condo at this time. Unknown. :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Aug 18 13:02:52 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 18 Aug 2006 15:02:52 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <20060818125518.GH27801@neu.nirvana> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> <44E59C4E.3040205@leemhuis.info> <20060818111138.GD27801@neu.nirvana> <44E5A4BE.8050506@leemhuis.info> <20060818125518.GH27801@neu.nirvana> Message-ID: <44E5BA7C.7040007@leemhuis.info> Axel Thimm schrieb: > On Fri, Aug 18, 2006 at 01:30:06PM +0200, Thorsten Leemhuis wrote: >> >> Axel Thimm schrieb: >>> On Fri, Aug 18, 2006 at 12:54:06PM +0200, Thorsten Leemhuis wrote: >>>> Axel Thimm schrieb: >>>>> On Fri, Aug 18, 2006 at 01:11:57PM +0300, Ville Skytt? wrote: >>>>>> On Thu, 2006-08-17 at 13:36 +0200, Axel Thimm wrote: >>>>> And to cut to the chase: Ever tried to support special kernel rpms >>>>> like swsusp2 or ccrma's low-latency kernels? I did and know it works >>>>> for kmdl and will fail with kmod. >>>> I looked into this once and I'd like to give people a bit more >>>> background from my point of view: >>>> >>>> Yes, kmod fails for the swsusp2 kernel from http://mhensler.de/swsusp/. >>>> But that's not directly a bug/problem in kmod. kmods would work if the >>>> swsusp2 kernel would be packaged exactly in the same way as the FC >>>> kernels are packaged. But that's not the case. >>> which was done deliberately to not conflict with having the same name >>> with a Fedora package, just as the highest mandate coming from Fedora >>> to 3rd parties is, right? >> Right, but it can be done in different ways, e.g. in a ways, that >> follows the general naming and file-placing behavior from the Fedora >> kernels or in ways that differ -- in case of the swsusp the latter was >> chosen. > Just outline a way that custom kernel packages could be created > Fedora-conform and be supported by kmods, Just use the same scheme that a new flavor in the main package would use. CU thl From jkeating at redhat.com Fri Aug 18 13:07:32 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Aug 2006 09:07:32 -0400 Subject: [Fedora-packaging] mixed-use-of-spaces-and-tabs In-Reply-To: <1155896703.2784.27.camel@localhost.localdomain> References: <1155896703.2784.27.camel@localhost.localdomain> Message-ID: <200608180907.32665.jkeating@redhat.com> On Friday 18 August 2006 06:25, Ville Skytt? wrote: > Whether it gets filtered in the future or not, implementation > improvements are welcome, preferably posted to the above upstream > tracker. Hrm, I think I'll have to file a bug then, as the check is triggering on one of my specs and for the life of me I can't find out why. It would be supremely helpful of this warning would give you a line number where the problem is.... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From panemade at gmail.com Fri Aug 18 13:33:34 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 18 Aug 2006 19:03:34 +0530 Subject: [Fedora-packaging] mixed-use-of-spaces-and-tabs In-Reply-To: <200608180907.32665.jkeating@redhat.com> References: <1155896703.2784.27.camel@localhost.localdomain> <200608180907.32665.jkeating@redhat.com> Message-ID: Hi, On 8/18/06, Jesse Keating wrote: > On Friday 18 August 2006 06:25, Ville Skytt? wrote: > > Whether it gets filtered in the future or not, implementation > > improvements are welcome, preferably posted to the above upstream > > tracker. > > Hrm, I think I'll have to file a bug then, as the check is triggering on one > of my specs and for the life of me I can't find out why. It would be > supremely helpful of this warning would give you a line number where the > problem is.... Yeah that will be better if that warning will give you line number also. Regards, Parag. From opensource at till.name Fri Aug 18 13:48:23 2006 From: opensource at till.name (Till Maas) Date: Fri, 18 Aug 2006 15:48:23 +0200 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? Message-ID: <200608181548.47138.opensource@till.name> Hiyas, the Packaging Guidelines contradict itself about the usage of %makeinstall http://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d0dbcfbdd2fcb7791dd002 The headline says "Why the %makeinstall macro should not be used" and the first sentence says "RPM, as included in Fedora, includes a %makeinstall macro, but you must NOT use this macro in Fedora packages." It seems to be used by a lot of maintainers, so is this just a should not or is this another candidate for a major specfile-cleanup project? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Aug 18 13:50:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 18 Aug 2006 16:50:19 +0300 Subject: [Fedora-packaging] mixed-use-of-spaces-and-tabs In-Reply-To: References: <1155896703.2784.27.camel@localhost.localdomain> <200608180907.32665.jkeating@redhat.com> Message-ID: <1155909019.2784.67.camel@localhost.localdomain> On Fri, 2006-08-18 at 19:03 +0530, Parag N(????) wrote: > Hi, > On 8/18/06, Jesse Keating wrote: > > On Friday 18 August 2006 06:25, Ville Skytt? wrote: > > > Whether it gets filtered in the future or not, implementation > > > improvements are welcome, preferably posted to the above upstream > > > tracker. > > > > Hrm, I think I'll have to file a bug then, as the check is triggering on one > > of my specs and for the life of me I can't find out why. It would be > > supremely helpful of this warning would give you a line number where the > > problem is.... > > Yeah that will be better if that warning will give you line number also. The next release will do that: http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/28 http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1221 From opensource at till.name Fri Aug 18 13:58:24 2006 From: opensource at till.name (Till Maas) Date: Fri, 18 Aug 2006 15:58:24 +0200 Subject: [Fedora-packaging] Do we need a Rule "Docs should be packaged as %doc"? In-Reply-To: <44D867D6.50708@leemhuis.info> References: <44D867D6.50708@leemhuis.info> Message-ID: <200608181558.24837.opensource@till.name> Am Dienstag, 8. August 2006 12:30 schrieb Thorsten Leemhuis: > Subject says it all. > Subject: Do we need a Rule "Docs should be packaged as %doc"? We should package documentation with %doc to ensure that $ rpm -q --docfiles works. It displays every documentation of a package and is thus very usefull to find documentation unless the documentation is not marked as such. Regards, Till From paul at city-fan.org Fri Aug 18 14:03:44 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 18 Aug 2006 15:03:44 +0100 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <200608181548.47138.opensource@till.name> References: <200608181548.47138.opensource@till.name> Message-ID: <44E5C8C0.1010907@city-fan.org> Till Maas wrote: > Hiyas, > > the Packaging Guidelines contradict itself about the usage of %makeinstall > > http://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d0dbcfbdd2fcb7791dd002 > > The headline says "Why the %makeinstall macro should not be used" and the > first sentence says "RPM, as included in Fedora, includes a %makeinstall > macro, but you must NOT use this macro in Fedora packages." > > It seems to be used by a lot of maintainers, so is this just a should not or > is this another candidate for a major specfile-cleanup project? Whoever wrote this text misrepresents the conclusion of the discussion that lead to its inclusion I think. "make DESTDIR=%{buildroot} install" should be *preferred* when it works, but there are times when %makeinstall works and there is no DESTDIR support in a package's Makefiles, so writing this as a "must not" as it is at the moment is just daft IMHO. Paul. From toshio at tiki-lounge.com Fri Aug 18 14:43:40 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 18 Aug 2006 07:43:40 -0700 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <44E5C8C0.1010907@city-fan.org> References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> Message-ID: <1155912220.4800.8.camel@localhost> On Fri, 2006-08-18 at 15:03 +0100, Paul Howarth wrote: > Till Maas wrote: > > Hiyas, > > > > the Packaging Guidelines contradict itself about the usage of %makeinstall > > > > http://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d0dbcfbdd2fcb7791dd002 > > > > The headline says "Why the %makeinstall macro should not be used" and the > > first sentence says "RPM, as included in Fedora, includes a %makeinstall > > macro, but you must NOT use this macro in Fedora packages." > > > > It seems to be used by a lot of maintainers, so is this just a should not or > > is this another candidate for a major specfile-cleanup project? > > Whoever wrote this text misrepresents the conclusion of the discussion > that lead to its inclusion I think. > > "make DESTDIR=%{buildroot} install" should be *preferred* when it works, > but there are times when %makeinstall works and there is no DESTDIR > support in a package's Makefiles, so writing this as a "must not" as it > is at the moment is just daft IMHO. Does this make more sense? "Fedora's RPM includes a %makeinstall macro but it must NOT be used when make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge that can work with broken Makefiles that don't make use of the DESTDIR variable but it has the following potential issues:" -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jcm at redhat.com Fri Aug 18 14:51:10 2006 From: jcm at redhat.com (Jon Masters) Date: Fri, 18 Aug 2006 15:51:10 +0100 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155789678.7629.11.camel@mccallum.corsepiu.local> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155735970.15307.250.camel@localhost.localdomain> <1155780125.27621.166.camel@mccallum.corsepiu.local> <1155789678.7629.11.camel@mccallum.corsepiu.local> Message-ID: <1155912670.9148.596.camel@localhost.localdomain> On Thu, 2006-08-17 at 06:41 +0200, Ralf Corsepius wrote: > Agreed, like we agree upon "apps go to %{_bindir}", "libs go to > %{_libdir}", we need a clear and strict convention on where > kernel-modules need to be installed. There is *no need* for kernel modules to go in /lib/modules/kver at all - that's just a convention for built-in kernel modules and I see no reason why we can't have m-i-t pick up modules from other sane locations too. If we can persuade people to use proper MODULE_VERSION()s then we can also sanely decide about which of several versions to use. Here's one random (not thought it all through) idea: * Install modules in %{_moduledir}/modulename/kver Then an RPM provides just the module for whatever kernel versions it wants. But we still need to solve the issue of compatible modules. I quite like the idea of insmod/depmod no longer basing its decisions on data available from depmod using the location of the module, but the compatibility of the module (kABI checks). So we say this: * m-i-t tries to load %{_moduledir/modulename/this_kver * m-i-t falls back on %{_moduledir/modulename/configured_ordering * m-i-t falls back on /lib/modules/this_kernel And weak-modules goes byebye because we don't need symlinks any more. We make depmod and insmod/modprobe much more configurable and ship a def. config with some sane options, but allow anyone to have old behavior or more configurable and flexible behavior depending on their config. What I'm saying is that I'm happy to try out some pretty radical solutions to this problem now that I'm maintaining m-i-t. If we can have a serious discussion about what we *want* from a "perfect system" then we can make it happen properly upstream and get other folks involved - we're not the only people who want to package up modules and agree on standardized locations and mechanisms for choosing updated drivers. I have spoken to the folks at SuSE/Novell and Ubuntu about driver packaging - though not all the interested parties. I would /really/ like it if some of these non-RPM-specific issues could get solved generally or at least involve the other players who actually use the tools. I am however /very/ sure that I don't want to try radical stuff ahead of lots of community involvement. In Fedora terms, that means my own personal view is it's way too late to be changing things for FC6 (unless it's decided it's not). I would like us to get somewhere today/this week/whenever towards sensible discussion of ways to fix the problems we have in FC7/etc. and beyond - where IMO we have the time to spend on it. Jon. -- Jon Masters Phone: +44 7776 131337 Red Hat UK, Ltd. Email: jcm at redhat.com From paul at city-fan.org Fri Aug 18 14:53:01 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 18 Aug 2006 15:53:01 +0100 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <1155912220.4800.8.camel@localhost> References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> Message-ID: <44E5D44D.20207@city-fan.org> Toshio Kuratomi wrote: > On Fri, 2006-08-18 at 15:03 +0100, Paul Howarth wrote: >> Till Maas wrote: >>> Hiyas, >>> >>> the Packaging Guidelines contradict itself about the usage of %makeinstall >>> >>> http://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d0dbcfbdd2fcb7791dd002 >>> >>> The headline says "Why the %makeinstall macro should not be used" and the >>> first sentence says "RPM, as included in Fedora, includes a %makeinstall >>> macro, but you must NOT use this macro in Fedora packages." >>> >>> It seems to be used by a lot of maintainers, so is this just a should not or >>> is this another candidate for a major specfile-cleanup project? >> Whoever wrote this text misrepresents the conclusion of the discussion >> that lead to its inclusion I think. >> >> "make DESTDIR=%{buildroot} install" should be *preferred* when it works, >> but there are times when %makeinstall works and there is no DESTDIR >> support in a package's Makefiles, so writing this as a "must not" as it >> is at the moment is just daft IMHO. > > Does this make more sense? > > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > that can work with broken Makefiles that don't make use of the DESTDIR > variable but it has the following potential issues:" WORKSFORME. Paul. From mattdm at mattdm.org Fri Aug 18 14:53:09 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 18 Aug 2006 10:53:09 -0400 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <1155912220.4800.8.camel@localhost> References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> Message-ID: <20060818145309.GA12458@jadzia.bu.edu> > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when ^^^^ "should"? > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > that can work with broken Makefiles that don't make use of the DESTDIR > variable but it has the following potential issues:" What if it doesn't have those issues in a particular case? Also, I'm not sure it's particularly fair to use the term "broken" for makefiles which don't include a DESTDIR variable. As far as I'm aware, that's not a _requirement_ for a makefile -- just a handy convention. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jcm at redhat.com Fri Aug 18 15:08:49 2006 From: jcm at redhat.com (Jon Masters) Date: Fri, 18 Aug 2006 16:08:49 +0100 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <20060817070157.GG27375@neu.nirvana> References: <44E263DA.2030806@redhat.com> <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <44E35F52.6030901@leemhuis.info> <20060816203634.GE27375@neu.nirvana> <1155765871.9148.540.camel@localhost.localdomain> <20060817070157.GG27375@neu.nirvana> Message-ID: <1155913729.9148.613.camel@localhost.localdomain> On Thu, 2006-08-17 at 09:01 +0200, Axel Thimm wrote: > The suggestion Thorsten is implying is that you should try under > > /lib/modules/*/foo/1/1.2.3/2 > /lib/modules/*/foo/1/1.2.3/1 > /lib/modules/*/foo/1/1.2.2/1 > /lib/modules/*/foo/0/10/1 > > in that order for several coinstalled versions of foo *for the same > kernel* (the folder names are epoch/version/release), and you would > have to use rpmvercmp to compare the folder names. > > That's a package problem that is being pushed to the wrong domain. For > the same kernel (or kabi) the module should have one version > installed. Otherwise the argument of having multiple versions of > anything, not only kernel modules applies. That's a problem. Some people genuinely want to have more than one version of a module installed - I think in the longer run that this would be a good thing to be able to support, though I much prefer using modinfo meta-data to solve it rather than the file location. We should compel people to use module versions properly in their source code IMO since it's deliberately designed to support what we need from it - and it's trivial enough to warn on build/load of non-kernel provided modules that they don't have good version info inside. > > With kabi checking enabled (if you package with kABI deps) then you get > > for free the compatibility links automatically added/removed on module > > install/remove so older kernels can use a more recent kmod. You will be > > able to ultimately instruct module-init-tools to always use the version > > of a module in weak-updates over the built-in kernel and thereby get a > > given module to always be available to all compatible installed kernels. > > The relation is different between what you and Thorsten think. It's > many kernel modules *for* the same kernel vs many kernel modules *from > different* kernels/kabis. *** The following is for explanatory purposes, not part of thread *** Yeah. We're talking about different things here - I'm just trying to clarify what I've done with the kABI stuff because I didn't really get at this part of the problem before. Let's say this happens (this is more of a RHEL-type problem but *not exclusively* so I mention it here): * Fedora kernel provides module foo. * Module is upgraded with kmod to bar with different compile options. Now, if we upgrade the kernel then we might upgrade to a newer and more improved module that happens also to make my root device unavailable because it broke on hardware X. So in that case we want to supply a depmod configuration file along with the kmod files that tells depmod to *always* use the kmod rather than the built-in driver from a newer kernel - i.e. override the weak-updates logic we're using which says that newer kernels always contain better versions of the module. This isn't the OO problem. OpenOffice doesn't run the risk of breaking your hardware on upgrade and people don't usually want to be able to use different builds of OO from many different locations. With external drivers not provided in Core we are *specifically allowing* people to have several different builds of the same driver in different RPMs. *** end of off-topic bit *** > If the newer pakcage is broken, downgrade to the previous is the > typical solution, not coinstall all under the sun :) Indeed. Though there's the complication that we'd ideally like to not prevent the system from booting when it's been upgraded remotely. This is not something that is addressed at the moment :-) > > My personal opinion is that it's too late to change kmods drastically in > > FC6. > I agree, my suggestion is not to change, but to dump :) Dude. We're on T2 right now. In 6 months, there'll be another Fedora and during that time we have plenty of scope to look at this some more. IMHO you haven't shown *compelling* evidence for kmods to be dropped in FC6 but instead have highlighted some issues to be looked at for FC7. Jon. -- Jon Masters Phone: +44 7776 131337 Red Hat UK, Ltd. Email: jcm at redhat.com From toshio at tiki-lounge.com Fri Aug 18 15:22:43 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 18 Aug 2006 08:22:43 -0700 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <20060818145309.GA12458@jadzia.bu.edu> References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <20060818145309.GA12458@jadzia.bu.edu> Message-ID: <1155914563.4800.28.camel@localhost> On Fri, 2006-08-18 at 10:53 -0400, Matthew Miller wrote: > > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > ^^^^ > > "should"? > "must" was intentional. Let's see what the arguments pro/con "should" are. > > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > > that can work with broken Makefiles that don't make use of the DESTDIR > > variable but it has the following potential issues:" > > What if it doesn't have those issues in a particular case? > It must still use make install DESTDIR=%{buildroot}. When reviewing the package you have to assume that %makeinstall has broken something and check for problems that could result from that. Theoretically, the packager has performed those checks as well so there's a lot more work involved with using %makeinstall than from using DESTDIR. > Also, I'm not sure it's particularly fair to use the term "broken" for > makefiles which don't include a DESTDIR variable. As far as I'm aware, > that's not a _requirement_ for a makefile -- just a handy convention. > That's a good criticism. I hesitated over using broken or old and chose the least inaccurate. Do you have a better word or phrase to describe them? Non-compliant with GNU standards for Makefiles is accurate but overly limiting in scope. Maybe simply removing the adjective describing Makefiles altogether? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri Aug 18 17:02:52 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 18 Aug 2006 12:02:52 -0500 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <1155912220.4800.8.camel@localhost> (Toshio Kuratomi's message of "Fri, 18 Aug 2006 07:43:40 -0700") References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> Does this make more sense? Absolutely. Count this as a +1 for that wording if someone wants to vote on the list. - J< From toshio at tiki-lounge.com Fri Aug 18 19:02:32 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 18 Aug 2006 12:02:32 -0700 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> Message-ID: <1155927752.2982.5.camel@localhost> On Fri, 2006-08-18 at 12:02 -0500, Jason L Tibbitts III wrote: > >>>>> "TK" == Toshio Kuratomi writes: > > TK> Does this make more sense? > > Absolutely. Count this as a +1 for that wording if someone wants to > vote on the list. > Great! List voting would be perfect for little clarifications like this. I've removed the "broken" from the text but otherwise left this the same. If we can get six packaging committee members to vote +1 on it, I'll put it into ratify. "Fedora's RPM includes a %makeinstall macro but it must NOT be used when make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge that can work with Makefiles that don't make use of the DESTDIR variable but it has the following potential issues:" -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Fri Aug 18 19:16:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 18 Aug 2006 14:16:28 -0500 Subject: [Fedora-packaging] Re: %makeinstall - must not or should not use it? References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <1155927752.2982.5.camel@localhost> Message-ID: Toshio Kuratomi wrote: > On Fri, 2006-08-18 at 12:02 -0500, Jason L Tibbitts III wrote: >> >>>>> "TK" == Toshio Kuratomi writes: >> >> TK> Does this make more sense? >> >> Absolutely. Count this as a +1 for that wording if someone wants to >> vote on the list. >> > Great! List voting would be perfect for little clarifications like > this. I've removed the "broken" from the text but otherwise left this > the same. If we can get six packaging committee members to vote +1 on > it, I'll put it into ratify. > > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > that can work with Makefiles that don't make use of the DESTDIR variable > but it has the following potential issues:" +1 -- Rex From toshio at tiki-lounge.com Fri Aug 18 19:36:58 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 18 Aug 2006 12:36:58 -0700 Subject: [Fedora-packaging] Python submodule naming Message-ID: <1155929818.2982.16.camel@localhost> Luke Macken is working on a few python packages for infrastructure and has run across an unanticipated naming issue with python-pastedeploy and python-pastescript[1]_. Our present naming guidelines [2]_ say to use the name of the python module when it is imported. The question is how does this map to submodules? In this case: import paste.deploy import paste.script This could reasonably be named python-pastedeploy or python-paste-deploy. Do we want to specify that submodules be named one or the other or leave it up to the packager? For what it's worth, Debian has python-pastedeploy but also python-twisted-conch so they seem to leave it to the packager ATM. [1]_ https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00676.html [2]_ http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonPython -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Fri Aug 18 20:08:46 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 18 Aug 2006 15:08:46 -0500 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <1155927752.2982.5.camel@localhost> References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <1155927752.2982.5.camel@localhost> Message-ID: <1155931726.17724.8.camel@localhost.localdomain> On Fri, 2006-08-18 at 12:02 -0700, Toshio Kuratomi wrote: > On Fri, 2006-08-18 at 12:02 -0500, Jason L Tibbitts III wrote: > > >>>>> "TK" == Toshio Kuratomi writes: > > > > TK> Does this make more sense? > > > > Absolutely. Count this as a +1 for that wording if someone wants to > > vote on the list. > > > Great! List voting would be perfect for little clarifications like > this. I've removed the "broken" from the text but otherwise left this > the same. If we can get six packaging committee members to vote +1 on > it, I'll put it into ratify. > > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > that can work with Makefiles that don't make use of the DESTDIR variable > but it has the following potential issues:" +1 to that. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Fri Aug 18 20:10:27 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 18 Aug 2006 15:10:27 -0500 Subject: [Fedora-packaging] Python submodule naming In-Reply-To: <1155929818.2982.16.camel@localhost> References: <1155929818.2982.16.camel@localhost> Message-ID: <1155931827.17724.10.camel@localhost.localdomain> On Fri, 2006-08-18 at 12:36 -0700, Toshio Kuratomi wrote: > Luke Macken is working on a few python packages for infrastructure and > has run across an unanticipated naming issue with python-pastedeploy and > python-pastescript[1]_. > > Our present naming guidelines [2]_ say to use the name of the python > module when it is imported. The question is how does this map to > submodules? In this case: > > import paste.deploy > import paste.script > > This could reasonably be named python-pastedeploy or > python-paste-deploy. Do we want to specify that submodules be named one > or the other or leave it up to the packager? > > For what it's worth, Debian has python-pastedeploy but also > python-twisted-conch so they seem to leave it to the packager ATM. Up to developer's discretion, IMHO. Look at what upstream calls it. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From Axel.Thimm at ATrpms.net Fri Aug 18 20:16:52 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 Aug 2006 22:16:52 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <44E5BA7C.7040007@leemhuis.info> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> <44E59C4E.3040205@leemhuis.info> <20060818111138.GD27801@neu.nirvana> <44E5A4BE.8050506@leemhuis.info> <20060818125518.GH27801@neu.nirvana> <44E5BA7C.7040007@leemhuis.info> Message-ID: <20060818201652.GA18162@neu.nirvana> On Fri, Aug 18, 2006 at 03:02:52PM +0200, Thorsten Leemhuis wrote: > Just use the same scheme that a new flavor in the main package would use. That would be for new flavours, not new kernels that share the same set of flavours like the unpatched kernel. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Aug 18 20:24:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Aug 2006 16:24:47 -0400 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <1155927752.2982.5.camel@localhost> References: <200608181548.47138.opensource@till.name> <1155927752.2982.5.camel@localhost> Message-ID: <200608181624.47777.jkeating@redhat.com> On Friday 18 August 2006 15:02, Toshio Kuratomi wrote: > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > make install DESTDIR=%{buildroot} will work. ?%makeinstall is a kludge > that can work with Makefiles that don't make use of the DESTDIR variable > but it has the following potential issues:" +1 -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Aug 18 20:29:19 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 Aug 2006 22:29:19 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference In-Reply-To: <1155913729.9148.613.camel@localhost.localdomain> References: <1155715718.27621.120.camel@mccallum.corsepiu.local> <20060816104301.GC13101@neu.nirvana> <1155746811.2662.6.camel@localhost> <20060816170948.GC20037@neu.nirvana> <20060816172920.GE20037@neu.nirvana> <44E35F52.6030901@leemhuis.info> <20060816203634.GE27375@neu.nirvana> <1155765871.9148.540.camel@localhost.localdomain> <20060817070157.GG27375@neu.nirvana> <1155913729.9148.613.camel@localhost.localdomain> Message-ID: <20060818202919.GB18162@neu.nirvana> On Fri, Aug 18, 2006 at 04:08:49PM +0100, Jon Masters wrote: > On Thu, 2006-08-17 at 09:01 +0200, Axel Thimm wrote: > > > The suggestion Thorsten is implying is that you should try under > > > > /lib/modules/*/foo/1/1.2.3/2 > > /lib/modules/*/foo/1/1.2.3/1 > > /lib/modules/*/foo/1/1.2.2/1 > > /lib/modules/*/foo/0/10/1 > > > > in that order for several coinstalled versions of foo *for the same > > kernel* (the folder names are epoch/version/release), and you would > > have to use rpmvercmp to compare the folder names. > > > > That's a package problem that is being pushed to the wrong domain. For > > the same kernel (or kabi) the module should have one version > > installed. Otherwise the argument of having multiple versions of > > anything, not only kernel modules applies. > > That's a problem. Some people genuinely want to have more than one > version of a module installed - I think in the longer run that this > would be a good thing to be able to support, though I much prefer using > modinfo meta-data to solve it rather than the file location. > > We should compel people to use module versions properly in their source ^^^^^^ That's kernel module authors. Convincing them to use proper versioning is even more difficult than convincing any other upstream author to do the same. Just consider that every module get's its own versioning and some even go back and forth, real-life examples: madwifi and 3w-9xxx. Before you get them to do a proper versioning, we'll have rpm rewritten. Furthermore: Even if the versioning of kernel modules was as "good" as other conventional upstream versioning, you still have the same needs for epochs and releases like for conventional packages: o epoch for when the version seems to go backwards in time in whatever versioning metrics o release for fixing bugs/patching up kernel modules that won't change their version. E.g. if I repackage foo-1.2.3-1 with a fix in foo-1.2.3-2, I don't want to see them both installed at the users' systems and hope m-i-t select the proper one. So when you think about coinstalling modules *for the same kernel/kabi*, you will inevitably both need to introduce full evr semantics on m-i-t level and will have to have rpmvercmp semantics in place. That means coding the evr into the path, since there is no place in the module's metadata *and* the different modules for the same kernel should not overlap. It is wrong to shift rpm's (or the depsolver's) work to m-i-t. We just lose the overview in keeping the packages managed at one place and the problem still needs to be solved. > code IMO since it's deliberately designed to support what we need from > it - and it's trivial enough to warn on build/load of non-kernel > provided modules that they don't have good version info inside. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Fri Aug 18 20:55:47 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 18 Aug 2006 13:55:47 -0700 Subject: [Fedora-packaging] Python submodule naming In-Reply-To: <1155931827.17724.10.camel@localhost.localdomain> References: <1155929818.2982.16.camel@localhost> <1155931827.17724.10.camel@localhost.localdomain> Message-ID: <1155934548.2982.20.camel@localhost> On Fri, 2006-08-18 at 15:10 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-08-18 at 12:36 -0700, Toshio Kuratomi wrote: > > In this case: > > > > import paste.deploy > > import paste.script > > > > This could reasonably be named python-pastedeploy or > > python-paste-deploy. Do we want to specify that submodules be named one > > or the other or leave it up to the packager? > > > > For what it's worth, Debian has python-pastedeploy but also > > python-twisted-conch so they seem to leave it to the packager ATM. > > Up to developer's discretion, IMHO. Look at what upstream calls it. Sounds good to me. If no one objects today, I'll post that to the bugs which are waiting for clarification (as this isn't a Guideline change AFAIS). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri Aug 18 22:48:23 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 18 Aug 2006 17:48:23 -0500 Subject: [Fedora-packaging] Importance of debuginfo packages Message-ID: Often when doing package reviews I find a package that needs some hack in order to get rpmbuild to build a complete debuginfo package. Some of this relates to passing the proper compiler flags and making sure the package doesn't strip its own binaries, which I think is necessary, but occasionally rpmbuild needs the source to be moved around in the build tree, or it needs symlinks flattened or somesuch. These are just hacks to work around rpmbuild deficiencies, and I can understand if packagers are reticent to clutter up their packages for something of unknown value. So, how important is it to have a proper debuginfo package? How much hacking is permissible or necessary in order to achieve that goal? Is an incomplete debuginfo package (that contains, say, the striped debug information but is missing some or all of the source code) still useful, or would it be better to have none at all? - J< From jcm at redhat.com Fri Aug 18 23:57:47 2006 From: jcm at redhat.com (Jon Masters) Date: Sat, 19 Aug 2006 00:57:47 +0100 Subject: [Fedora-packaging] RESEND: REPORT: IRC meeting to discuss kernel module packaging Message-ID: <1155945467.9148.652.camel@localhost.localdomain> [ Original message with attachment exceeded mailing list accepted size ] Hi folks, We just had a little gathering on #fedora-packaging to discuss what to do about kernel module packaging in FC6 and beyond. The logs are attached inline to this message for archival, though none of these points have been put to a vote at this point for an official seal. The inclination of most of us present was to accept my proposal that we fix the fedorakmod plugin to handle older kernels in time for FC6 (that being an identifiable key issue with kmods right now). We should then re-address the whole kernel module packaging standard in the FC7 time-frame with a view to considering how introducing kABI checks, fixing identified failings, and taking on comments from Axel (and others) can best result in an improved packaging system. We decided to have regular IRC meetings following FC6 in order to look again at the packaging process and make some recommendations for a new modified standard for packaging modules. Although we would like not to re-invent the wheel, there are legitimate issues to look at later on. Jon. P.S. http://fremont.jonmasters.org/~jcm/fedora-packaging_20060818.log -- Jon Masters Phone: +44 7776 131337 Red Hat UK, Ltd. Email: jcm at redhat.com From Axel.Thimm at ATrpms.net Sat Aug 19 00:19:25 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 19 Aug 2006 02:19:25 +0200 Subject: [Fedora-packaging] rpm -i, "missing" file conflicts and brokenness with kmods Message-ID: <20060819001925.GA21216@neu.nirvana> In the session today it was stated that rpm -i on packages of the same name does not check file conflicts. Since many people reported that this was the case I thought I missed the latest in rpm bug regression. But that's not the case, at least not on FC5: Cut and paste the two almost identical specfiles at the end of this mail and rpmbuild -bb them. You will get test-1-1.i386.rpm test-2-1.i386.rpm Both containing just /tmp/delmex with contents "XXX" and "YYY". Now try: | # rpm -ihv test-1-1.i386.rpm | Preparing... ########################################### [100%] | 1:test ########################################### [100%] | # rpm -Vp test-2-1.i386.rpm | ..5....TC /tmp/delmex | # rpm -ihv test-2-1.i386.rpm | Preparing... ########################################### [100%] | file /tmp/delmex from install of test-2-1 conflicts with file from package test-1-1 So rpm is not to blame it properly catches the file conflict. Now why do other people claim otherwise, and does it make any difference in the context we we discussing it? It may seem to "work" for other people because: a) either the contents of the test packages they tried were identical, e.g. rpm checks the md5sum of the files, it does not care about package names when it checks for file conflicts, b) or (according to a report from Thorsten) it may be yum that effectively uses rpm -i --replacefiles on the transaction. A yum expert could confirm the latter or not. at least it looks like Thorsten only used yum for testing and not rpm -i. Does it matter at all? In the scope of the discussion not really, it is probably making things worse. The file conflict situation only comes up when some depsolver, be it a human or yum/etc. decides to coinstall a package not meant for coinstallation. In this scope it is for example a release bump in a module for the same kernel. Accidentially using rpm -i on it would - either create the file conflict, in that sense the file conflict is a *guardian institution* - or if the --replacefiles flag is turned on, *WILL OVERWRITE* the old module, maybe even just partially, since the new module package may have a different set of ko files. Even funnier effects may happen if the now overwritten old module still in the rpmdb is tried to be removed. But we're already in a broken state, so who cares whether it can be worse. In a nutshell: o rpm -i behaves properly with file conflicts o yum may for some reason turn of file conflict checking o The file conflict situation is actually WELCOME, as it is a SAFETY precaution to not messing up thing (either by hand or automatically) And this has absolutely nothing to do with whether rpm -i can be applied to kmods, because 1) obviously rpm -i wasn't tested, or wasn't tested with differing contents in the rpm 2) rpm -i SHOULD not be used on kmods when a kmod is already installed for this kernel. 3) If you still go ahead and use rpm -i on a kmod while a kmod is already installed you get the file conflict as stated. 4) If you do the same with yum the new kmod overwrites the old one w/o any warning The desired operation that the kmod should do is only possible in the fedorakmod.py code: Don't touch kmods of other kernels, and upgrade kmods of the target kernel. Still: USAGE OF RPM CLI (-U/-i) IS NOT WORKING WITH KMOD And for all the non-believing Thomases (as in Thomas the evangelist) out there, the everlasting example wrapped as a RHCE question to make it more interesting: kernel-2.6.17 has kmod-foo-1.2.3_2.6.17 installed kernel-2.6.18 has kmod-foo-1.2.3_2.6.18 installed kmod-foo-6.6.6_2.6.18 for kernel 2.6.18 appears. How do you install it in the system above with a single rpm call (e.g. w/o removing the modules before reinstalling them) and w/o disrupting the old kernel's foo support? a) rpm -i b) rpm -U c) not at all Usage of rpm -i/rpm -U on kmod scheme is broken, end of story. I'm still shocked it suddenly was defined working a couple hours earlier today. ======================================================================= test.spec ========= Summary: test Name: test Version: 1 Release: 1 License: l Group: g BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root %description x %install mkdir -p %{buildroot}/tmp echo XXX > %{buildroot}/tmp/delmex %files %defattr(-,root,root,-) /tmp/delmex test2.spec ========== Summary: test Name: test Version: 2 Release: 1 License: l Group: g BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root %description x %install mkdir -p %{buildroot}/tmp echo YYY > %{buildroot}/tmp/delmex %files %defattr(-,root,root,-) /tmp/delmex -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Sat Aug 19 00:24:25 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 18 Aug 2006 20:24:25 -0400 Subject: [Fedora-packaging] rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <20060819001925.GA21216@neu.nirvana> References: <20060819001925.GA21216@neu.nirvana> Message-ID: <1155947065.24935.0.camel@cutter> On Sat, 2006-08-19 at 02:19 +0200, Axel Thimm wrote: > o rpm -i behaves properly with file conflicts > o yum may for some reason turn of file conflict checking There is no code in yum that disables file conflict checking. -sv From fedora at leemhuis.info Fri Aug 18 17:13:19 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 18 Aug 2006 19:13:19 +0200 Subject: [Fedora-packaging] file-conflicts on updates problem Message-ID: <44E5F52F.2030905@leemhuis.info> Hi all! I was looking at the current kmod situation a bit again and tested some stuff and it seems I'm to dump to reproduce the "file-conflicts on updates problem" -- a problem that I saw myself some weeks ago once IIRC and that was multiple times brought into the current discussions by Axel. Seems I'm doing something wrong here. Can somebody tell me that that is? I uploaded two srpms for testing to http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kmod/ for people to reproduce the problem locally. That's not a real kmod, but it uses the kmod-scheme and a "kernel module" for testing which is created by > dd if=/dev/urandom bs=1k count=500 > $RPM_BUILD_ROOT/lib/modules/%{kverrel}${kvariant}/extra/%{kmod_name}/foo.ko Look closer yourself below to understand my confusion. Note, all the yum calls are on FC5 with latest updates, but without the kmod plugin: Prepare the test rpms: > [thl at notebook ~]$ rpmbuild -ba rpmbuild/SPECS/foo-kmod-common.spec > [thl at notebook ~]$ rpmbuild -ba rpmbuild/SPECS/foo-kmod.spec --define 'kversion 2.6.17-1.2157_FC5' --define 'kvariants ""' --define 'thisrelease 1' --target i686 > [thl at notebook ~]$ rpmbuild -ba rpmbuild/SPECS/foo-kmod.spec --define 'kversion 2.6.17-1.2174_FC5' --define 'kvariants ""' --define 'thisrelease 1' --target i686 > [thl at notebook ~]$ rpmbuild -ba rpmbuild/SPECS/foo-kmod.spec --define 'kversion 2.6.17-1.2174_FC5' --define 'kvariants ""' --define 'thisrelease 2' --target i686 [...] Put them in a testrepo: > [thl at notebook ~]$ mkdir -p ~/tmp/testrepo > [thl at notebook ~]$ cp rpmbuild/RPMS/noarch/foo-kmod-common-1.1-1.noarch.rpm rpmbuild/RPMS/i686/kmod-foo-1.1-1.2.6.17_1.2157_FC5.i686.rpm ~/tmp/testrepo/ > [thl at notebook ~]$ createrepo ~/tmp/testrepo > 2/2 - kmod-foo-1.1-1.2.6.17_1.2157_FC5.i686.rpm > Saving Primary metadata > Saving file lists metadata > Saving other metadata Install the first one with yum: > [thl at notebook ~]$ sudo yum --enablerepo=testrepo install kmod-foo > Loading "installonlyn" plugin > Setting up Install Process > Setting up repositories [...] > Parsing package install arguments > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package kmod-foo.i686 0:1.1-1.2.6.17_1.2157_FC5 set to be installed > --> Running transaction check > --> Processing Dependency: foo-kmod-common >= 1.1 for package: kmod-foo > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > ---> Package foo-kmod-common.noarch 0:1.1-1 set to be updated > --> Running transaction check > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > kmod-foo i686 1.1-1.2.6.17_1.2157_FC5 testrepo 504 k > Installing for dependencies: > foo-kmod-common noarch 1.1-1 testrepo 2.2 k > > Transaction Summary > ============================================================================= > Install 2 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > Total download size: 506 k > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Installing: foo-kmod-common ######################### [1/2] > Installing: kmod-foo ######################### [2/2] > WARNING: Module /lib/modules/2.6.17-1.2157_FC5/extra/foo/foo.ko is not an elf object > > Installed: kmod-foo.i686 0:1.1-1.2.6.17_1.2157_FC5 > Dependency Installed: foo-kmod-common.noarch 0:1.1-1 > Complete! > [thl at notebook ~]$ Copy the second one in the repo and update: > [thl at notebook ~]$ cp rpmbuild/RPMS/i686/kmod-foo-1.1-1.2.6.17_1.2174_FC5.i686.rpm ~/tmp/testrepo/ > [thl at notebook ~]$ createrepo ~/tmp/testrepo/ > 3/3 - kmod-foo-1.1-1.2.6.17_1.2174_FC5.i686.rpm > Saving Primary metadata > Saving file lists metadata > Saving other metadata > [thl at notebook ~]$ sudo rm -rf /var/cache/yum/testrepo/ > [thl at notebook ~]$ sudo yum --enablerepo=testrepo update > Loading "installonlyn" plugin > Setting up Update Process > Setting up repositories > macromedia [1/7] > livna [2/7] > testrepo [3/7] > testrepo 100% |=========================| 951 B 00:00 > updates-testing [4/7] > core [5/7] > updates [6/7] > extras [7/7] > Reading repository metadata in from local files > primary.xml.gz 100% |=========================| 1.0 kB 00:00 > testrepo : ################################################## 3/3 > Added 3 new packages, deleted 0 old in 0.05 seconds > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for kmod-foo to pack into transaction set. > kmod-foo-1.1-1.2.6.17_1.2 100% |=========================| 2.4 kB 00:00 > ---> Package kmod-foo.i686 0:1.1-1.2.6.17_1.2174_FC5 set to be installed > --> Running transaction check > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > kmod-foo i686 1.1-1.2.6.17_1.2174_FC5 testrepo 504 k > > Transaction Summary > ============================================================================= > Install 1 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > Total download size: 504 k > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Installing: kmod-foo ######################### [1/1] > WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object > > Installed: kmod-foo.i686 0:1.1-1.2.6.17_1.2174_FC5 > Complete! > [thl at notebook ~]$ Works as expected so far. But now: > [thl at notebook ~]$ cp rpmbuild/RPMS/i686/kmod-foo-1.1-2.2.6.17_1.2174_FC5.i686.rpm tmp/testrepo/ > [thl at notebook ~]$ sudo rm -rf /var/cache/yum/testrepo/ > [thl at notebook ~]$ createrepo ~/tmp/testrepo/ > 4/4 - kmod-foo-1.1-2.2.6.17_1.2174_FC5.i686.rpm > Saving Primary metadata > Saving file lists metadata > Saving other metadata > [thl at notebook ~]$ sudo yum --enablerepo=testrepo update > Loading "installonlyn" plugin > Setting up Update Process > Setting up repositories > macromedia [1/7] > livna [2/7] > testrepo [3/7] > testrepo 100% |=========================| 951 B 00:00 > updates-testing [4/7] > core [5/7] > updates [6/7] > extras [7/7] > Reading repository metadata in from local files > primary.xml.gz 100% |=========================| 1.1 kB 00:00 > testrepo : ################################################## 4/4 > Added 4 new packages, deleted 0 old in 0.10 seconds > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for kmod-foo to pack into transaction set. > kmod-foo-1.1-2.2.6.17_1.2 100% |=========================| 2.4 kB 00:00 > ---> Package kmod-foo.i686 0:1.1-2.2.6.17_1.2174_FC5 set to be installed > --> Running transaction check > --> Populating transaction set with selected packages. Please wait. > ---> Package kmod-foo.i686 0:1.1-1.2.6.17_1.2157_FC5 set to be erased > --> Running transaction check > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > kmod-foo i686 1.1-2.2.6.17_1.2174_FC5 testrepo 504 k > Removing: > kmod-foo i686 1.1-1.2.6.17_1.2157_FC5 installed 500 k > > Transaction Summary > ============================================================================= > Install 1 Package(s) > Update 0 Package(s) > Remove 1 Package(s) > Total download size: 504 k > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Removing : kmod-foo ######################### [1/2] > Installing: kmod-foo ######################### [2/2] > WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object > > Removed: kmod-foo.i686 0:1.1-1.2.6.17_1.2157_FC5 > Installed: kmod-foo.i686 0:1.1-2.2.6.17_1.2174_FC5 > Complete! > [thl at notebook ~]$ Okay, why did that work? I don't know for real. Let's check some details: > [thl at notebook ~]$ rpm -qa kmod-foo > kmod-foo-1.1-2.2.6.17_1.2174_FC5 > kmod-foo-1.1-1.2.6.17_1.2174_FC5 > [thl at notebook ~]$ rpm -V kmod-foo-1.1-1.2.6.17_1.2174_FC5 > ..5....T /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > [thl at notebook ~]$ rpm -V kmod-foo-1.1-2.2.6.17_1.2174_FC5 > [thl at notebook ~]$ Well, I'd call that "interesting". Seem the "file-conflicts on updates problem" doesn't exist. But while testing it I noticed something else. You probably noticed that in above transaction kmod-foo.i686 0:1.1-1.2.6.17_1.2157_FC5 got removed -- it seems that's not a rpm/yum feature. It's the installonly-plugin that does this. Let's get back to the state we were before: > [thl at notebook ~]$ sudo rpm -ivh /home/thl/tmp/testrepo/kmod-foo-1.1-1.2.6.17_1.2157_FC5.i686.rpm --oldpackage > Preparing... ########################################### [100%] > 1:kmod-foo ########################################### [100%] > WARNING: Module /lib/modules/2.6.17-1.2157_FC5/extra/foo/foo.ko is not an elf object > [thl at notebook ~]$ sudo rpm -e kmod-foo-1.1-1.2.6.17_1.2174_FC5 kmod-foo-1.1-2.2.6.17_1.2174_FC5 > [thl at notebook ~]$ sudo rpm -ivh /home/thl/tmp/testrepo/kmod-foo-1.1-1.2.6.17_1.2174_FC5.i686.rpm > Preparing... ########################################### [100%] > 1:kmod-foo ########################################### [100%] > WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object > [thl at notebook ~]$ Now disable the plugin: > [thl at notebook ~]$ sudo yum --noplugins --enablerepo=testrepo update > Setting up Update Process > Setting up repositories > macromedia [1/7] > livna [2/7] > testrepo [3/7] > updates-testing [4/7] > core [5/7] > updates [6/7] > extras [7/7] > Reading repository metadata in from local files > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for kmod-foo to pack into transaction set. > kmod-foo-1.1-2.2.6.17_1.2 100% |=========================| 2.4 kB 00:00 > ---> Package kmod-foo.i686 0:1.1-2.2.6.17_1.2174_FC5 set to be installed > --> Running transaction check > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > kmod-foo i686 1.1-2.2.6.17_1.2174_FC5 testrepo 504 k > > Transaction Summary > ============================================================================= > Install 1 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > Total download size: 504 k > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Installing: kmod-foo ######################### [1/1] > WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object > > Installed: kmod-foo.i686 0:1.1-2.2.6.17_1.2174_FC5 > Complete! > [thl at notebook ~]$ Disabling the installonly-plungin in /etc/yum/pluginconf.d/installonlyn.conf has the same effect. So the "old modules get removed on updates" problem in reality is a bug AFAICS. Or I'm probably doing something really wrong here -- but what? CU thl From Axel.Thimm at ATrpms.net Sat Aug 19 00:34:47 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 19 Aug 2006 02:34:47 +0200 Subject: [Fedora-packaging] Re: rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <1155947065.24935.0.camel@cutter> References: <20060819001925.GA21216@neu.nirvana> <1155947065.24935.0.camel@cutter> Message-ID: <20060819003447.GC21216@neu.nirvana> On Fri, Aug 18, 2006 at 08:24:25PM -0400, seth vidal wrote: > On Sat, 2006-08-19 at 02:19 +0200, Axel Thimm wrote: > > o rpm -i behaves properly with file conflicts > > o yum may for some reason turn of file conflict checking > > There is no code in yum that disables file conflict checking. I wouldn't think so myself, but Thorsten's report seems to indicate this. Is there some other explanation why people don't see file conflicts under yum? Note that according to Thorsten's report this is w/o any special kmod/kmdls or other plugins (or only installn, but that shouldn't matter). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Sat Aug 19 01:00:34 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Aug 2006 21:00:34 -0400 Subject: [Fedora-packaging] Re: rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <20060819003447.GC21216@neu.nirvana> References: <20060819001925.GA21216@neu.nirvana> <1155947065.24935.0.camel@cutter> <20060819003447.GC21216@neu.nirvana> Message-ID: <20060819010034.GA5543@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > On Fri, Aug 18, 2006 at 08:24:25PM -0400, seth vidal wrote: > > On Sat, 2006-08-19 at 02:19 +0200, Axel Thimm wrote: > > > o rpm -i behaves properly with file conflicts > > > o yum may for some reason turn of file conflict checking > > > > There is no code in yum that disables file conflict checking. > > I wouldn't think so myself, but Thorsten's report seems to indicate > this. > > Is there some other explanation why people don't see file conflicts > under yum? rpm does not properly detect multilib conflicts when packages are installed in the same transaction. This is a RPM bug, and has nothing to do with yum. Bug 190209, if you're curious. Bill From notting at redhat.com Sat Aug 19 01:03:20 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Aug 2006 21:03:20 -0400 Subject: [Fedora-packaging] Re: rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <20060819010034.GA5543@nostromo.devel.redhat.com> References: <20060819001925.GA21216@neu.nirvana> <1155947065.24935.0.camel@cutter> <20060819003447.GC21216@neu.nirvana> <20060819010034.GA5543@nostromo.devel.redhat.com> Message-ID: <20060819010320.GB5543@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Bug 190209, if you're curious. And 132687 before that... Bill From Axel.Thimm at ATrpms.net Sat Aug 19 06:45:00 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 19 Aug 2006 08:45:00 +0200 Subject: [Fedora-packaging] Re: rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <20060819010034.GA5543@nostromo.devel.redhat.com> References: <20060819001925.GA21216@neu.nirvana> <1155947065.24935.0.camel@cutter> <20060819003447.GC21216@neu.nirvana> <20060819010034.GA5543@nostromo.devel.redhat.com> Message-ID: <20060819064500.GA28595@neu.nirvana> On Fri, Aug 18, 2006 at 09:00:34PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > On Fri, Aug 18, 2006 at 08:24:25PM -0400, seth vidal wrote: > > > On Sat, 2006-08-19 at 02:19 +0200, Axel Thimm wrote: > > > > o rpm -i behaves properly with file conflicts > > > > o yum may for some reason turn of file conflict checking > > > > > > There is no code in yum that disables file conflict checking. > > > > I wouldn't think so myself, but Thorsten's report seems to indicate > > this. > > > > Is there some other explanation why people don't see file conflicts > > under yum? > > rpm does not properly detect multilib conflicts when packages are > installed in the same transaction. This is a RPM bug, and has > nothing to do with yum. > > Bug 190209, if you're curious. But the report by Thorsten did not involve any multilib situation. In fact it looked like he used FC5/i386 to test it, check https://www.redhat.com/archives/fedora-packaging/2006-August/msg00250.html He includes a repeatable setup where yum installs an i686 package overwriting another i686 package. I didn't verify the yum setup (but I trust Thorsten to have done the right thing), I just checked with rpm -i alone and that worked as expected, e.g. file conflicts were detected and the install aborted. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Aug 19 06:47:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 19 Aug 2006 08:47:26 +0200 Subject: [Fedora-packaging] Complaints about censoring and kmdl IRC session (resend) Message-ID: <20060819064726.GB28595@neu.nirvana> Hi, IMHO the IRC session today was a pure catastrophe. Some - especially people not following the discussion closely - were given the wrong picture and even accused me of being arrogant and what not. I'd like to file in my view, since the IRC session turned that badly. Upon request I compiled a tabular list of pros and cons of kmods vs kmdls derived from the longer writeup in the wiki. I've added all points mentioned even the ones I personally do not pay that much importance on and more importantly also these points that my proposal isn't good at including negative personal ratings for kmdls! I considered this a necessity out of fairness to everyone's contributions. W/o notice someone changed that list in a way I consider heavily censoring and very biased. I complained to him in PM, but his spam filter ate my mail and I didn't get a reply before the session (or by now either FWIW). In any case at the end of this mail I summarize the main changes [3]. Of course that new list wasn't really what I would consider a neutral, unbiased approach. There were many errors either accidentially or due to different understanding [1] which by happenstance *all* were turning against kmdls, even typos and cut&paste errors. Also important items were scratched (not the rating, but features and comparisons). Later in the session it was told that the omitted items were dumped because they were considered irrelevant, something which IMHO the people in the session should be allowed to judge for themselves. When the first difference was brought on discussion - namely that rpm -i supposedly works with kmod - I objected and gave examples why this is not the case. Independent of whether I were right or wrong [2], the following "definition of rpm -i works for kmods" was topping the censoring by itself. I can understand that people are not as deep into kernel modules as others, and that therefore some issues may look different. But shouldn't these people be open to discussion in case they are missing something (which in this case they are)? Or is this just a fake discussion where the end result is already in stone and we're just trying to justify it? ATM I really disappointed as to how things evolve. I've put lots of efforts and sweat over the last weeks into this with the target to fix something broken for the benefits of all and I don't consider this the proper reaction. Please note that I'm very far from escalating this. I wrote this mail with very careful wording, omitting on purpose all names and refraining from any direct accusations, even though I'm extremely alergic to censoring and misquoting in general. And I didn't reply on personal insults either to avoid any flaming. To get to the positive side: At least it was discussed at all (or an attempt was made) and I'd like to thank all for their participation and patience. ===================================================================== [1] I use "different" as a very neutral wording of what I personally consider "wrong". [2] IMHO I was and am correct in the statement that the kmod scheme can neither be used with rpm -U, nor rpm -i. [3] Changes between original and censored list of items http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance?action=diff&rev2=8&rev1=4 By order of importance: o rpm & kmods: "breaks on rpm level" removed "rpm -i does not work" suddenly "works" ??? o kmod's need for further yum developend removed!!! o yum w/ full plugin support kmod's "only one kernel supportable [...]" becomes "possible" ??? kmdl's "full suport" becomes "possible" ??? The difference is a working kmdl plugin today vs the shown issues of the fedorakmod.py, which were even admited by pro-kmod participants. o kmods: kernel's evr "merged with the modules" becomes "available as provides" It is very important that the 2-dimensional evr space is mapped that way, it is in fact the root of most evil. Replacing it as done hides the issue. o kmdls and low maintenance: "specfile/src.rpm/userland invariant" becomes "every new kernel/flavour needs full rebuild" o kmdl's design flexibility/abstraction of interface/implementation removed o infrastructure (bugzilla/cvs/owners) benefits removed o custom kernel support removed o other distribution benefits of kmdls removed o cross-distribution standard benefits of kmdls removed o Removed column rating (that by itself I would consider OK) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: irc.log.gz Type: application/x-gzip Size: 19034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sat Aug 19 11:39:25 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 19 Aug 2006 13:39:25 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <20060818201652.GA18162@neu.nirvana> References: <44E365F6.9020604@leemhuis.info> <20060816201144.GC27375@neu.nirvana> <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> <44E59C4E.3040205@leemhuis.info> <20060818111138.GD27801@neu.nirvana> <44E5A4BE.8050506@leemhuis.info> <20060818125518.GH27801@neu.nirvana> <44E5BA7C.7040007@leemhuis.info> <20060818201652.GA18162@neu.nirvana> Message-ID: <44E6F86D.10103@leemhuis.info> Axel Thimm schrieb: > On Fri, Aug 18, 2006 at 03:02:52PM +0200, Thorsten Leemhuis wrote: >> Just use the same scheme that a new flavor in the main package would use. > That would be for new flavours, not new kernels that share the same > set of flavours like the unpatched kernel. Sorry, I fail to follow you. Why can the flavor be something like "swsusp2", "swsusp2-smp", "swsusp2-xen", ...? CU thl From fedora at leemhuis.info Sat Aug 19 12:06:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 19 Aug 2006 14:06:05 +0200 Subject: [Fedora-packaging] Re: rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <20060819064500.GA28595@neu.nirvana> References: <20060819001925.GA21216@neu.nirvana> <1155947065.24935.0.camel@cutter> <20060819003447.GC21216@neu.nirvana> <20060819010034.GA5543@nostromo.devel.redhat.com> <20060819064500.GA28595@neu.nirvana> Message-ID: <44E6FEAD.5020709@leemhuis.info> Axel Thimm schrieb: > On Fri, Aug 18, 2006 at 09:00:34PM -0400, Bill Nottingham wrote: >> Axel Thimm (Axel.Thimm at ATrpms.net) said: >>> On Fri, Aug 18, 2006 at 08:24:25PM -0400, seth vidal wrote: >>>> On Sat, 2006-08-19 at 02:19 +0200, Axel Thimm wrote: >>>>> o rpm -i behaves properly with file conflicts >>>>> o yum may for some reason turn of file conflict checking >>>> There is no code in yum that disables file conflict checking. >>> I wouldn't think so myself, but Thorsten's report seems to indicate >>> this. >>> Is there some other explanation why people don't see file conflicts >>> under yum? >> rpm does not properly detect multilib conflicts when packages are >> installed in the same transaction. This is a RPM bug, and has >> nothing to do with yum. >> Bug 190209, if you're curious. > But the report by Thorsten [side note -- I didn't post the report to the list myself -- I noticed the things in the report on the yesterday and compiled the report shortly before the meeting and send it only to Spot and Axel in private; I wanted to extend it slightly (see below) and reread it once more before posting it to the list] > did not involve any multilib situation. In > fact it looked like he used FC5/i386 to test it, check Yes, I tested it for the report on a i386 machine; but I checked it before on a x86_64 machine where it worked in the same way. > https://www.redhat.com/archives/fedora-packaging/2006-August/msg00250.html > > He includes a repeatable setup where yum installs an i686 package > overwriting another i686 package. I didn't verify the yum setup (but I > trust Thorsten to have done the right thing), Well, I'd be glad if someone could reproduce it and check if I did everything correctly. Computers are stupid sometimes, but in this case I might have done something wrong. Albeit: I more and more tend to think I did it correctly because we (lvn, lvn users, jcmasters in his kABI testing,) would have hit the "file conflicts on updates" problem often and people would have yelled. And I go not a single report in livna's bugzilla mention file-conflicts since we use the kmod scheme. > I just checked with rpm > -i alone and that worked as expected, e.g. file conflicts were > detected and the install aborted. That's exactly the part that missing in the report -- that works here, too. See: > [thl at notebook ~]$ rpm -qa kmod-foo foo-kmod-common > foo-kmod-common-1.1-1 > kmod-foo-1.1-1.2.6.17_1.2157_FC5 > [thl at notebook ~]$ sudo rpm -ivh /home/thl/tmp/testrepo/kmod-foo-1.1-1.2.6.17_1.2174_FC5.i686.rpm > Vorbereiten... ########################################### [100%] > 1:kmod-foo ########################################### [100%] > WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object > [thl at notebook ~]$ sha1sum /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > b9bfed7890b1126a8469291a1a0c19f2c61cdf35 /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > [thl at notebook ~]$ sudo rpm -ivh /home/thl/tmp/testrepo/kmod-foo-1.1-2.2.6.17_1.2174_FC5.i686.rpm > Vorbereiten... ########################################### [100%] > 1:kmod-foo ########################################### [100%] > WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object > [thl at notebook ~]$ sha1sum /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > f8afd194e3058c40092396d7186d43c239920075 /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > [thl at notebook ~]$ rpm -V kmod-foo-1.1-1.2.6.17_1.2174_FC5 > ..5....T /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > [thl at notebook ~]$ rpm -V kmod-foo-1.1-2.2.6.17_1.2174_FC5 > [thl at notebook ~]$ Albeit the rpm output does look a bit confusing: > [thl at notebook ~]$ rpm -qa kmod-foo foo-kmod-common > foo-kmod-common-1.1-1 > kmod-foo-1.1-1.2.6.17_1.2174_FC5 > kmod-foo-1.1-1.2.6.17_1.2157_FC5 > kmod-foo-1.1-2.2.6.17_1.2174_FC5 > [thl at notebook ~]$ But that will be clean up sooner or later when the matching kernel is automatically removed together with the modules. Am I doing something terribly wrong during testing here? Why does it fail for Axel, but not for me? CU thl From Axel.Thimm at ATrpms.net Sat Aug 19 13:55:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 19 Aug 2006 15:55:08 +0200 Subject: [Fedora-packaging] Re: kmdls: very good support for custom kernels (was: kernel-module packaging discussing ...) In-Reply-To: <44E6F86D.10103@leemhuis.info> References: <20060817113614.GE5485@neu.nirvana> <1155895917.2784.16.camel@localhost.localdomain> <20060818103447.GB27801@neu.nirvana> <44E59C4E.3040205@leemhuis.info> <20060818111138.GD27801@neu.nirvana> <44E5A4BE.8050506@leemhuis.info> <20060818125518.GH27801@neu.nirvana> <44E5BA7C.7040007@leemhuis.info> <20060818201652.GA18162@neu.nirvana> <44E6F86D.10103@leemhuis.info> Message-ID: <20060819135508.GD30787@neu.nirvana> On Sat, Aug 19, 2006 at 01:39:25PM +0200, Thorsten Leemhuis wrote: > > > Axel Thimm schrieb: > > On Fri, Aug 18, 2006 at 03:02:52PM +0200, Thorsten Leemhuis wrote: > >> Just use the same scheme that a new flavor in the main package would use. > > That would be for new flavours, not new kernels that share the same > > set of flavours like the unpatched kernel. > > Sorry, I fail to follow you. Why can the flavor be something like > "swsusp2", "swsusp2-smp", "swsusp2-xen", ...? Why should it? The flavour is simply the choice of a config file (not 100% true, but let's keep it simple), that's why it is called a flavour after all. Overloading it with further information is wrong, especially when the sole purpose is only to support the kmod hack. Any custom kernel package out there is either not changing the name or is suffixing the main name with suspend2/desktop etc. Noone wants to start hacking new flavours. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Aug 19 14:06:32 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 19 Aug 2006 16:06:32 +0200 Subject: [Fedora-packaging] Re: rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <44E6FEAD.5020709@leemhuis.info> References: <20060819001925.GA21216@neu.nirvana> <1155947065.24935.0.camel@cutter> <20060819003447.GC21216@neu.nirvana> <20060819010034.GA5543@nostromo.devel.redhat.com> <20060819064500.GA28595@neu.nirvana> <44E6FEAD.5020709@leemhuis.info> Message-ID: <20060819140632.GE30787@neu.nirvana> On Sat, Aug 19, 2006 at 02:06:05PM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Fri, Aug 18, 2006 at 09:00:34PM -0400, Bill Nottingham wrote: > >> Axel Thimm (Axel.Thimm at ATrpms.net) said: > >>> On Fri, Aug 18, 2006 at 08:24:25PM -0400, seth vidal wrote: > >>>> On Sat, 2006-08-19 at 02:19 +0200, Axel Thimm wrote: > >>>>> o rpm -i behaves properly with file conflicts > >>>>> o yum may for some reason turn of file conflict checking > >>>> There is no code in yum that disables file conflict checking. > >>> I wouldn't think so myself, but Thorsten's report seems to indicate > >>> this. > >>> Is there some other explanation why people don't see file conflicts > >>> under yum? > Albeit: I more and more tend to think I did it correctly because we > (lvn, lvn users, jcmasters in his kABI testing,) would have hit the > "file conflicts on updates" problem often and people would have yelled. > And I go not a single report in livna's bugzilla mention file-conflicts > since we use the kmod scheme. Wow, that means that if it indeed does not yell, that people w/o fedorakmod.py are happily overwriting their previous kernel modules? For example with the change of the name of the openafs ko module, the users had two modules simultaneously installed praying for the userland to modprobe the correct name ... Coinstallation of kernel modules of different module evr for the same kernel is a bug as explained before. File conflicts are guardians, and w/o you (partly) overwrite your old module. > > I just checked with rpm -i alone and that worked as expected, > > e.g. file conflicts were detected and the install aborted. > > That's exactly the part that missing in the report -- that works here, > too. See: > > > [thl at notebook ~]$ rpm -qa kmod-foo foo-kmod-common > > foo-kmod-common-1.1-1 > > kmod-foo-1.1-1.2.6.17_1.2157_FC5 > > [thl at notebook ~]$ sudo rpm -ivh /home/thl/tmp/testrepo/kmod-foo-1.1-1.2.6.17_1.2174_FC5.i686.rpm > > Vorbereiten... ########################################### [100%] > > 1:kmod-foo ########################################### [100%] > > WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object > > [thl at notebook ~]$ sha1sum /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > > b9bfed7890b1126a8469291a1a0c19f2c61cdf35 /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > > [thl at notebook ~]$ sudo rpm -ivh /home/thl/tmp/testrepo/kmod-foo-1.1-2.2.6.17_1.2174_FC5.i686.rpm > > Vorbereiten... ########################################### [100%] > > 1:kmod-foo ########################################### [100%] > > WARNING: Module /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko is not an elf object > > [thl at notebook ~]$ sha1sum /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > > f8afd194e3058c40092396d7186d43c239920075 /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > > [thl at notebook ~]$ rpm -V kmod-foo-1.1-1.2.6.17_1.2174_FC5 > > ..5....T /lib/modules/2.6.17-1.2174_FC5/extra/foo/foo.ko > > [thl at notebook ~]$ rpm -V kmod-foo-1.1-2.2.6.17_1.2174_FC5 > > [thl at notebook ~]$ > Am I doing something terribly wrong during testing here? Why does it > fail for Axel, but not for me? I would start with simpler examples like the two minimal specfiles I posted. If you still don't get file conflicts something is really off here (I have a vanilla FC5/i386, e.g. rpm-4.4.2-15.2), maybe you're tuning rpm over global macros?. If you do get file conflicts then it's part of the kmod specfile - start adding parts that you suspect may confuse rpm enough to not report the conflict, so you know what part of the specfile did it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjneely at ncsu.edu Sat Aug 19 22:25:30 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Sat, 19 Aug 2006 18:25:30 -0400 Subject: [Fedora-packaging] rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <20060819001925.GA21216@neu.nirvana> References: <20060819001925.GA21216@neu.nirvana> Message-ID: <20060819222530.GX26953@anduril.unity.ncsu.edu> Axel, There's a fundamental misunderstanding here about using rpm -i. You claim that it does not function for kmods. Most of us consider your examples for this an upgrade path rather than an install path. We consider rpm -i only useful for the install path where there are no other kernel modules of that name installed on the system. So, when no previous versions of a specific kernel module are installed and we use rpm -i to install one, there are no file conflicts. The package is installed correctly. Other cases are considered upgrade paths and we agree that rpm -U does not give the desired behavior. rpm -i should not be used for an upgrade path as it does not work for any package at all. Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From rdieter at math.unl.edu Sat Aug 19 23:27:57 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 19 Aug 2006 18:27:57 -0500 Subject: [Fedora-packaging] rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <20060819222530.GX26953@anduril.unity.ncsu.edu> References: <20060819001925.GA21216@neu.nirvana> <20060819222530.GX26953@anduril.unity.ncsu.edu> Message-ID: <44E79E7D.7020508@math.unl.edu> Jack Neely wrote: > Axel, > > There's a fundamental misunderstanding here about using rpm -i. You > claim that it does not function for kmods. Most of us consider your > examples for this an upgrade path rather than an install path. ... > Other cases are considered upgrade paths and we agree that rpm -U does > not give the desired behavior. rpm -i should not be used for an upgrade > path as it does not work for any package at all. IMO, seems to be an argument for using the uname-r mechanism, so no such problems, misunderstandings occur. -- Rex From Axel.Thimm at ATrpms.net Sat Aug 19 23:15:00 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 20 Aug 2006 01:15:00 +0200 Subject: [Fedora-packaging] Re: rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <20060819222530.GX26953@anduril.unity.ncsu.edu> References: <20060819001925.GA21216@neu.nirvana> <20060819222530.GX26953@anduril.unity.ncsu.edu> Message-ID: <20060819231500.GA4291@neu.nirvana> On Sat, Aug 19, 2006 at 06:25:30PM -0400, Jack Neely wrote: > There's a fundamental misunderstanding here about using rpm -i. You > claim that it does not function for kmods. Most of us consider your > examples for this an upgrade path rather than an install path. The key point is that neither -U, nor -i, nor any other rpm cli transaction can support kmods. Restricting the starting environment does not count. In this case firefox and any other conventional package can also be installed with -i. So whether you want to give "rpm -i" a name or not, doesn't matter. I call it neither upgarde, nor (co)install, I just make the technical and correct observation that "rpm -i" does not work - as "rpm -U" does not work. And since both do not work rpm cli operation with kmods is impossible which is the final aspect here. Please note that restricting the starting environment (e.g. kmod free setup) does really not count as an argument that rpm -i/-U works. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From i.pilcher at comcast.net Sun Aug 20 02:21:11 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Sat, 19 Aug 2006 21:21:11 -0500 Subject: [Fedora-packaging] Re: rpm -i, "missing" file conflicts and brokenness with kmods In-Reply-To: <20060819222530.GX26953@anduril.unity.ncsu.edu> References: <20060819001925.GA21216@neu.nirvana> <20060819222530.GX26953@anduril.unity.ncsu.edu> Message-ID: Jack Neely wrote: > We consider rpm -i only useful for the install path where there are no > other kernel modules of that name installed on the system. So, when no > previous versions of a specific kernel module are installed and we use > rpm -i to install one, there are no file conflicts. The package is > installed correctly. That may be the typical usage, but there's nothing about RPM that mandates this. Different versions of the same package can happily coexist as long as their files don't conflict. For an example of this, look no further than the practice of keeping older kernels around. In this case, the "upgrade" is performed with rpm -i (or its API equivalent); if rpm -U were used, the old kernel would be automatically removed. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From yaneti at declera.com Sun Aug 20 06:45:04 2006 From: yaneti at declera.com (Yanko Kaneti) Date: Sun, 20 Aug 2006 09:45:04 +0300 Subject: [Fedora-packaging] GConf snippets suggestion Message-ID: <1156056304.8893.10.camel@indigo.declera.com> Hi, Since the wiki doesn't allow useful collaboration on immutable pages, here is my suggestion for the gconf schema installation snippet in the form of a patch. It tries to emphasize the proper (IMHO) --disable-schemas-install method of disabling schemas installation on the build host vs the prevalent GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL hack (again IMHO) Regards Yanko --- ScriptletSnippets 2006-08-20 09:04:41.000000000 +0300 +++ ScriptletSnippets.gconf 2006-08-20 09:29:51.000000000 +0300 @@ -148,6 +148,12 @@ Here's the first part: {{{ +%build +%configure --disable-schemas-install +... +}}} +In the cases where the package doesn't use autotools or doesnt support the --disable-schemas-install configure flag we instuct gconftool to ignore schema installation commands by setting the GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL environment variable +{{{ %install rm -rf $RPM_BUILD_ROOT export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 From ville.skytta at iki.fi Sun Aug 20 08:18:57 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 20 Aug 2006 11:18:57 +0300 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <1155927752.2982.5.camel@localhost> References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <1155927752.2982.5.camel@localhost> Message-ID: <1156061937.2508.0.camel@localhost.localdomain> On Fri, 2006-08-18 at 12:02 -0700, Toshio Kuratomi wrote: > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > that can work with Makefiles that don't make use of the DESTDIR variable > but it has the following potential issues:" +1 From Fedora at FamilleCollet.com Sun Aug 20 12:54:06 2006 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sun, 20 Aug 2006 14:54:06 +0200 Subject: [Fedora-packaging] Guidelines for packaging PHP Message-ID: <44E85B6E.1010503@FamilleCollet.com> Hello, I'm back from a few holidays weeks I saw that this Guidelines is no more in draft state, but i don't see anything about the approvement on the list. Can you tell me if it is ok to push the RPM witch are ready on the CVS and to run the build ? Remi. From toshio at tiki-lounge.com Sun Aug 20 17:19:55 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 20 Aug 2006 10:19:55 -0700 Subject: [Fedora-packaging] GConf snippets suggestion In-Reply-To: <1156056304.8893.10.camel@indigo.declera.com> References: <1156056304.8893.10.camel@indigo.declera.com> Message-ID: <1156094396.2786.8.camel@localhost> On Sun, 2006-08-20 at 09:45 +0300, Yanko Kaneti wrote: > Hi, > > Since the wiki doesn't allow useful collaboration on immutable pages, > here is my suggestion for the gconf schema installation snippet in the > form of a patch. > PackagingDrafts/ScriptletSnippets is useful for this. Changes can then be voted on and merged to the official, immutable pages. > It tries to emphasize the proper (IMHO) --disable-schemas-install method > of disabling schemas installation on the build host vs the prevalent > GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL hack (again IMHO) > Could you explain why the configure script option should be considered canonical and the environment variable a hack? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From yaneti at declera.com Sun Aug 20 19:21:52 2006 From: yaneti at declera.com (Yanko Kaneti) Date: Sun, 20 Aug 2006 22:21:52 +0300 Subject: [Fedora-packaging] GConf snippets suggestion In-Reply-To: <1156094396.2786.8.camel@localhost> References: <1156056304.8893.10.camel@indigo.declera.com> <1156094396.2786.8.camel@localhost> Message-ID: <1156101712.8893.32.camel@indigo.declera.com> On Sun, 2006-08-20 at 10:19 -0700, Toshio Kuratomi wrote: > On Sun, 2006-08-20 at 09:45 +0300, Yanko Kaneti wrote: > > It tries to emphasize the proper (IMHO) --disable-schemas-install method > > of disabling schemas installation on the build host vs the prevalent > > GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL hack (again IMHO) > > > Could you explain why the configure script option should be considered > canonical and the environment variable a hack? Its should be canonical because its part of the AM_GCONF_SOURCE_2 autoconf macro which in turn is used by perhaps 99% of all gconf-using packages out there. Now, some use the macro but don't honor the automake conditional that --disable-schemas-install sets. This IMO should be considered an upstream bug. As to why using an overly wordy environment variable to negate a specifically invoked action of a tool should be considered a hack? I'll leave that to your good taste. I personally consider the existence of this mechanism a GConf birth defect that's been carried for too long. On a side-note If there was a more global auto* foo for flagging a staged build/install perhaps we wouldn't need package specific magic like that at all. Yanko From tibbs at math.uh.edu Mon Aug 21 14:45:37 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 21 Aug 2006 09:45:37 -0500 Subject: [Fedora-packaging] Guidelines for packaging PHP In-Reply-To: <44E85B6E.1010503@FamilleCollet.com> (Remi Collet's message of "Sun, 20 Aug 2006 14:54:06 +0200") References: <44E85B6E.1010503@FamilleCollet.com> Message-ID: >>>>> "RC" == Remi Collet writes: RC> I saw that this Guidelines is no more in draft state, but i don't RC> see anything about the approvement on the list. It was voted upon in one of our regular meetings and is thus mentioned in the meeting minutes. The appropriate changes were also made in the wiki. RC> Can you tell me if it is ok to push the RPM witch are ready on the RC> CVS and to run the build ? Assuming that they meet the guidelines, which would entail a review. I'm not sure that any review made before the guidelines were finished really counts as a review. Also note that the updated php-pear pear package which contains the updated macros mentioned in the guidelines still has not been released as an update for FC5, so currently you can only target FC6. On my TODO list is the addition of some information on targeting FC5 and older releases. - J< From rdieter at math.unl.edu Mon Aug 21 14:53:21 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 21 Aug 2006 09:53:21 -0500 Subject: [Fedora-packaging] Importance of debuginfo packages In-Reply-To: References: Message-ID: <44E9C8E1.1070501@math.unl.edu> Jason L Tibbitts III wrote: > So, how important is it to have a proper > debuginfo package? How much hacking is permissible or necessary in > order to achieve that goal? I think these are questions best answered by the maintainer/reviewer (and possibly upstream). The easy answers are: tiny hacks -> do it many hacks/patches -> probably not worth it It's defining the line between the two that's tricky. > Is an incomplete debuginfo package (that > contains, say, the striped debug information but is missing some or > all of the source code) still useful, or would it be better to have > none at all? Something is certainly better than nothing. -- Rex From tibbs at math.uh.edu Mon Aug 21 16:26:00 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 21 Aug 2006 11:26:00 -0500 Subject: [Fedora-packaging] Importance of debuginfo packages In-Reply-To: <44E9C8E1.1070501@math.unl.edu> (Rex Dieter's message of "Mon, 21 Aug 2006 09:53:21 -0500") References: <44E9C8E1.1070501@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> Something is certainly better than nothing. Is it really? I don't know how to use debuginfo packages, so I don't know if there's any point to having them if they're not complete. Obviously we know that a debuginfo package with no files should be disabled, so what needs to be there before there's any point to enabling it? - J< From jkeating at redhat.com Mon Aug 21 16:48:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Aug 2006 12:48:05 -0400 Subject: [Fedora-packaging] Importance of debuginfo packages In-Reply-To: References: <44E9C8E1.1070501@math.unl.edu> Message-ID: <200608211248.08625.jkeating@redhat.com> On Monday 21 August 2006 12:26, Jason L Tibbitts III wrote: > Is it really? ?I don't know how to use debuginfo packages, so I don't > know if there's any point to having them if they're not complete. > > Obviously we know that a debuginfo package with no files should be > disabled, so what needs to be there before there's any point to > enabling it? Enough so that running gdb (gnu debugger) on the application will produce a meaningful traceback. This helps a lot in figuring out where / why an application is crashing. Without a debuginfo package you cannot get this information without recompiling the package and leaving the binaries unstripped. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Mon Aug 21 16:54:22 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 21 Aug 2006 11:54:22 -0500 Subject: [Fedora-packaging] Importance of debuginfo packages In-Reply-To: <200608211248.08625.jkeating@redhat.com> (Jesse Keating's message of "Mon, 21 Aug 2006 12:48:05 -0400") References: <44E9C8E1.1070501@math.unl.edu> <200608211248.08625.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Enough so that running gdb (gnu debugger) on the application will JK> produce a meaningful traceback. So what needs to be there in order for that to work? I need to be able to superficially inspect a debuginfo package and know whether it has enough stuff in it or not. - J< From Axel.Thimm at ATrpms.net Mon Aug 21 17:16:55 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 21 Aug 2006 19:16:55 +0200 Subject: [Fedora-packaging] Re: Importance of debuginfo packages In-Reply-To: References: <44E9C8E1.1070501@math.unl.edu> <200608211248.08625.jkeating@redhat.com> Message-ID: <20060821171655.GD25253@neu.nirvana> On Mon, Aug 21, 2006 at 11:54:22AM -0500, Jason L Tibbitts III wrote: > >>>>> "JK" == Jesse Keating writes: > > JK> Enough so that running gdb (gnu debugger) on the application will > JK> produce a meaningful traceback. > > So what needs to be there in order for that to work? > > I need to be able to superficially inspect a debuginfo package and > know whether it has enough stuff in it or not. That's very difficult, especially in projects with subdirectories that may redefine CFLAGS/CXXFLAGS w/o the builder noticing. sope/ogo is one nasty candidate for example. There are some safety pins in debuginfo, IIRC if it's turned on, but the debuginfo turns out empty the build will fail. That's how it gets my attention to fix debugging symbols at least :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Mon Aug 21 17:18:46 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 21 Aug 2006 10:18:46 -0700 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <1156061937.2508.0.camel@localhost.localdomain> References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <1155927752.2982.5.camel@localhost> <1156061937.2508.0.camel@localhost.localdomain> Message-ID: <1156180726.3129.1.camel@localhost> On Sun, 2006-08-20 at 11:18 +0300, Ville Skytt? wrote: > On Fri, 2006-08-18 at 12:02 -0700, Toshio Kuratomi wrote: > > > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > > that can work with Makefiles that don't make use of the DESTDIR variable > > but it has the following potential issues:" > > +1 With my +1, that's six. Thanks all, Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Mon Aug 21 17:20:06 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Aug 2006 12:20:06 -0500 Subject: [Fedora-packaging] Re: Importance of debuginfo packages In-Reply-To: <20060821171655.GD25253@neu.nirvana> References: <44E9C8E1.1070501@math.unl.edu> <200608211248.08625.jkeating@redhat.com> <20060821171655.GD25253@neu.nirvana> Message-ID: <1156180806.26974.18.camel@localhost.localdomain> On Mon, 2006-08-21 at 19:16 +0200, Axel Thimm wrote: > On Mon, Aug 21, 2006 at 11:54:22AM -0500, Jason L Tibbitts III wrote: > > >>>>> "JK" == Jesse Keating writes: > > > > JK> Enough so that running gdb (gnu debugger) on the application will > > JK> produce a meaningful traceback. > > > > So what needs to be there in order for that to work? > > > > I need to be able to superficially inspect a debuginfo package and > > know whether it has enough stuff in it or not. > > That's very difficult, especially in projects with subdirectories that > may redefine CFLAGS/CXXFLAGS w/o the builder noticing. sope/ogo is one > nasty candidate for example. > > There are some safety pins in debuginfo, IIRC if it's turned on, but > the debuginfo turns out empty the build will fail. That's how it gets > my attention to fix debugging symbols at least :) Indeed, debuginfo being empty is about the only giant red warning flag that I'm aware of. :) ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Tue Aug 22 04:21:41 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 21 Aug 2006 23:21:41 -0500 Subject: [Fedora-packaging] Absolute symlinks Message-ID: rpmlint spits symlink-should-be-relative warnings when it sees an absolute symlink, and generally folks have fixed things up when presented with the warning. But now I've hit a review where the packager thinks an absolute symlink is appropriate and I'm not sure whether it's really an issue. The guidelines are silent on the subject; the only mention I see of it is in the mono guidelines, which say: ---- Mono installs binaries in /usr/lib//bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour). ---- That statement is somewhat confusing; is generating the error correct behavior? Is the symlink supposed to be fixed up or not? And does this apply in general to non-mono packages? - J< From rdieter at math.unl.edu Tue Aug 22 11:35:46 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 22 Aug 2006 06:35:46 -0500 Subject: [Fedora-packaging] Absolute symlinks In-Reply-To: References: Message-ID: <44EAEC12.4050501@math.unl.edu> Jason L Tibbitts III wrote: > rpmlint spits symlink-should-be-relative warnings when it sees an > absolute symlink, and generally folks have fixed things up when > presented with the warning. But now I've hit a review where the > packager thinks an absolute symlink is appropriate and I'm not sure > whether it's really an issue. That's why rpmlint issues only a warning. IMO, it doesn't matter that much one way or the other as long as it still "just works". > ---- > Mono installs binaries in /usr/lib//bin with symlinks back to > /usr/bin. rpmlint is not happy with this and generates an error (which > is the correct behaviour). > ---- An error? I thought rpmlint only issues a warning for this? -- Rex From paul at all-the-johnsons.co.uk Tue Aug 22 11:42:29 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Tue, 22 Aug 2006 12:42:29 +0100 Subject: [Fedora-packaging] Absolute symlinks In-Reply-To: <44EAEC12.4050501@math.unl.edu> References: <44EAEC12.4050501@math.unl.edu> Message-ID: <1156246949.2672.68.camel@localhost.localdomain> Hi, > > ---- > > Mono installs binaries in /usr/lib//bin with symlinks back to > > /usr/bin. rpmlint is not happy with this and generates an error (which > > is the correct behaviour). > > ---- > > An error? I thought rpmlint only issues a warning for this? The problem is not so much the binary being in lib, but that it's not an ELF binary. That said, bins in lib shouldn't happen really... TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From rdieter at math.unl.edu Tue Aug 22 12:14:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 22 Aug 2006 07:14:11 -0500 Subject: [Fedora-packaging] Re: Absolute symlinks References: <44EAEC12.4050501@math.unl.edu> <1156246949.2672.68.camel@localhost.localdomain> Message-ID: PFJ wrote: >> > ---- >> > Mono installs binaries in /usr/lib//bin with symlinks back to >> > /usr/bin. rpmlint is not happy with this and generates an error (which >> > is the correct behaviour). >> > ---- >> >> An error? I thought rpmlint only issues a warning for this? > > The problem is not so much the binary being in lib, but that it's not an > ELF binary. And that's a problem because? -- Rex From paul at all-the-johnsons.co.uk Tue Aug 22 12:25:27 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Tue, 22 Aug 2006 13:25:27 +0100 Subject: [Fedora-packaging] Re: Absolute symlinks In-Reply-To: References: <44EAEC12.4050501@math.unl.edu> <1156246949.2672.68.camel@localhost.localdomain> Message-ID: <1156249528.2672.71.camel@localhost.localdomain> Hi, > >> An error? I thought rpmlint only issues a warning for this? > > > > The problem is not so much the binary being in lib, but that it's not an > > ELF binary. > > And that's a problem because? Um, dunno, but rpmlint really does moan a lot with mono packages... TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From rdieter at math.unl.edu Tue Aug 22 12:29:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 22 Aug 2006 07:29:47 -0500 Subject: [Fedora-packaging] Re: Absolute symlinks In-Reply-To: <1156249528.2672.71.camel@localhost.localdomain> References: <44EAEC12.4050501@math.unl.edu> <1156246949.2672.68.camel@localhost.localdomain> <1156249528.2672.71.camel@localhost.localdomain> Message-ID: <44EAF8BB.4040502@math.unl.edu> PFJ wrote: >>>> An error? I thought rpmlint only issues a warning for this? >>> The problem is not so much the binary being in lib, but that it's not an >>> ELF binary. >> And that's a problem because? > Um, dunno, but rpmlint really does moan a lot with mono packages... So, lesson learned: don't blindly follow rpmlint? -- Rex From tibbs at math.uh.edu Tue Aug 22 13:57:01 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 22 Aug 2006 08:57:01 -0500 Subject: [Fedora-packaging] Absolute symlinks In-Reply-To: <44EAEC12.4050501@math.unl.edu> (Rex Dieter's message of "Tue, 22 Aug 2006 06:35:46 -0500") References: <44EAEC12.4050501@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> That's why rpmlint issues only a warning. IMO, it doesn't matter RD> that much one way or the other as long as it still "just works". What rpmlint chooses as a warning and what it chooses as an error seem to be arbitrary and not generally useful for predicting how significant the issues are. That is why I ask here. - J< From rdieter at math.unl.edu Tue Aug 22 14:29:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 22 Aug 2006 09:29:35 -0500 Subject: [Fedora-packaging] Absolute symlinks In-Reply-To: References: <44EAEC12.4050501@math.unl.edu> Message-ID: <44EB14CF.5020509@math.unl.edu> Jason L Tibbitts III wrote: >>>>>> "RD" == Rex Dieter writes: > > RD> That's why rpmlint issues only a warning. IMO, it doesn't matter > RD> that much one way or the other as long as it still "just works". > > What rpmlint chooses as a warning and what it chooses as an error seem > to be arbitrary and not generally useful for predicting how > significant the issues are. That is why I ask here. If we're speaking in "general", then consider rpmlint errors to be serious that deserve attention, and rpmlint warnings to be less serious and well, you get the idea. -- Rex From Axel.Thimm at ATrpms.net Tue Aug 22 14:44:16 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 22 Aug 2006 16:44:16 +0200 Subject: [Fedora-packaging] Re: Absolute symlinks In-Reply-To: References: Message-ID: <20060822144416.GA5028@neu.nirvana> On Mon, Aug 21, 2006 at 11:21:41PM -0500, Jason L Tibbitts III wrote: > rpmlint spits symlink-should-be-relative warnings when it sees an > absolute symlink, and generally folks have fixed things up when > presented with the warning. what is the rationale behind preferring relative to absolute symlinks (unless relative means in the same folder)? I would even prefer it the other way around to avoid breakage. > But now I've hit a review where the packager thinks an absolute > symlink is appropriate and I'm not sure whether it's really an > issue. The guidelines are silent on the subject; the only mention I > see of it is in the mono guidelines, which say: > > ---- > Mono installs binaries in /usr/lib//bin with symlinks back to > /usr/bin. rpmlint is not happy with this and generates an error (which > is the correct behaviour). > ---- > > That statement is somewhat confusing; is generating the error correct > behavior? Is the symlink supposed to be fixed up or not? And does > this apply in general to non-mono packages? > > - J< > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Aug 22 14:48:31 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 22 Aug 2006 09:48:31 -0500 Subject: [Fedora-packaging] Re: Absolute symlinks In-Reply-To: <20060822144416.GA5028@neu.nirvana> References: <20060822144416.GA5028@neu.nirvana> Message-ID: <44EB193F.3070900@math.unl.edu> Axel Thimm wrote: > On Mon, Aug 21, 2006 at 11:21:41PM -0500, Jason L Tibbitts III wrote: >> rpmlint spits symlink-should-be-relative warnings when it sees an >> absolute symlink, and generally folks have fixed things up when >> presented with the warning. > > what is the rationale behind preferring relative to absolute symlinks > (unless relative means in the same folder)? I would even prefer it the > other way around to avoid breakage. depends on your definition of breakage, whether the package is relocatable (not that we worry too much about that), whether the target of the symlink is in *this* pkg, etc... (: -- Rex From Axel.Thimm at ATrpms.net Tue Aug 22 14:56:17 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 22 Aug 2006 16:56:17 +0200 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060816174431.GF20037@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <20060816174431.GF20037@neu.nirvana> Message-ID: <20060822145617.GB5028@neu.nirvana> On Wed, Aug 16, 2006 at 07:44:31PM +0200, Axel Thimm wrote: > On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote: > > I suggest to vote through email [...] > > 5 voted, 5 still to go. Can the remaining committee members do their > voting business, please? Maybe we get this rejected and all can be > happy again ;) > > http://fedoraproject.org/wiki/AxelThimm/kmdls/voting > > I added Ville's votes (and copied them verbatim for Toshio on his > wish) but the first because he made it indirectly dependent on the > outcome: Ville & Toshio you need to decide on the first item, if you > are not sure better reject than accept, but don't conditionalize, it > makes vote counting difficult. :) > > Note: Don't use "0", it's the same as "-1" in fedora-packaging. As a committee we need to decide on certain items either positive or negative. Allowing discussion before voting is OK, but having a stalled voting over weeks isn't really an advertisment for our work. Please vote within the next day until Wed 16:00UTC. I'll consider the missing votes as "-1", but mark them as "0" to distinguish from the actual votes. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Tue Aug 22 15:04:16 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 22 Aug 2006 08:04:16 -0700 Subject: [Fedora-packaging] Absolute symlinks In-Reply-To: References: Message-ID: <1156259056.30998.11.camel@localhost> On Mon, 2006-08-21 at 23:21 -0500, Jason L Tibbitts III wrote: > rpmlint spits symlink-should-be-relative warnings when it sees an > absolute symlink, and generally folks have fixed things up when > presented with the warning. But now I've hit a review where the > packager thinks an absolute symlink is appropriate and I'm not sure > whether it's really an issue. Here's rpmlint's reasoning: 'Absolute symlinks are problematic eg. when working with chroot environments.' I don't know that this is a blocker (the symlinks will work within the chroot environment but trying to access the symlinks from outside the chroot will do the wrong thing [access the system file rather than the one inside the chroot.]) So what's the package and what's the reasoning? If the package can be broken with relative symlinks but absolute symlinks work 100% then that would swing the balance towards using absolute symlinks. If it really boils down to the packager thinking his application is special then I think rpmlint is right in this case. > The guidelines are silent on the > subject; the only mention I see of it is in the mono guidelines, which > say: > > ---- > Mono installs binaries in /usr/lib//bin with symlinks back to > /usr/bin. rpmlint is not happy with this and generates an error (which > is the correct behaviour). > ---- IIRC, PFJ ran across an rpmlint warning here that isn't about symlinks but about Mono applications installing to /usr/lib//bin. I think the wording needs to be changed here too, as last I looked, the "symlinks back to /usr/bin" are actually wrapper scripts in %{_bindir} pointing to the program file in %{_libdir}//bin/. -Toshio From Axel.Thimm at ATrpms.net Tue Aug 22 15:04:39 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 22 Aug 2006 17:04:39 +0200 Subject: [Fedora-packaging] Re: Absolute symlinks In-Reply-To: <44EB193F.3070900@math.unl.edu> References: <20060822144416.GA5028@neu.nirvana> <44EB193F.3070900@math.unl.edu> Message-ID: <20060822150439.GC5028@neu.nirvana> On Tue, Aug 22, 2006 at 09:48:31AM -0500, Rex Dieter wrote: > Axel Thimm wrote: > >On Mon, Aug 21, 2006 at 11:21:41PM -0500, Jason L Tibbitts III wrote: > >>rpmlint spits symlink-should-be-relative warnings when it sees an > >>absolute symlink, and generally folks have fixed things up when > >>presented with the warning. > > > >what is the rationale behind preferring relative to absolute symlinks > >(unless relative means in the same folder)? I would even prefer it the > >other way around to avoid breakage. > > depends on your definition of breakage, whether the package is > relocatable (not that we worry too much about that), whether the target > of the symlink is in *this* pkg, etc... (: Dangling symlinks break with relative and absolute links, but relative symlinks break whenever "folder/.." != ".", which is the case for symlinked folders. Example: Suppose you'd like to have /var/mail/foo link to /var/bar and do that with ../bar, you'll end up at /var/spool/bar instead. Symlinks in the filesystem as shipped are admittedly scarce, but it happens quite often to me that my system partition explodes and I need to move something over to a data partition symlinking it back. That would break relative symlinks, too. Relative symlinks w/o "..", e.g. starting in the same folder, don't break, though. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Aug 22 15:10:44 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 22 Aug 2006 17:10:44 +0200 Subject: [Fedora-packaging] Re: Absolute symlinks In-Reply-To: <1156259056.30998.11.camel@localhost> References: <1156259056.30998.11.camel@localhost> Message-ID: <20060822151044.GD5028@neu.nirvana> On Tue, Aug 22, 2006 at 08:04:16AM -0700, Toshio Kuratomi wrote: > Here's rpmlint's reasoning: > 'Absolute symlinks are problematic eg. when working with chroot > environments.' In that sense every symlink is danergerous including relative ones: if it contains too many ".." you'll end up outside the chroot anyway if accessed from outside. If accessed from inside the chroot, absolute paths are even securer when being root. Chroots (with external access, e.g. not within) aren't used by package consumers, but package builders and testers. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Tue Aug 22 15:31:49 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Aug 2006 10:31:49 -0500 Subject: [Fedora-packaging] Re: Mail voting on kmdl adoption In-Reply-To: <20060822145617.GB5028@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <20060816174431.GF20037@neu.nirvana> <20060822145617.GB5028@neu.nirvana> Message-ID: <1156260709.26974.94.camel@localhost.localdomain> On Tue, 2006-08-22 at 16:56 +0200, Axel Thimm wrote: > On Wed, Aug 16, 2006 at 07:44:31PM +0200, Axel Thimm wrote: > > On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote: > > > I suggest to vote through email [...] > > > > 5 voted, 5 still to go. Can the remaining committee members do their > > voting business, please? Maybe we get this rejected and all can be > > happy again ;) > > > > http://fedoraproject.org/wiki/AxelThimm/kmdls/voting > > > > I added Ville's votes (and copied them verbatim for Toshio on his > > wish) but the first because he made it indirectly dependent on the > > outcome: Ville & Toshio you need to decide on the first item, if you > > are not sure better reject than accept, but don't conditionalize, it > > makes vote counting difficult. :) > > > > Note: Don't use "0", it's the same as "-1" in fedora-packaging. > > As a committee we need to decide on certain items either positive or > negative. Allowing discussion before voting is OK, but having a > stalled voting over weeks isn't really an advertisment for our work. > > Please vote within the next day until Wed 16:00UTC. I'll consider the > missing votes as "-1", but mark them as "0" to distinguish from the > actual votes. I vote -1 on all items, not because KMDL has anything incorrect, but because I do not wish to overhaul an existing standard, rather than correct the flaws present in it. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Tue Aug 22 16:15:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 22 Aug 2006 11:15:59 -0500 Subject: [Fedora-packaging] Absolute symlinks In-Reply-To: <1156259056.30998.11.camel@localhost> (Toshio Kuratomi's message of "Tue, 22 Aug 2006 08:04:16 -0700") References: <1156259056.30998.11.camel@localhost> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> So what's the package and what's the reasoning? The package is eclipse-subclipse, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191017 The reasoning is that the Core eclipse packages all do things this way and it isn't a problem there. Yes, that doesn't get a whole lot of traction with me given the general state of Core, but rather than just say that I figure I'd get some idea of just why the rpmlint complaint is there. - J< From a.badger at gmail.com Tue Aug 22 16:56:28 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 22 Aug 2006 09:56:28 -0700 Subject: [Fedora-packaging] Re: Absolute symlinks In-Reply-To: <20060822151044.GD5028@neu.nirvana> References: <1156259056.30998.11.camel@localhost> <20060822151044.GD5028@neu.nirvana> Message-ID: <1156265788.3012.19.camel@localhost> On Tue, 2006-08-22 at 17:10 +0200, Axel Thimm wrote: > On Tue, Aug 22, 2006 at 08:04:16AM -0700, Toshio Kuratomi wrote: > > Here's rpmlint's reasoning: > > 'Absolute symlinks are problematic eg. when working with chroot > > environments.' > > In that sense every symlink is danergerous including relative ones: if > it contains too many ".." you'll end up outside the chroot anyway if > accessed from outside. That supposes that the symlink is referencing something above where the root directory should be. If it happens when the path is the same as where the package is meant to install, then I'd consider it a bug in packaging (ie: if you packaged a symlink, /usr/bin/ifconfig, it shouldn't point to ../../../../../sbin/ifconfig; it should point to ../../sbin/ifconfig). If it happens with the path changed, (You install the previous package with --relocate /usr/bin=/bin) I'm inclined to say that's unsupported behaviour anyway. > If accessed from inside the chroot, absolute > paths are even securer when being root. > More secure? > Chroots (with external access, e.g. not within) aren't used by package > consumers, but package builders and testers. This is incorrect. We often use chroots for building and testing packages here in Fedora but chroots are a much more general purpose tool. I think relative symlinks and chroots are most important with configuration files where an administrator will try to edit the file from outside the chroot. There can be a world of difference between $CHROOT/root/resolv.conf => ../etc/resolv.conf and $CHROOT/root/resolv.conf => /etc/resolv.conf -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue Aug 22 17:14:07 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 22 Aug 2006 19:14:07 +0200 Subject: [Fedora-packaging] Re: Absolute symlinks In-Reply-To: <1156265788.3012.19.camel@localhost> References: <1156259056.30998.11.camel@localhost> <20060822151044.GD5028@neu.nirvana> <1156265788.3012.19.camel@localhost> Message-ID: <20060822171407.GE5028@neu.nirvana> On Tue, Aug 22, 2006 at 09:56:28AM -0700, Toshio Kuratomi wrote: > > If accessed from inside the chroot, absolute > > paths are even securer when being root. > > > More secure? Yes, you can't escape a chroot using absolute paths, almost every chroot exploit uses ".." once too many. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Tue Aug 22 18:11:29 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 22 Aug 2006 11:11:29 -0700 Subject: [Fedora-packaging] Absolute symlinks In-Reply-To: References: <1156259056.30998.11.camel@localhost> Message-ID: <1156270289.3012.26.camel@localhost> On Tue, 2006-08-22 at 11:15 -0500, Jason L Tibbitts III wrote: > >>>>> "TK" == Toshio Kuratomi writes: > > TK> So what's the package and what's the reasoning? > > The package is eclipse-subclipse, > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191017 > > The reasoning is that the Core eclipse packages all do things this way > and it isn't a problem there. Yes, that doesn't get a whole lot of > traction with me given the general state of Core, but rather than just > say that I figure I'd get some idea of just why the rpmlint complaint > is there. Well, they aren't configuration files that the admin would want to edit. And Axel has some good points so based on information so far, I'd say rpmlint should be ignored here. Not sure what I think when configuration files are involved as I think Axel's points and mine would run smack dab into each other there. Guess we'll have to reevaluate if we run across a case where that occurs. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Wed Aug 23 14:12:56 2006 From: opensource at till.name (Till Maas) Date: Wed, 23 Aug 2006 16:12:56 +0200 Subject: [Fedora-packaging] Packaging/Guidelines - Usage of %{optflags} Message-ID: <200608231613.04454.opensource@till.name> Hiyas, at this time the Packaging-Guidelines do not mention whether or not %{optflags} should / must be used. They are used everytime %configure is executed, but there are also packages that do not have a ./configure script and for this reason would not use the %{optflags}. The flags in %{optflags} contain not only optimization but also security flags. For this reason I suggest that the Guidelines state that they have to be used. This will also help new contributors to know about this. I already mentioned this in fedora-extras-list, but without much feedback, but this may be the better mailinglist: https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00178.html Greetings, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 23 14:36:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 23 Aug 2006 16:36:27 +0200 Subject: [Fedora-packaging] Re: Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <200608231613.04454.opensource@till.name> References: <200608231613.04454.opensource@till.name> Message-ID: <20060823143627.GA30316@neu.nirvana> On Wed, Aug 23, 2006 at 04:12:56PM +0200, Till Maas wrote: > at this time the Packaging-Guidelines do not mention whether or not > %{optflags} should / must be used. They are used everytime > %configure is executed, but there are also packages that do not have > a ./configure script and for this reason would not use the > %{optflags}. The flags in %{optflags} contain not only optimization > but also security flags. For this reason I suggest that the > Guidelines state that they have to be used. This will also help new > contributors to know about this. I agree, but I'd make that a recommendation instead. There are a couple of packages known to break with some optimization flags, most notably such using hand-crafted asm and not tolerating any misalignments of structures. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Wed Aug 23 14:52:03 2006 From: opensource at till.name (Till Maas) Date: Wed, 23 Aug 2006 16:52:03 +0200 Subject: [Fedora-packaging] Re: Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <20060823143627.GA30316@neu.nirvana> References: <200608231613.04454.opensource@till.name> <20060823143627.GA30316@neu.nirvana> Message-ID: <200608231652.11047.opensource@till.name> On Wednesday 23 August 2006 16:36, Axel Thimm wrote: > I agree, but I'd make that a recommendation instead. There are a > couple of packages known to break with some optimization flags, most > notably such using hand-crafted asm and not tolerating any > misalignments of structures. Is this true for security flags like -D_FORTIFY_SOURCE=2 -fstack-protector? http://fedoraproject.org/wiki/Security/Features and the release notes for FC5 state, that all packages in Core and Extras are compiled with these features. For this reason at least these flags should be mandatory oder the exceptions should be mentioned in the wiki (if there are any). Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Aug 23 15:03:59 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 23 Aug 2006 17:03:59 +0200 Subject: [Fedora-packaging] Re: Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <200608231652.11047.opensource@till.name> References: <200608231613.04454.opensource@till.name> <20060823143627.GA30316@neu.nirvana> <200608231652.11047.opensource@till.name> Message-ID: <20060823150359.GB30316@neu.nirvana> On Wed, Aug 23, 2006 at 04:52:03PM +0200, Till Maas wrote: > On Wednesday 23 August 2006 16:36, Axel Thimm wrote: > > There are a couple of packages known to break with some > > optimization flags, most notably such using hand-crafted asm and > > not tolerating any misalignments of structures. > > Is this true for security flags like -D_FORTIFY_SOURCE=2 -fstack-protector? I'm only aware of issues due to optimization, I myself haven't heard any issues about security flags, so hopefully these are safe to use. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Wed Aug 23 16:38:36 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 23 Aug 2006 09:38:36 -0700 Subject: [Fedora-packaging] Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <200608231613.04454.opensource@till.name> References: <200608231613.04454.opensource@till.name> Message-ID: <1156351116.3001.2.camel@localhost> On Wed, 2006-08-23 at 16:12 +0200, Till Maas wrote: > Hiyas, > > at this time the Packaging-Guidelines do not mention whether or > not %{optflags} should / must be used. They are used everytime %configure is > executed, but there are also packages that do not have a ./configure script > and for this reason would not use the %{optflags}. The flags in %{optflags} > contain not only optimization but also security flags. For this reason I > suggest that the Guidelines state that they have to be used. This will also > help new contributors to know about this. I believe this has been ratified and is waiting for Ville to write up and enter into the guidelines: http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo http://www.fedoraproject.org/wiki/Packaging/IRCLog20060713 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Wed Aug 23 16:54:21 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 23 Aug 2006 09:54:21 -0700 Subject: [Fedora-packaging] GConf snippets suggestion In-Reply-To: <1156101712.8893.32.camel@indigo.declera.com> References: <1156056304.8893.10.camel@indigo.declera.com> <1156094396.2786.8.camel@localhost> <1156101712.8893.32.camel@indigo.declera.com> Message-ID: <1156352061.3001.7.camel@localhost> On Sun, 2006-08-20 at 22:21 +0300, Yanko Kaneti wrote: > On Sun, 2006-08-20 at 10:19 -0700, Toshio Kuratomi wrote: > > On Sun, 2006-08-20 at 09:45 +0300, Yanko Kaneti wrote: > > > > It tries to emphasize the proper (IMHO) --disable-schemas-install method > > > of disabling schemas installation on the build host vs the prevalent > > > GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL hack (again IMHO) > > > > > Could you explain why the configure script option should be considered > > canonical and the environment variable a hack? > > Its should be canonical because its part of the AM_GCONF_SOURCE_2 > autoconf macro which in turn is used by perhaps 99% of all gconf-using > packages out there. > Now, some use the macro but don't honor the automake conditional that > --disable-schemas-install sets. This IMO should be considered an > upstream bug. > > As to why using an overly wordy environment variable to negate a > specifically invoked action of a tool should be considered a hack? I'll > leave that to your good taste. > I personally consider the existence of this mechanism a GConf birth > defect that's been carried for too long. Thanks! I've started work on integrating that into the Draft for the next ScriptletSnippets page [1]_ and added it to the schedule [2]_. I'd like to take a look at some packages in Extras to make sure that most upstream packages will work with this suggestion and then we'll discuss this on this mailing list or in one of the weekly IRC meetings. [1]_ http://www.fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets [2]_ http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Wed Aug 23 16:57:38 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 23 Aug 2006 19:57:38 +0300 Subject: [Fedora-packaging] Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <1156351116.3001.2.camel@localhost> References: <200608231613.04454.opensource@till.name> <1156351116.3001.2.camel@localhost> Message-ID: <1156352258.2791.24.camel@viper.local> On Wed, 2006-08-23 at 09:38 -0700, Toshio Kuratomi wrote: > On Wed, 2006-08-23 at 16:12 +0200, Till Maas wrote: > > Hiyas, > > > > at this time the Packaging-Guidelines do not mention whether or > > not %{optflags} should / must be used. They are used everytime %configure is > > executed, but there are also packages that do not have a ./configure script > > and for this reason would not use the %{optflags}. The flags in %{optflags} > > contain not only optimization but also security flags. For this reason I > > suggest that the Guidelines state that they have to be used. This will also > > help new contributors to know about this. > > I believe this has been ratified and is waiting for Ville to write up > and enter into the guidelines: > > http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo > http://www.fedoraproject.org/wiki/Packaging/IRCLog20060713 Thanks for the reminder, will take care of it in a jiffy. From ville.skytta at iki.fi Wed Aug 23 19:41:27 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 23 Aug 2006 22:41:27 +0300 Subject: [Fedora-packaging] Absolute symlinks In-Reply-To: <44EB14CF.5020509@math.unl.edu> References: <44EAEC12.4050501@math.unl.edu> <44EB14CF.5020509@math.unl.edu> Message-ID: <1156362087.2791.45.camel@viper.local> On Tue, 2006-08-22 at 09:29 -0500, Rex Dieter wrote: > Jason L Tibbitts III wrote: > >>>>>> "RD" == Rex Dieter writes: > > > > What rpmlint chooses as a warning and what it chooses as an error seem > > to be arbitrary and not generally useful for predicting how > > significant the issues are. That is why I ask here. > > If we're speaking in "general", then consider rpmlint errors to be > serious that deserve attention, and rpmlint warnings to be less serious > and well, you get the idea. That's correct, with the addition that there are some checks that generally produce more false positives than others and aren't currently/cannot be done too robustly; in those cases I nowadays personally tend to make messages for new checks warnings even though the actual thing complained about might be a severe error if it's not a false positive. There's also quite a bit of historical baggage whose error/warning classification rationale is unknown to me, and may no longer be quite optimal as upstream rpmlint is no longer Mandriva specific. From opensource at till.name Wed Aug 23 21:46:30 2006 From: opensource at till.name (Till Maas) Date: Wed, 23 Aug 2006 23:46:30 +0200 Subject: [Fedora-packaging] Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <1156352258.2791.24.camel@viper.local> References: <200608231613.04454.opensource@till.name> <1156351116.3001.2.camel@localhost> <1156352258.2791.24.camel@viper.local> Message-ID: <200608232346.44268.opensource@till.name> Hello, thank you for your fast response. In http://fedoraproject.org/wiki/Packaging/Guidelines?action=diff#head-8b14098227aebff1cf6188939e9d0877295ac448 you only mention C and C++ Compilers, rpm --eval %configure shows, that also FFLAGS, which I believe are for Fortran, are set with the values of %optflags. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From yaneti at declera.com Wed Aug 23 23:27:55 2006 From: yaneti at declera.com (Yanko Kaneti) Date: Thu, 24 Aug 2006 02:27:55 +0300 Subject: [Fedora-packaging] GConf snippets suggestion In-Reply-To: <1156056304.8893.10.camel@indigo.declera.com> References: <1156056304.8893.10.camel@indigo.declera.com> Message-ID: <1156375675.28382.5.camel@indigo.declera.com> On Wed, 2006-08-23 at 09:54 -0700, Toshio Kuratomi wrote: > I'd like to take a look at some packages in Extras to make sure that most > upstream packages will work with this suggestion and then we'll discuss > this on this mailing list or in one of the weekly IRC meetings. > > [1]_ http://www.fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets > [2]_ http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo Here is some manually extracted food for thought. ^------^ (it could be quite wrong) - Packages that can be converted to --disable-schemas-install now -- Core -- bug-buddy compiz control-center desktop-printing devhelp ekiga eog epiphany evince evolution-webcal file-roller gcalctool gconf-editor gedit gnome-applets gnome-bluetooth gnome-games gnome-keyring-manager gnome-media gnome-netstatus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-system-monitor gnome-terminal gnome-user-share gnome-utils gnome-vfs2 gnopernicus gok gthumb libgnome metacity nautilus nautilus-cd-burner rhythmbox tomboy totem vino -- Extras -- banshee blam byzanz celestia gnome-applet-music gnome-applet-timer gnome-translate gnumeric gossip gramps liferea mail-notification muine qa-assistant regexxer revelation screem seahorse xchat-gnome - Packages needing upstream fixes to honor --disable-schemas-install -- Core -- evolution gnome-pilot sound-juicer -- Extras -- buoh contacts firestarter ghex glunarclock gnochm gnome-blog gnotime gstreamer08-plugins gwget monkey-bubble wp_tray - Other dasher - using gconf but not using AM_GCONF_SOURCE_2 conglomerate - needs upstream fixes for installing the schemas gmpc - doesnt need schema snippets as it doesn't use gconf gnome-applet-netmon - doesnt need schema snippets as it doesn't use gconf From Axel.Thimm at ATrpms.net Thu Aug 24 06:49:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 24 Aug 2006 08:49:43 +0200 Subject: [Fedora-packaging] kmdl voting results (was: Mail voting on kmdl adoption) In-Reply-To: <20060811105803.GA30245@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> Message-ID: <20060824064943.GA2532@neu.nirvana> On Fri, Aug 11, 2006 at 12:58:03PM +0200, Axel Thimm wrote: > Hi, > > I suggest to vote through email about replacing the current kernel > scheme with the kmdl or similar scheme. > > a) kernel module scheme needs uname-r-in-name > > b) kernel module scheme needs one-specfile approach (for both usreland > and kernel modules) > > c) kernel module scheme needs to be kernel agnostic (both version > *and* flavour) > > 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) > > e) Adoption of kmdl interface scheme as used at ATrpms and outlined on > http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive > vote on a-d) > > f) Assignment to kmdl-task force to integrate kmdl support into the > buildsystems used by Fedora (myself volunteering). Requires a > positive vote on a-e) > > g) Allow kmdl package submissions to Fedora Core/Extras. Requires a > positive vote on a-f) > > Without voting, but dependent on vote results: Assist in GFS kmdl > packaging (altready done at FC4 times, needs to resurface). After a long and painful struggle this matter reached an end. The voting result is that none of these passes. Also the voting participation indicates that this is not a topic this committee is interested in: http://fedoraproject.org/wiki/AxelThimm/kmdls/voting Almost half the members of this committee did not care to vote, some did not even comment on this matter at all. This is a sad thing. Not for the specific matter (which is sad, too), but because it was an item one of us worked his ass off to fulfill all possible incoming requests on documentation, explanation, use cases, examples, synopsis, whatever, and the least one would expect would be to have more people vote. It's ugly to see my efforts being rejected, but being ignored is even worse. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Thu Aug 24 18:46:14 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 24 Aug 2006 21:46:14 +0300 Subject: [Fedora-packaging] Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <200608232346.44268.opensource@till.name> References: <200608231613.04454.opensource@till.name> <1156351116.3001.2.camel@localhost> <1156352258.2791.24.camel@viper.local> <200608232346.44268.opensource@till.name> Message-ID: <1156445175.2791.49.camel@viper.local> On Wed, 2006-08-23 at 23:46 +0200, Till Maas wrote: > Hello, > > thank you for your fast response. In > http://fedoraproject.org/wiki/Packaging/Guidelines?action=diff#head-8b14098227aebff1cf6188939e9d0877295ac448 > you only mention C and C++ Compilers, > rpm --eval %configure > shows, that also FFLAGS, which I believe are for Fortran, are set with the > values of %optflags. Thanks for the catch, improved wording is online now: http://fedoraproject.org/wiki/Packaging/Guidelines?action=diff&rev2=72&rev1=71 From Axel.Thimm at ATrpms.net Thu Aug 24 19:24:12 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 24 Aug 2006 21:24:12 +0200 Subject: [Fedora-packaging] Re: Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <1156445175.2791.49.camel@viper.local> References: <200608231613.04454.opensource@till.name> <1156351116.3001.2.camel@localhost> <1156352258.2791.24.camel@viper.local> <200608232346.44268.opensource@till.name> <1156445175.2791.49.camel@viper.local> Message-ID: <20060824192412.GX19402@neu.nirvana> On Thu, Aug 24, 2006 at 09:46:14PM +0300, Ville Skytt? wrote: > On Wed, 2006-08-23 at 23:46 +0200, Till Maas wrote: > > Hello, > > > > thank you for your fast response. In > > http://fedoraproject.org/wiki/Packaging/Guidelines?action=diff#head-8b14098227aebff1cf6188939e9d0877295ac448 > > you only mention C and C++ Compilers, > > rpm --eval %configure > > shows, that also FFLAGS, which I believe are for Fortran, are set with the > > values of %optflags. If you really want to be picky, you'd have to mention FCFLAGS, too. Which is actually a bug in current FC6, let me think a bit about it. > Thanks for the catch, improved wording is online now: > http://fedoraproject.org/wiki/Packaging/Guidelines?action=diff&rev2=72&rev1=71 > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Aug 24 19:28:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 24 Aug 2006 21:28:31 +0200 Subject: [Fedora-packaging] Re: Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <20060824192412.GX19402@neu.nirvana> References: <200608231613.04454.opensource@till.name> <1156351116.3001.2.camel@localhost> <1156352258.2791.24.camel@viper.local> <200608232346.44268.opensource@till.name> <1156445175.2791.49.camel@viper.local> <20060824192412.GX19402@neu.nirvana> Message-ID: <20060824192831.GY19402@neu.nirvana> On Thu, Aug 24, 2006 at 09:24:12PM +0200, Axel Thimm wrote: > On Thu, Aug 24, 2006 at 09:46:14PM +0300, Ville Skytt? wrote: > > On Wed, 2006-08-23 at 23:46 +0200, Till Maas wrote: > > > Hello, > > > > > > thank you for your fast response. In > > > http://fedoraproject.org/wiki/Packaging/Guidelines?action=diff#head-8b14098227aebff1cf6188939e9d0877295ac448 > > > you only mention C and C++ Compilers, > > > rpm --eval %configure > > > shows, that also FFLAGS, which I believe are for Fortran, are set with the > > > values of %optflags. > > If you really want to be picky, you'd have to mention FCFLAGS, > too. Which is actually a bug in current FC6, let me think a bit about > it. Hm, looks like it's broken on FC5, too. :/ Probably not that many fortran packages to make this surface. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Aug 24 19:31:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 24 Aug 2006 21:31:27 +0200 Subject: [Fedora-packaging] Re: Packaging/Guidelines - Usage of %{optflags} In-Reply-To: <20060824192831.GY19402@neu.nirvana> References: <200608231613.04454.opensource@till.name> <1156351116.3001.2.camel@localhost> <1156352258.2791.24.camel@viper.local> <200608232346.44268.opensource@till.name> <1156445175.2791.49.camel@viper.local> <20060824192412.GX19402@neu.nirvana> <20060824192831.GY19402@neu.nirvana> Message-ID: <20060824193127.GZ19402@neu.nirvana> On Thu, Aug 24, 2006 at 09:28:31PM +0200, Axel Thimm wrote: > On Thu, Aug 24, 2006 at 09:24:12PM +0200, Axel Thimm wrote: > > On Thu, Aug 24, 2006 at 09:46:14PM +0300, Ville Skytt? wrote: > > > On Wed, 2006-08-23 at 23:46 +0200, Till Maas wrote: > > > > Hello, > > > > > > > > thank you for your fast response. In > > > > http://fedoraproject.org/wiki/Packaging/Guidelines?action=diff#head-8b14098227aebff1cf6188939e9d0877295ac448 > > > > you only mention C and C++ Compilers, > > > > rpm --eval %configure > > > > shows, that also FFLAGS, which I believe are for Fortran, are set with the > > > > values of %optflags. > > > > If you really want to be picky, you'd have to mention FCFLAGS, > > too. Which is actually a bug in current FC6, let me think a bit about > > it. > > Hm, looks like it's broken on FC5, too. :/ > > Probably not that many fortran packages to make this surface. BTW what needs fixing are rpm and/or redhat-rpm-config, not the guidelines, the guidelines are OK. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Thu Aug 24 20:10:44 2006 From: tcallawa at redhat.com (Tom Callaway) Date: Thu, 24 Aug 2006 15:10:44 -0500 Subject: [Fedora-packaging] kmdl voting results (was: Mail voting on kmdl adoption) In-Reply-To: <20060824064943.GA2532@neu.nirvana> References: <20060811105803.GA30245@neu.nirvana> <20060824064943.GA2532@neu.nirvana> Message-ID: <1156450244.14082.37.camel@dhcp-32-120.ord.redhat.com> > Almost half the members of this committee did not care to vote, some > did not even comment on this matter at all. This is a sad thing. Not > for the specific matter (which is sad, too), but because it was an > item one of us worked his ass off to fulfill all possible incoming > requests on documentation, explanation, use cases, examples, synopsis, > whatever, and the least one would expect would be to have more people > vote. Indeed. It would have been nice to at least see people who are truly disinterested vote with a 0. (Note: I am excluding Ralf from this, as he's said he will be unavailable for the near future) ~spot From opensource at till.name Fri Aug 25 16:10:33 2006 From: opensource at till.name (Till Maas) Date: Fri, 25 Aug 2006 18:10:33 +0200 Subject: [Fedora-packaging] Best practise license checking? Message-ID: <200608251810.42129.opensource@till.name> Hiyas, do you have any recommendations on how to check which license a package uses? Is it enough to look at the upstream homepage or README which license it uses or need a reviewer perform a code inspection? In the latter case is it enough to check the headers of each file for licensing? And has each file have a header with an allowed license? And after review, has the maintainer to check on each new file on each release whether or not the file has an allowed license? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Aug 25 16:37:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 25 Aug 2006 11:37:20 -0500 Subject: [Fedora-packaging] Best practise license checking? In-Reply-To: <200608251810.42129.opensource@till.name> References: <200608251810.42129.opensource@till.name> Message-ID: <44EF2740.30407@math.unl.edu> Till Maas wrote: > do you have any recommendations on how to check which license a package uses? > Is it enough to look at the upstream homepage or README which license it uses > or need a reviewer perform a code inspection? IMO, the former should be sufficient. -- Rex From toshio at tiki-lounge.com Sat Aug 26 16:01:39 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 26 Aug 2006 09:01:39 -0700 Subject: [Fedora-packaging] New Meeting Time Message-ID: <1156608100.31584.1.camel@localhost> Hi guys, as discussed in the meetings for the past couple of weeks, we're trying to change the meeting time. I've started a wiki page with a simple calendar to fill in days and times that work for you. You can also block off a section of time that doesn't work (as I've done for the West Coast sleep & commute period). http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Aug 29 07:52:06 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 29 Aug 2006 09:52:06 +0200 Subject: [Fedora-packaging] New Meeting Time In-Reply-To: <1156608100.31584.1.camel@localhost> References: <1156608100.31584.1.camel@localhost> Message-ID: <1156837926.19217.118.camel@mccallum.corsepiu.local> On Sat, 2006-08-26 at 09:01 -0700, Toshio Kuratomi wrote: > Hi guys, as discussed in the meetings for the past couple of weeks, > we're trying to change the meeting time. I've started a wiki page with > a simple calendar to fill in days and times that work for you. You can > also block off a section of time that doesn't work (as I've done for the > West Coast sleep & commute period). > > http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime Hmm, ATM most people seem to prefer 17:00 UTC. This is 19:00 CEST, and clashes with dinner-time. Ralf From chris.stone at gmail.com Tue Aug 29 18:13:36 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 29 Aug 2006 11:13:36 -0700 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps Message-ID: Hi, It should be really easy to make a script that builds metagroup packages from comps, no? This will allow someone to install a group such as kde/gnome as an rpm package and when packages are removed/added/changed in the comps groups, the meta group package also changes, and the user gets the appropriate changes. I don't think this is possible now with the groupinstall feature in yum which IMO is a bad feature since it should be done with meta group packages as I describe. Comments? From skvidal at linux.duke.edu Tue Aug 29 18:20:35 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 29 Aug 2006 14:20:35 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: References: Message-ID: <1156875635.1508.2.camel@cutter> On Tue, 2006-08-29 at 11:13 -0700, Christopher Stone wrote: > Hi, > > It should be really easy to make a script that builds metagroup > packages from comps, no? > > This will allow someone to install a group such as kde/gnome as an rpm > package and when packages are removed/added/changed in the comps > groups, the meta group package also changes, and the user gets the > appropriate changes. > > I don't think this is possible now with the groupinstall feature in > yum which IMO is a bad feature since it should be done with meta group > packages as I describe. So you want to make packages based on what is in comps? Whats the point of that if we can just read the comps information itself? -sv From chris.stone at gmail.com Tue Aug 29 18:25:05 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 29 Aug 2006 11:25:05 -0700 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <1156875635.1508.2.camel@cutter> References: <1156875635.1508.2.camel@cutter> Message-ID: On 8/29/06, seth vidal wrote: > Whats the point of that if we can just read the comps information > itself? Because it's easier to "yum install kde kde-optional" and have new kde packages added to your system automatically as comps changes. It's also more intuitive to noobs. "yum install kde" just makes more sense than "yum groupinstall "Some really long string describing the kde group which must be enclosed in quotes which you also have to look up with the yum list groups command which you have to always have to man yum to figure it out every time you run it, and keep in mind that you will have to manually always have to recheck the comps file every so often for every group you install to know if the group has changed, this will mean you will have to keep track of every package in every group and manually figure out changes on your own. good luck" From michael at knox.net.nz Tue Aug 29 18:27:46 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 30 Aug 2006 06:27:46 +1200 (NZST) Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <1156875635.1508.2.camel@cutter> References: <1156875635.1508.2.camel@cutter> Message-ID: <30228.203.118.135.21.1156876066.squirrel@www.knox.net.nz> seth vidal wrote: > On Tue, 2006-08-29 at 11:13 -0700, Christopher Stone wrote: >> Hi, >> >> It should be really easy to make a script that builds metagroup >> packages from comps, no? >> >> This will allow someone to install a group such as kde/gnome as an rpm >> package and when packages are removed/added/changed in the comps >> groups, the meta group package also changes, and the user gets the >> appropriate changes. >> >> I don't think this is possible now with the groupinstall feature in >> yum which IMO is a bad feature since it should be done with meta group >> packages as I describe. > > So you want to make packages based on what is in comps? > > Whats the point of that if we can just read the comps information > itself? Not if you use smart or apt.. these tools don't use comps.xml Michael > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From skvidal at linux.duke.edu Tue Aug 29 18:48:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 29 Aug 2006 14:48:36 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <30228.203.118.135.21.1156876066.squirrel@www.knox.net.nz> References: <1156875635.1508.2.camel@cutter> <30228.203.118.135.21.1156876066.squirrel@www.knox.net.nz> Message-ID: <1156877316.1508.7.camel@cutter> On Wed, 2006-08-30 at 06:27 +1200, Michael J. Knox wrote: > seth vidal wrote: > > On Tue, 2006-08-29 at 11:13 -0700, Christopher Stone wrote: > >> Hi, > >> > >> It should be really easy to make a script that builds metagroup > >> packages from comps, no? > >> > >> This will allow someone to install a group such as kde/gnome as an rpm > >> package and when packages are removed/added/changed in the comps > >> groups, the meta group package also changes, and the user gets the > >> appropriate changes. > >> > >> I don't think this is possible now with the groupinstall feature in > >> yum which IMO is a bad feature since it should be done with meta group > >> packages as I describe. > > > > So you want to make packages based on what is in comps? > > > > Whats the point of that if we can just read the comps information > > itself? > > Not if you use smart or apt.. these tools don't use comps.xml > That's up to them, isn't it? Ask the application maintainer. -sv From jkeating at redhat.com Tue Aug 29 18:51:20 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Aug 2006 14:51:20 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: References: <1156875635.1508.2.camel@cutter> Message-ID: <200608291451.23563.jkeating@redhat.com> On Tuesday 29 August 2006 14:25, Christopher Stone wrote: > Because it's easier to "yum install kde kde-optional" and have new kde > packages added to your system automatically as comps changes. > > It's also more intuitive to noobs. ?"yum install kde" just makes more > sense than "yum groupinstall "Some really long string describing the > kde group which must be enclosed in quotes which you also have to look > up with the yum list groups command which you have to always have to > man yum to figure it out every time you run it, and keep in mind that > you will have to manually always have to recheck the comps file every > so often for every group you install to know if the group has changed, > this will mean you will have to keep track of every package in every > group and manually figure out changes on your own. good luck" This is an invalid reasons. The noob wouldn't be using yum directly. They'd be using Add / Remove Software (pirut) and select the KDE Desktop group with their mouse, and any optional packages they want within that group. Puplet will let them know when there are updates, which will be processed by pup. How does your 'metapackage' fit into this scheme? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Aug 29 19:00:21 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 29 Aug 2006 15:00:21 -0400 Subject: [Fedora-packaging] Re: RFC: Creating meta group packages via comps In-Reply-To: References: Message-ID: <1156878021.11204.4.camel@aglarond.local> On Tue, 2006-08-29 at 11:09 -0700, Christopher Stone wrote: > It should be really easy to make a script that builds metagroup > packages from comps, no? > > This will allow someone to install a group such as kde/gnome as an rpm > package and when packages are removed/added/changed in the comps > groups, the meta group package also changes, and the user gets the > appropriate changes. > > I don't think this is possible now with the groupinstall feature in > yum which IMO is a bad feature since it should be done with meta group > packages as I describe. > > Comments? The entire point here is that there don't have to be packages to keep track of this metadata -- so if you change comps, you don't have to go change lots of packages. This is also really helpful for doing site-specific customizations of what the various groups are. The argument about a "noob" is pretty much moot as they're far more likely to be using the graphical interface as opposed to yum on the command line. And at that point, the comps file becomes even _more_ important as it's used for the entirety of the display. Jeremy From chris.stone at gmail.com Tue Aug 29 19:15:09 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 29 Aug 2006 12:15:09 -0700 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <200608291451.23563.jkeating@redhat.com> References: <1156875635.1508.2.camel@cutter> <200608291451.23563.jkeating@redhat.com> Message-ID: On 8/29/06, Jesse Keating wrote: > Puplet > will let them know when there are updates, which will be processed by pup. > How does your 'metapackage' fit into this scheme? Puplet only does a "yum check-install" (AFAIK since this is the first time Ive even heard of this app). There is absolutely nothing it does to check if new packages have been added to a group. If a non-optional package is added to a group that no other package depends on, how is the user to know he needs to install this package? In addition a user may want to have all packages for a group. For example I should be able to select that I want all optional games packages and every time a new game is added to comps, it should be installed on my system automatically. puplet does not do this AFAIK. From chris.stone at gmail.com Tue Aug 29 19:15:44 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 29 Aug 2006 12:15:44 -0700 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: References: <1156875635.1508.2.camel@cutter> <200608291451.23563.jkeating@redhat.com> Message-ID: On 8/29/06, Christopher Stone wrote: > Puplet only does a "yum check-install" (AFAIK since this is the first er yum check-update I mean... From jkeating at redhat.com Tue Aug 29 19:28:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Aug 2006 15:28:23 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: References: <200608291451.23563.jkeating@redhat.com> Message-ID: <200608291528.23204.jkeating@redhat.com> On Tuesday 29 August 2006 15:15, Christopher Stone wrote: > Puplet only does a "yum check-install" (AFAIK since this is the first > time Ive even heard of this app). ? There is absolutely nothing it > does to check if new packages have been added to a group. ?If a > non-optional package is added to a group that no other package depends > on, how is the user to know he needs to install this package? > > In addition a user may want to have all packages for a group. ?For > example I should be able to select that I want all optional games > packages and every time a new game is added to comps, it should be > installed on my system automatically. ?puplet does not do this AFAIK. *shrug* I'm not sure users want to constantly get more and more packages added to their install, vs just the existing packages updated. Typically RHL/Fedora releases wouldn't change comps for the duration of the release, but with Extras and new packages being added all the time, comps can get updated. Blindly adding new packages to a user's install isn't the way, perhaps if the user launches pirut it can notice that new packages have been added to the pool and do a interesting popup or a window that says "new packages added to the pool: foo in group Bar baz in group Zing and let the USER decide if they want to add those packages or not. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Tue Aug 29 19:45:25 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Tue, 29 Aug 2006 20:45:25 +0100 Subject: [Fedora-packaging] Re: RFC: Creating meta group packages via comps In-Reply-To: <1156878021.11204.4.camel@aglarond.local> References: <1156878021.11204.4.camel@aglarond.local> Message-ID: <200608292045.25992.jamatos@fc.up.pt> On Tuesday 29 August 2006 20:00, Jeremy Katz wrote: > The argument about a "noob" is pretty much moot as they're far more > likely to be using the graphical interface as opposed to yum on the > command line. ?And at that point, the comps file becomes even _more_ > important as it's used for the entirety of the display. OTHO, since any package is listed in just one category does not help so much users and I am not talking about new users only. Something like trove would be interesting, after all world is not just black and white. :-) The possible solution should be clearly a superset of comp files to avoid synchronisation problems... One way to do it would be to use something like: ... xxxx ... ... ... xxxx ... > Jeremy -- Jos? Ab?lio From notting at redhat.com Tue Aug 29 19:47:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Aug 2006 15:47:22 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <200608291528.23204.jkeating@redhat.com> References: <200608291451.23563.jkeating@redhat.com> <200608291528.23204.jkeating@redhat.com> Message-ID: <20060829194722.GA12254@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > *shrug* I'm not sure users want to constantly get more and more packages added > to their install, vs just the existing packages updated. Typically > RHL/Fedora releases wouldn't change comps for the duration of the release, > but with Extras and new packages being added all the time, comps can get > updated. Blindly adding new packages to a user's install isn't the way, > perhaps if the user launches pirut it can notice that new packages have been > added to the pool and do a interesting popup or a window that says "new > packages added to the pool: > foo in group Bar > baz in group Zing > > and let the USER decide if they want to add those packages or not. So, to do this you'd need to keep track of the *previous* state of the comps and do (essentially) a diff. The metadata at the moment isn't set to store this information. Napkin-ing this, you'd compare it, see the new packages, and then pop up: New software available in the 'Games' group: GnomePoker - Play poker against your friends! Lose all your money! HackSlashKillMaim - Role play as your favorite serial killer [ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ] or something along those lines. Bill From skvidal at linux.duke.edu Tue Aug 29 19:53:57 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 29 Aug 2006 15:53:57 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <20060829194722.GA12254@nostromo.devel.redhat.com> References: <200608291451.23563.jkeating@redhat.com> <200608291528.23204.jkeating@redhat.com> <20060829194722.GA12254@nostromo.devel.redhat.com> Message-ID: <1156881238.1508.10.camel@cutter> On Tue, 2006-08-29 at 15:47 -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > *shrug* I'm not sure users want to constantly get more and more packages added > > to their install, vs just the existing packages updated. Typically > > RHL/Fedora releases wouldn't change comps for the duration of the release, > > but with Extras and new packages being added all the time, comps can get > > updated. Blindly adding new packages to a user's install isn't the way, > > perhaps if the user launches pirut it can notice that new packages have been > > added to the pool and do a interesting popup or a window that says "new > > packages added to the pool: > > foo in group Bar > > baz in group Zing > > > > and let the USER decide if they want to add those packages or not. > > So, to do this you'd need to keep track of the *previous* state of the > comps and do (essentially) a diff. The metadata at the moment isn't > set to store this information. > > Napkin-ing this, you'd compare it, see the new packages, and then > pop up: > > New software available in the 'Games' group: > > GnomePoker - Play poker against your friends! Lose all your money! > HackSlashKillMaim - Role play as your favorite serial killer > > [ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ] > > or something along those lines. You should be able to just run groupinstall again and it will only install the new stuff in that comps group. -sv From notting at redhat.com Tue Aug 29 19:58:04 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Aug 2006 15:58:04 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <1156881238.1508.10.camel@cutter> References: <200608291451.23563.jkeating@redhat.com> <200608291528.23204.jkeating@redhat.com> <20060829194722.GA12254@nostromo.devel.redhat.com> <1156881238.1508.10.camel@cutter> Message-ID: <20060829195804.GB12254@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > > Napkin-ing this, you'd compare it, see the new packages, and then > > pop up: > > > > New software available in the 'Games' group: > > > > GnomePoker - Play poker against your friends! Lose all your money! > > HackSlashKillMaim - Role play as your favorite serial killer > > > > [ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ] > > > > or something along those lines. > > You should be able to just run groupinstall again and it will only > install the new stuff in that comps group. But we don't: a) store what groups are installed on the box, to know how to automatically do this b) users may want to know about new optional packages, that this won't catch Bill From skvidal at linux.duke.edu Tue Aug 29 20:14:58 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 29 Aug 2006 16:14:58 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <20060829195804.GB12254@nostromo.devel.redhat.com> References: <200608291451.23563.jkeating@redhat.com> <200608291528.23204.jkeating@redhat.com> <20060829194722.GA12254@nostromo.devel.redhat.com> <1156881238.1508.10.camel@cutter> <20060829195804.GB12254@nostromo.devel.redhat.com> Message-ID: <1156882498.1508.13.camel@cutter> On Tue, 2006-08-29 at 15:58 -0400, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > > Napkin-ing this, you'd compare it, see the new packages, and then > > > pop up: > > > > > > New software available in the 'Games' group: > > > > > > GnomePoker - Play poker against your friends! Lose all your money! > > > HackSlashKillMaim - Role play as your favorite serial killer > > > > > > [ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ] > > > > > > or something along those lines. > > > > You should be able to just run groupinstall again and it will only > > install the new stuff in that comps group. > > But we don't: > a) store what groups are installed on the box, to know how to automatically > do this yum can more or less generate that based on what is currently installed. > b) users may want to know about new optional packages, that this won't catch true enough. -sv From jkeating at redhat.com Tue Aug 29 20:26:38 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Aug 2006 16:26:38 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <20060829194722.GA12254@nostromo.devel.redhat.com> References: <200608291528.23204.jkeating@redhat.com> <20060829194722.GA12254@nostromo.devel.redhat.com> Message-ID: <200608291626.38557.jkeating@redhat.com> On Tuesday 29 August 2006 15:47, Bill Nottingham wrote: > So, to do this you'd need to keep track of the *previous* state of the > comps and do (essentially) a diff. The metadata at the moment isn't > set to store this information. Not necessarily. It doesn't necessarily have to be a comps group that changed. Could be "I didn't have a cached entry for this package before, this is a new one to me, lets throw a popup". Yum knows about what it knows about (right?), and anything new could be flagged as new, and thus get the popup. Would cover packages that are new that aren't in any comps group too (although you might want to filter those by default...) > Napkin-ing this, you'd compare it, see the new packages, and then > pop up: > > ?New software available in the 'Games' group: > > ? ?GnomePoker - Play poker against your friends! Lose all your money! > ? ?HackSlashKillMaim - Role play as your favorite serial killer > ? ? > ?[ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages > ] > > or something along those lines. Yeah, that makes some kind of sense. Would be a cool way of getting new packages into the hands of users. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Aug 29 20:30:04 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 29 Aug 2006 16:30:04 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <1156882498.1508.13.camel@cutter> References: <200608291451.23563.jkeating@redhat.com> <200608291528.23204.jkeating@redhat.com> <20060829194722.GA12254@nostromo.devel.redhat.com> <1156881238.1508.10.camel@cutter> <20060829195804.GB12254@nostromo.devel.redhat.com> <1156882498.1508.13.camel@cutter> Message-ID: <1156883404.20029.3.camel@aglarond.local> On Tue, 2006-08-29 at 16:14 -0400, seth vidal wrote: > On Tue, 2006-08-29 at 15:58 -0400, Bill Nottingham wrote: > > seth vidal (skvidal at linux.duke.edu) said: > > > > Napkin-ing this, you'd compare it, see the new packages, and then > > > > pop up: > > > > > > > > New software available in the 'Games' group: > > > > > > > > GnomePoker - Play poker against your friends! Lose all your money! > > > > HackSlashKillMaim - Role play as your favorite serial killer > > > > > > > > [ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ] > > > > > > > > or something along those lines. > > > > > > You should be able to just run groupinstall again and it will only > > > install the new stuff in that comps group. > > > > But we don't: > > a) store what groups are installed on the box, to know how to automatically > > do this > > yum can more or less generate that based on what is currently installed. Not reliably if the contents of groups change. Jeremy From skvidal at linux.duke.edu Tue Aug 29 20:30:43 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 29 Aug 2006 16:30:43 -0400 Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <1156883404.20029.3.camel@aglarond.local> References: <200608291451.23563.jkeating@redhat.com> <200608291528.23204.jkeating@redhat.com> <20060829194722.GA12254@nostromo.devel.redhat.com> <1156881238.1508.10.camel@cutter> <20060829195804.GB12254@nostromo.devel.redhat.com> <1156882498.1508.13.camel@cutter> <1156883404.20029.3.camel@aglarond.local> Message-ID: <1156883444.1508.15.camel@cutter> On Tue, 2006-08-29 at 16:30 -0400, Jeremy Katz wrote: > On Tue, 2006-08-29 at 16:14 -0400, seth vidal wrote: > > On Tue, 2006-08-29 at 15:58 -0400, Bill Nottingham wrote: > > > seth vidal (skvidal at linux.duke.edu) said: > > > > > Napkin-ing this, you'd compare it, see the new packages, and then > > > > > pop up: > > > > > > > > > > New software available in the 'Games' group: > > > > > > > > > > GnomePoker - Play poker against your friends! Lose all your money! > > > > > HackSlashKillMaim - Role play as your favorite serial killer > > > > > > > > > > [ Don't install ] [ Tell me more ] [ Ask me later ] [ Install new packages ] > > > > > > > > > > or something along those lines. > > > > > > > > You should be able to just run groupinstall again and it will only > > > > install the new stuff in that comps group. > > > > > > But we don't: > > > a) store what groups are installed on the box, to know how to automatically > > > do this > > > > yum can more or less generate that based on what is currently installed. > > Not reliably if the contents of groups change. > agreed. -sv From jjneely at ncsu.edu Tue Aug 29 21:13:50 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Tue, 29 Aug 2006 17:13:50 -0400 Subject: [Fedora-packaging] Re: RFC: Creating meta group packages via comps In-Reply-To: <1156878021.11204.4.camel@aglarond.local> References: <1156878021.11204.4.camel@aglarond.local> Message-ID: <20060829211350.GL32595@anduril.unity.ncsu.edu> On Tue, Aug 29, 2006 at 03:00:21PM -0400, Jeremy Katz wrote: > On Tue, 2006-08-29 at 11:09 -0700, Christopher Stone wrote: > > It should be really easy to make a script that builds metagroup > > packages from comps, no? > > > > This will allow someone to install a group such as kde/gnome as an rpm > > package and when packages are removed/added/changed in the comps > > groups, the meta group package also changes, and the user gets the > > appropriate changes. > > > > I don't think this is possible now with the groupinstall feature in > > yum which IMO is a bad feature since it should be done with meta group > > packages as I describe. > > > > Comments? > > The entire point here is that there don't have to be packages to keep > track of this metadata -- so if you change comps, you don't have to go > change lots of packages. This is also really helpful for doing > site-specific customizations of what the various groups are. > > The argument about a "noob" is pretty much moot as they're far more > likely to be using the graphical interface as opposed to yum on the > command line. And at that point, the comps file becomes even _more_ > important as it's used for the entirety of the display. > > Jeremy > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging I agree that packages for maintaining this metadata is bad. However, I do have issues related to this. I build/maintain slightly modified versions of FC/RHEL to support NC State University. For some time now administrators on campus have known that if they want a stripped down server they can use kickstart and include the Server group. For workstations, the kickstart has one or two workstation groups that install the standard setup. Now to install a workstation the kickstart needs to have...I think I stopped counting at 15 groups. This is slightly problematic in 2 ways. I have a pretty big re-education effort (much more so than if the names of the group changed or only 1 or 2 additions). Also, there's a large risk that one group or another will forget/add certain groups making my managed clients less identical, harder to maintain, and even worse to support. Perhaps I've missed something. Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From mattdm at mattdm.org Wed Aug 30 01:05:42 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 29 Aug 2006 21:05:42 -0400 Subject: [Fedora-packaging] Re: RFC: Creating meta group packages via comps In-Reply-To: <20060829211350.GL32595@anduril.unity.ncsu.edu> References: <1156878021.11204.4.camel@aglarond.local> <20060829211350.GL32595@anduril.unity.ncsu.edu> Message-ID: <20060830010542.GA19949@jadzia.bu.edu> On Tue, Aug 29, 2006 at 05:13:50PM -0400, Jack Neely wrote: > Perhaps I've missed something. You don't make your own comps.xml? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pmatilai at laiskiainen.org Wed Aug 30 06:17:10 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 30 Aug 2006 09:17:10 +0300 (EEST) Subject: [Fedora-packaging] RFC: Creating meta group packages via comps In-Reply-To: <1156877316.1508.7.camel@cutter> References: <1156875635.1508.2.camel@cutter> <30228.203.118.135.21.1156876066.squirrel@www.knox.net.nz> <1156877316.1508.7.camel@cutter> Message-ID: On Tue, 29 Aug 2006, seth vidal wrote: > On Wed, 2006-08-30 at 06:27 +1200, Michael J. Knox wrote: >> seth vidal wrote: >>> On Tue, 2006-08-29 at 11:13 -0700, Christopher Stone wrote: >>>> Hi, >>>> >>>> It should be really easy to make a script that builds metagroup >>>> packages from comps, no? >>>> >>>> This will allow someone to install a group such as kde/gnome as an rpm >>>> package and when packages are removed/added/changed in the comps >>>> groups, the meta group package also changes, and the user gets the >>>> appropriate changes. >>>> >>>> I don't think this is possible now with the groupinstall feature in >>>> yum which IMO is a bad feature since it should be done with meta group >>>> packages as I describe. >>> >>> So you want to make packages based on what is in comps? >>> >>> Whats the point of that if we can just read the comps information >>> itself? >> >> Not if you use smart or apt.. these tools don't use comps.xml >> > > That's up to them, isn't it? Ask the application maintainer. Apt used to have support for comps.xml with the previous format of comps.xml in the form of a plugin and it's certainly on the todo-list to resurrect the functionality one way or the other. As for metapackages, JUST SAY NO. I've been down that path, they are nothing short of hidous to deal with. Carefully handcrafted metapackage(s) *might* make sense in some specific environments / cases but automatically generated humongous dep-bloat comps-metapackages are nothing but pain, pain, pain. - Panu - From jjneely at ncsu.edu Wed Aug 30 15:22:09 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Wed, 30 Aug 2006 11:22:09 -0400 Subject: [Fedora-packaging] Re: RFC: Creating meta group packages via comps In-Reply-To: <20060830010542.GA19949@jadzia.bu.edu> References: <1156878021.11204.4.camel@aglarond.local> <20060829211350.GL32595@anduril.unity.ncsu.edu> <20060830010542.GA19949@jadzia.bu.edu> Message-ID: <20060830152209.GO32595@anduril.unity.ncsu.edu> On Tue, Aug 29, 2006 at 09:05:42PM -0400, Matthew Miller wrote: > On Tue, Aug 29, 2006 at 05:13:50PM -0400, Jack Neely wrote: > > Perhaps I've missed something. > > You don't make your own comps.xml? > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging I do. Been using groups of groups which no longer work. *Looks* Hmm, perhaps categorys work better than I think they do. Shall be my after lunch source code reading... Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From orion at cora.nwra.com Wed Aug 30 22:01:04 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 30 Aug 2006 16:01:04 -0600 Subject: [Fedora-packaging] cmake best practices Message-ID: <44F60AA0.3090508@cora.nwra.com> It appears that more and more projects are moving to cmake, especially with KDE4 making the jump. Two packages of mine (plplot and kdesvn) are also making the switch. I also happen to be the current packager for cmake itself (because I package paraview which uses it), though I expect it will have to get moved to core relatively soon. It seems like it is time to start collecting cmake best practices for generating Fedora RPMS using cmake, and perhaps even creating a %cmake rpm macro that is analagous to the %configure macro. Here's what I have so far (note that cmake generally does out of tree builds): %build mkdir fedora cd fedora export CFLAGS="$RPM_OPT_FLAGS" export CXXFLAGS="$RPM_OPT_FLAGS" cmake .. \ -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \ -DBUILD_SHARED_LIBS:BOOL=ON \ -DCMAKE_SKIP_RPATH:BOOL=ON make VERBOSE=1 %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT cd fedora make install DESTDIR=$RPM_BUILD_ROOT I'm also running into trouble getting kdesvn to install into /usr/lib64 on x86_64. This might just be a matter of educating upstream users on the proper cmake commands for this (once I figure that out myself...). Currently there is lots of hard coding of "lib" into install paths. Now, where to put this in the wiki? -- Orion Poplawski System Administrator 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From Axel.Thimm at ATrpms.net Thu Aug 31 17:01:07 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 31 Aug 2006 19:01:07 +0200 Subject: [Fedora-packaging] New meeting time Message-ID: <20060831170107.GH28961@neu.nirvana> Hi, all 7 participants of today's IRC session would agree to Tue, 17:00 UTC + DST fixes. http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime It's two days before fesco which will make some easier information passing and evaluation. The remaining three are Ralf, Jose and David. Is it OK with you? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: