packaging August 2006

packaging@lists.fedoraproject.org

35 participants
40 discussions

Re: Attention kernel module project packagers!
by Axel Thimm 15 Aug '06

15 Aug '06

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

1 0

Re: Attention kernel module project packagers!
by Axel Thimm 15 Aug '06

15 Aug '06

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

1 0

Attention kernel module project packagers!
by Axel Thimm 15 Aug '06

15 Aug '06

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

1 1

get further rid of uname -r in the kmod stuff and solve the remaining kmod problem
by Thorsten Leemhuis 15 Aug '06

15 Aug '06

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<?kernel-flavour>-<?kernel-version> 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

6 12

kmdl proposal and kmod flaws
by Axel Thimm 15 Aug '06

15 Aug '06

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

9 33

Pointer: Packaging discussion about Boost (C++) library
by Kenneth Porter 14 Aug '06

14 Aug '06

<http://lists.boost.org/Archives/boost/2006/08/index.php> 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.

1 0

Missing IRCs
by Ralf Corsepius 10 Aug '06

10 Aug '06

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

1 0

missing this week's meetings
by Tom Callaway 10 Aug '06

10 Aug '06

Due to the fact that I will be on a plane somewhere between California and Illinois on Thursday, I will not be able to attend this week's Packaging or FESCo meetings. ~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!

6 10

Fix problems building Extras packages for FC3 and FC4
by Thorsten Leemhuis 06 Aug '06

06 Aug '06

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

1 0

Fwd: When to use perl(:WITH_...) requires?
by Chris Weyl 02 Aug '06

02 Aug '06

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 <cweyl(a)alumni.drew.edu> Date: Jul 31, 2006 8:15 AM Subject: When to use perl(:WITH_...) requires? To: Discussion related to Fedora Extras <fedora-extras-list(a)redhat.com> 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

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2006