From i.pilcher at comcast.net Wed Jun 1 17:34:58 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 01 Jun 2005 12:34:58 -0500 Subject: [Fedora-packaging] "License" tag for GPL w/ exception Message-ID: I'm finally getting around to cleaning up the nedit SRPM (from Fedora CVS) for inclusion in Extras, and rpmlint is complaining about the "License: distributable" tag in the SPEC file. nedit is licensed under the GPL, with the following exception: In addition, as a special exception to the GNU GPL, the copyright holders give permission to link the code of this program with the Motif and Open Motif libraries (or with modified versions of these that use the same license), and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than linking with Motif/Open Motif. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. So what is the appropriate tag? Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From tcallawa at redhat.com Thu Jun 2 05:04:02 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 02 Jun 2005 00:04:02 -0500 Subject: [Fedora-packaging] "License" tag for GPL w/ exception In-Reply-To: References: Message-ID: <1117688642.3713.27.camel@localhost.localdomain> On Wed, 2005-06-01 at 12:34 -0500, Ian Pilcher wrote: > I'm finally getting around to cleaning up the nedit SRPM (from Fedora > CVS) for inclusion in Extras, and rpmlint is complaining about the > "License: distributable" tag in the SPEC file. nedit is licensed under > the GPL, with the following exception: > > In addition, as a special exception to the GNU GPL, the copyright > holders give permission to link the code of this program with the > Motif and Open Motif libraries (or with modified versions of these > that use the same license), and distribute linked combinations > including the two. You must obey the GNU General Public License in all > respects for all of the code used other than linking with Motif/Open > Motif. If you modify this file, you may extend this exception to your > version of the file, but you are not obligated to do so. If you do not > wish to do so, delete this exception statement from your version. > > So what is the appropriate tag? Use "GPL (with Motif/Open Motif linking exception)" or something equally concise and relevant. rpmlint will spit on that too, but I'd rather have it be accurate than have it be something vague like "distributable". Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Tue Jun 21 16:06:17 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 21 Jun 2005 19:06:17 +0300 Subject: [Fedora-packaging] Using self-Obsoletes instead of Epoch bumps? Message-ID: <1119369977.28867.166.camel@bobcat.mine.nu> Has anyone ever experimented with or considered using self-Obsoletes as an alternative to Epoch bumps using plain rpm CLI and various depsolvers? Assuming there's a finite and known set of "supported" packages, listing all of them as an explicit, exact (note: always "=") Obsoletes: %{name} = $v-$r for each such (E)VR could possibly be thought of as a 3rd party friendly substitute for an Epoch bump. Sure, it would be a larger maintenance burden than the bump, but how much so, and would it even work in practice? Good/incrediby-stupid/something-in-between idea? From skvidal at phy.duke.edu Tue Jun 21 17:27:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 21 Jun 2005 13:27:49 -0400 Subject: [Fedora-packaging] Using self-Obsoletes instead of Epoch bumps? In-Reply-To: <1119369977.28867.166.camel@bobcat.mine.nu> References: <1119369977.28867.166.camel@bobcat.mine.nu> Message-ID: <1119374869.24920.22.camel@opus.phy.duke.edu> On Tue, 2005-06-21 at 19:06 +0300, Ville Skytt? wrote: > Has anyone ever experimented with or considered using self-Obsoletes as > an alternative to Epoch bumps using plain rpm CLI and various > depsolvers? > > Assuming there's a finite and known set of "supported" packages, listing > all of them as an explicit, exact (note: always "=") > > Obsoletes: %{name} = $v-$r > well to make it catch older ones you'd need <= $v-$r and at that point wouldn't the package be obsoleting itself b/c of the version confusion? -sv From ville.skytta at iki.fi Tue Jun 21 17:38:56 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 21 Jun 2005 20:38:56 +0300 Subject: [Fedora-packaging] Using self-Obsoletes instead of Epoch bumps? In-Reply-To: <1119374869.24920.22.camel@opus.phy.duke.edu> References: <1119369977.28867.166.camel@bobcat.mine.nu> <1119374869.24920.22.camel@opus.phy.duke.edu> Message-ID: <1119375536.28867.169.camel@bobcat.mine.nu> On Tue, 2005-06-21 at 13:27 -0400, seth vidal wrote: > On Tue, 2005-06-21 at 19:06 +0300, Ville Skytt? wrote: > > Has anyone ever experimented with or considered using self-Obsoletes as > > an alternative to Epoch bumps using plain rpm CLI and various > > depsolvers? > > > > Assuming there's a finite and known set of "supported" packages, listing > > all of them as an explicit, exact (note: always "=") > > > > Obsoletes: %{name} = $v-$r > > well to make it catch older ones you'd need <= $v-$r > > and at that point wouldn't the package be obsoleting itself b/c of the > version confusion? Yes. But as I said above, always "=". Not "<=" or anything else. From skvidal at phy.duke.edu Tue Jun 21 17:39:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 21 Jun 2005 13:39:30 -0400 Subject: [Fedora-packaging] Using self-Obsoletes instead of Epoch bumps? In-Reply-To: <1119375536.28867.169.camel@bobcat.mine.nu> References: <1119369977.28867.166.camel@bobcat.mine.nu> <1119374869.24920.22.camel@opus.phy.duke.edu> <1119375536.28867.169.camel@bobcat.mine.nu> Message-ID: <1119375571.24920.24.camel@opus.phy.duke.edu> On Tue, 2005-06-21 at 20:38 +0300, Ville Skytt? wrote: > On Tue, 2005-06-21 at 13:27 -0400, seth vidal wrote: > > On Tue, 2005-06-21 at 19:06 +0300, Ville Skytt? wrote: > > > Has anyone ever experimented with or considered using self-Obsoletes as > > > an alternative to Epoch bumps using plain rpm CLI and various > > > depsolvers? > > > > > > Assuming there's a finite and known set of "supported" packages, listing > > > all of them as an explicit, exact (note: always "=") > > > > > > Obsoletes: %{name} = $v-$r > > > > well to make it catch older ones you'd need <= $v-$r > > > > and at that point wouldn't the package be obsoleting itself b/c of the > > version confusion? > > Yes. But as I said above, always "=". Not "<=" or anything else. > then you'll only catch that specific version - I can see that becoming sticky once you have to limp them along for multiple releases. -sv From ville.skytta at iki.fi Tue Jun 21 17:59:45 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 21 Jun 2005 20:59:45 +0300 Subject: [Fedora-packaging] Using self-Obsoletes instead of Epoch bumps? In-Reply-To: <1119375571.24920.24.camel@opus.phy.duke.edu> References: <1119369977.28867.166.camel@bobcat.mine.nu> <1119374869.24920.22.camel@opus.phy.duke.edu> <1119375536.28867.169.camel@bobcat.mine.nu> <1119375571.24920.24.camel@opus.phy.duke.edu> Message-ID: <1119376785.28867.185.camel@bobcat.mine.nu> On Tue, 2005-06-21 at 13:39 -0400, seth vidal wrote: > On Tue, 2005-06-21 at 20:38 +0300, Ville Skytt? wrote: > > On Tue, 2005-06-21 at 13:27 -0400, seth vidal wrote: > > > > > > and at that point wouldn't the package be obsoleting itself b/c of the > > > version confusion? > > > > Yes. But as I said above, always "=". Not "<=" or anything else. > > then you'll only catch that specific version - I can see that becoming > sticky once you have to limp them along for multiple releases. Multiple releases, yes, but not forever. If I understand "sticky" correctly in this context, that was also noted in my initial post. The question was whether the burden would be manageable and tolerable. To ease it a bit (but also limiting future options somewhat), dropping Release from the otherwise versioned Obsoletes would be possible in most cases. From skvidal at phy.duke.edu Tue Jun 21 18:04:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 21 Jun 2005 14:04:28 -0400 Subject: [Fedora-packaging] Using self-Obsoletes instead of Epoch bumps? In-Reply-To: <1119376785.28867.185.camel@bobcat.mine.nu> References: <1119369977.28867.166.camel@bobcat.mine.nu> <1119374869.24920.22.camel@opus.phy.duke.edu> <1119375536.28867.169.camel@bobcat.mine.nu> <1119375571.24920.24.camel@opus.phy.duke.edu> <1119376785.28867.185.camel@bobcat.mine.nu> Message-ID: <1119377068.24920.30.camel@opus.phy.duke.edu> On Tue, 2005-06-21 at 20:59 +0300, Ville Skytt? wrote: > On Tue, 2005-06-21 at 13:39 -0400, seth vidal wrote: > > On Tue, 2005-06-21 at 20:38 +0300, Ville Skytt? wrote: > > > On Tue, 2005-06-21 at 13:27 -0400, seth vidal wrote: > > > > > > > > and at that point wouldn't the package be obsoleting itself b/c of the > > > > version confusion? > > > > > > Yes. But as I said above, always "=". Not "<=" or anything else. > > > > then you'll only catch that specific version - I can see that becoming > > sticky once you have to limp them along for multiple releases. > > Multiple releases, yes, but not forever. If I understand "sticky" > correctly in this context, that was also noted in my initial post. The > question was whether the burden would be manageable and tolerable. To > ease it a bit (but also limiting future options somewhat), dropping > Release from the otherwise versioned Obsoletes would be possible in most > cases. Yah - I was just explaining I thought it would get 'sticky' -sv From mpeters at mac.com Sun Jun 26 05:10:00 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 25 Jun 2005 22:10:00 -0700 Subject: [Fedora-packaging] tetex packaging question Message-ID: <1119762607.21404.36.camel@locolhost.localdomain> I'm packaging a package for personal use at the moment, I don't think I'll be submitting it to Extras any time soon as it has some issues (see bottom), but I want to make sure my personal packaging is what would be expected if it were to be submitted. package is latex2rtf It is suppose to translate a latex package to rtf http://mpeters.us/testing/latex2rtf.spec http://mpeters.us/testing/latex2rtf-1.9.15.destdir.patch http://mpeters.us/testing/latex2rtf-1.9.15-0.1.src.rpm Packaging questions - upstream ctan is a zip archive, but unlike most ctan archives - this archive contains a bunch of archives within it, including the source tar.gz tarball I'm using for the package (and an older version). So what I did is referenced where the ctan archive came from in a comment, noting the source tarball is contained within. That seemed better to me than having prep do everything inside a zip archive full of stuff that wasn't going to be used. Secondly - I'm not using the tetex namespace. Since upstream has latex in the name already, and it isn't a package that you would call from within a tetex document, I didn't think that was necessary. Thirdly - the package in the Makefile wants to put its .cfg files in /usr/local/share/latex2rtf I'm instead putting them in /usr/share/texmf/tex/latex/latex2rtf Since it doesn't have any .sty files and isn't a package that a latex document would use, though, I'm not sure that that is the right thing to do. The reason I'm putting them there is because I wanted the documentation in texmf so that texdoc would find the documentation. Since it isn't a tetex package that other packages would use, is what I'm doing wrong? Thanks for comments. -=- The compile gives a LOT of warnings when compiled with $RPM_OPT_FLAGS - but it works OK. The tex file I'm trying it out on has some png images and some complex math equations (some inline, some not) - but was created in LyX and I think needs some cleaning, there's some latex warnings - the resulting rtf has some unwanted text at the beginning of all non inline complex equations as part of the image "Created using babel.pl from version 3.7 ..." and the document is missing the table of contents and a few other minor things, but I don't know how much of that is a problem with latex2rtf or how much of it is caused by LyX exporting to tex in a possibly less than ideal way - but I'll figure that out when I have cleaned up the latex ;) From mpeters at mac.com Sun Jun 26 06:56:27 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 25 Jun 2005 23:56:27 -0700 Subject: [Fedora-packaging] tetex packaging question In-Reply-To: <1119762607.21404.36.camel@locolhost.localdomain> References: <1119762607.21404.36.camel@locolhost.localdomain> Message-ID: <1119768988.21404.50.camel@locolhost.localdomain> On Sat, 2005-06-25 at 22:10 -0700, Michael A. Peters wrote: > > Thirdly - the package in the Makefile wants to put its .cfg files > in /usr/local/share/latex2rtf > I'm instead putting them in /usr/share/texmf/tex/latex/latex2rtf OK - that's clearly wrong, it causes latex to complain - so /usr/share is better. Interestingly - latex2rtf segfaults if gnuplot is involved (unless you just include the image) - so my interest in latex2rtf just decreased ... From symbiont at berlios.de Sun Jun 26 07:04:21 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sun, 26 Jun 2005 15:04:21 +0800 Subject: [Fedora-packaging] Using self-Obsoletes instead of Epoch bumps? In-Reply-To: <1119369977.28867.166.camel@bobcat.mine.nu> References: <1119369977.28867.166.camel@bobcat.mine.nu> Message-ID: <200506261504.21268.symbiont@berlios.de> On Wednesday 22 June 2005 00:06, Ville Skytt? wrote: > Has anyone ever experimented with or considered using self-Obsoletes > as an alternative to Epoch bumps using plain rpm CLI and various > depsolvers? I did this in Pyvault to get python15, python22, python23, python24 to Obsolete their python counterparts because of the existing implicit Obsoletes behavior. Saga documented here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130352 Listing out the Obsoletes for existing supported python versions aided in getting systems upgraded in the right way. Might not be exactly your situation (since the name changes), but it's been done! ;) take care, -- -jeff From bugs.michael at gmx.net Sun Jun 26 10:00:51 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Jun 2005 12:00:51 +0200 Subject: [Fedora-packaging] tetex packaging question In-Reply-To: <1119768988.21404.50.camel@locolhost.localdomain> References: <1119762607.21404.36.camel@locolhost.localdomain> <1119768988.21404.50.camel@locolhost.localdomain> Message-ID: <20050626120051.60bef819.bugs.michael@gmx.net> On Sat, 25 Jun 2005 23:56:27 -0700, Michael A. Peters wrote: > On Sat, 2005-06-25 at 22:10 -0700, Michael A. Peters wrote: > > > > > Thirdly - the package in the Makefile wants to put its .cfg files > > in /usr/local/share/latex2rtf > > I'm instead putting them in /usr/share/texmf/tex/latex/latex2rtf > > OK - that's clearly wrong, it causes latex to complain - so /usr/share > is better. > Interestingly - latex2rtf segfaults if gnuplot is involved (unless you > just include the image) - so my interest in latex2rtf just decreased ... ".cfg files"? Putting configuration files below /usr/share looks like a strange decision. If these are really configuration files which may be modified, they should go into some /etc directory rather than into a tree which may be mounted read-only and/or from the network. -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1383_FC5 loadavg: 1.14 1.21 1.41 From altblue at n0i.net Sun Jun 26 22:59:00 2005 From: altblue at n0i.net (Marius Feraru) Date: Mon, 27 Jun 2005 01:59:00 +0300 (EEST) Subject: [Fedora-packaging] %check script issues Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello folks. Current Packaging Guidelines [1] don't say anything about the %check script, so the only source of _documentation_ for now is the mere paragraph from Maximum RPM [2] which states: " This script's primary function is to run the test suite of the built software to ensure that the binaries work correctly. Some typical commands to run in this script are make test or make check. " Ok, nothing new for now, but there is one footnote [3] there: " One popular hack to make spec files containing the %check script work with RPM versions older than 4.2 roughly similarly as in newer versions is to include it immediately after the %install script in the spec file and append '|| :' to it, like: %check || : " Fedora Extras team (seeing provided template specs from fedora-rpmdevtools) and everybody in fact (reviewing prior discussions on the various Fedora related channels - mailing list, websites) seems to agree on this and already started using this procedure on some of the current packages in Fedora Core/Extras. The hack suggested in [3] ("%check || :" _after_ %install) and the testing done determined that this %check is done after %install (sort of "%__spec_install_post"). So, here come my issues: a) Maybe I really don't get it (reading [2] again and again), but it seems more appropiate to append this %check to %build (or even prepend it to %install), but I see no point for doing it _after_ %install. b) What is the "easy" way to disable %check? "--define 'check exit 0'" doesn't sound as "easy" as e.g. "--without check". Ok, b) is more like a rant or something, but a) bothers me a lot. Before knowing about this %check, I was adding a %{!?_without_test:make test} to the %build script and this seems good enough for me. Why should I "upgrade" to using this %check script? TIA. References: [1] http://fedoraproject.org/wiki/PackagingGuidelines [2] http://rpm.org/max-rpm-snapshot/s1-rpm-inside-scripts.html [3] http://rpm.org/max-rpm-snapshot/s1-rpm-inside-scripts.html#FTN.AEN8053 - -- Marius Feraru http://www.altblue.com/ "It isn't easy being the parent of a three-years-old. However, it's a pretty small price to pay for having somebody around the house who understands computers." -----BEGIN PGP SIGNATURE----- iD8DBQFCvzM3n0ZKufYp8iURAgwbAJ9vq/rGlUqL/iO+wOmtcqmg0F6uiACfTGFm 4v5UcwUaSoVvhiJtDq7FUUA= =3s5Z -----END PGP SIGNATURE----- From mpeters at mac.com Mon Jun 27 00:45:39 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 26 Jun 2005 17:45:39 -0700 Subject: [Fedora-packaging] tetex packaging question In-Reply-To: <20050626120051.60bef819.bugs.michael@gmx.net> References: <1119762607.21404.36.camel@locolhost.localdomain> <1119768988.21404.50.camel@locolhost.localdomain> <20050626120051.60bef819.bugs.michael@gmx.net> Message-ID: <1119833139.27880.2.camel@locolhost.localdomain> On Sun, 2005-06-26 at 12:00 +0200, Michael Schwendt wrote: > On Sat, 25 Jun 2005 23:56:27 -0700, Michael A. Peters wrote: > > > On Sat, 2005-06-25 at 22:10 -0700, Michael A. Peters wrote: > > > > > > > > Thirdly - the package in the Makefile wants to put its .cfg files > > > in /usr/local/share/latex2rtf > > > I'm instead putting them in /usr/share/texmf/tex/latex/latex2rtf > > > > OK - that's clearly wrong, it causes latex to complain - so /usr/share > > is better. > > Interestingly - latex2rtf segfaults if gnuplot is involved (unless you > > just include the image) - so my interest in latex2rtf just decreased ... > > ".cfg files"? Putting configuration files below /usr/share looks > like a strange decision. If these are really configuration files which > may be modified, they should go into some /etc directory rather than > into a tree which may be mounted read-only and/or from the network. > They look more like language support files to me - snippet of welsh.cfg # Created using babel.pl from version 3.7 of the Babel system # by Scott Prahl Tue Jul 3 22:26:17 2001 PREFACENAME,Rhagair. REFNAME,Cyfeiriadau. ABSTRACTNAME,Crynodeb. BIBNAME,Llyfryddiaeth. CHAPTERNAME,Pennod. etc. From ville.skytta at iki.fi Mon Jun 27 17:45:42 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 27 Jun 2005 20:45:42 +0300 Subject: [Fedora-packaging] %check script issues In-Reply-To: References: Message-ID: <1119894342.4656.42.camel@localhost.localdomain> On Mon, 2005-06-27 at 01:59 +0300, Marius Feraru wrote: > The hack suggested in [3] ("%check || :" _after_ %install) and the > testing done determined that this %check is done after %install (sort of > "%__spec_install_post"). > > So, here come my issues: > a) Maybe I really don't get it (reading [2] again and again), but it > seems more appropiate to append this %check to %build (or even prepend > it to %install), but I see no point for doing it _after_ %install. The Max-RPM hack suggests placing "%check || :" after %install, because that's the order rpmbuild >= 4.2 also runs the two in, no matter what their order is in the specfile. Off the cuff, I guess that the install-before-check order is because non-well-behaving test suites may modify/add/remove files in the build root which can affect what files get installed by the %install section. Which is obviously not acceptable. Can you come up with a generic case where running the test suite before doing the staged install would be useful? I cannot at the moment. > b) What is the "easy" way to disable %check? "--define 'check exit 0'" > doesn't sound as "easy" as e.g. "--without check". Right, but it doesn't have to be easy :) Just make it a habit to disable the test suite only when _absolutely_ necessary. In those rare cases, the --define way should not be too "hard", and keeps the specfile (very) slightly more readable. If a test suite of a package does or requires something that is not appropriate (taking into account all situations where it might be run in, generic/minimal build roots and personal workstations or desktops etc.), report a bug against the package. > Ok, b) is more like a rant or something, but a) bothers me a lot. Before > knowing about this %check, I was adding a %{!?_without_test:make test} > to the %build script and this seems good enough for me. Why should I > "upgrade" to using this %check script? Mileages vary, but I'd suggest at least running the test suite after %install, no matter what way you choose. Also, conditionalizing the build on a "--without test" or the like will obviously work only for that particular package, whereas "--define 'check exit 0'" should work for all packages that use %check, which are the majority already of ones that run test suites in the first place. Personally, I usually use the %check section just as is. In cases the test suite requires or does something inappropriate, I just write the "make test" and friends in the %check section, but comment them out along with a note stating why. Or add a "--with tests" flag that enables the test suite if it can be configured properly in the build root, but I don't remember ever adding a "--without tests" flag, nor using "--define 'check exit 0'", nor do I plan to do either :) From ivazquez at ivazquez.net Tue Jun 28 15:26:01 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 28 Jun 2005 11:26:01 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1119971087.9688.76.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> Message-ID: <1119972361.4427.59.camel@ignacio.ignacio.lan> On Tue, 2005-06-28 at 18:04 +0300, Ville Skytt? wrote: > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote: > > As an aside, I didn't think Extras was ready to tackle the issue of > > kernel module packages yet. > > Right, at least three issues remain: how to name the modules, how to > make depsolvers do the right thing with them, and how to request builds > for i586 and i686 from the build system for the same package. Screw i586 for now. As for naming, the kernel version needs to be stored *somewhere*. And we need to finalize the naming issue before we can decide what behavior depsolvers need. > But we should really fix the remaining issues with kernel module builds, > I'd like to get LIRC modules shipped too, and there may be other stuff > queued up from others. Anybody willing to (re)start or join this > discussion somewhere? fedora-packaging? Works for me. Here's my first submission: https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00965.html I've had to make a few changes for FC4, and I'll post those later today when I get a chance. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Jun 28 15:42:58 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 28 Jun 2005 18:42:58 +0300 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1119972361.4427.59.camel@ignacio.ignacio.lan> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> Message-ID: <1119973378.9688.109.camel@localhost.localdomain> On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-06-28 at 18:04 +0300, Ville Skytt? wrote: > > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote: > > > As an aside, I didn't think Extras was ready to tackle the issue of > > > kernel module packages yet. > > > > Right, at least three issues remain: how to name the modules, how to > > make depsolvers do the right thing with them, and how to request builds > > for i586 and i686 from the build system for the same package. > > Screw i586 for now. I'll screw it once the i586 kernel is screwed from FC :) Seriously, there are cases where i586 and external kernel modules are a valid scenario; for example I think a lot of HTPC/PVR boxes run some VIA CPUs that don't work with the i686 kernel, and having LIRC modules for their remote controls is kind of essential. But anyway, even in the hypothetical case that i586 would be ignored, I'm not 100% sure how to implement i686 build only for the ix86 family in the build system, while keeping in mind that the modules should probably be built for x86_64 and ppc too. %ifarch %{ix86} \ BuildArch: i686 \ %endif? > As for naming, the kernel version needs to be stored > *somewhere*. Dependencies, surely, but it does not _have_ to be in the package's NVR, as demonstrated by the external kernel module packages in FC4 (eg. GFS-kernel). Having it in the NVR somewhere is useful for humans, and it can be (ab?)used to get depsolvers to do "stuff". > And we need to finalize the naming issue before we can > decide what behavior depsolvers need. Possibly. From rc040203 at freenet.de Tue Jun 28 16:00:56 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Jun 2005 18:00:56 +0200 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1119973378.9688.109.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1119973378.9688.109.camel@localhost.localdomain> Message-ID: <1119974456.6288.89.camel@mccallum.corsepiu.local> On Tue, 2005-06-28 at 18:42 +0300, Ville Skytt? wrote: > On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote: > > On Tue, 2005-06-28 at 18:04 +0300, Ville Skytt? wrote: > > > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote: > > > > As an aside, I didn't think Extras was ready to tackle the issue of > > > > kernel module packages yet. > > > > > > Right, at least three issues remain: how to name the modules, how to > > > make depsolvers do the right thing with them, and how to request builds > > > for i586 and i686 from the build system for the same package. > > > > Screw i586 for now. > > I'll screw it once the i586 kernel is screwed from FC :) Seriously, > there are cases where i586 and external kernel modules are a valid > scenario; As architectures actually are switched outside of rpm-specs (rpmbuild --target=..) this isn't a packaging issue, but actually is a build system issue. I.e. the buildsystem has to be equipped with means to specify architectures, because rpm specs can't handle it. Ralf From ivazquez at ivazquez.net Tue Jun 28 16:35:14 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 28 Jun 2005 12:35:14 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1119974456.6288.89.camel@mccallum.corsepiu.local> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1119973378.9688.109.camel@localhost.localdomain> <1119974456.6288.89.camel@mccallum.corsepiu.local> Message-ID: <1119976514.4427.66.camel@ignacio.ignacio.lan> On Tue, 2005-06-28 at 18:00 +0200, Ralf Corsepius wrote: > On Tue, 2005-06-28 at 18:42 +0300, Ville Skytt? wrote: > > On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote: > > > On Tue, 2005-06-28 at 18:04 +0300, Ville Skytt? wrote: > > > > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote: > > > > > As an aside, I didn't think Extras was ready to tackle the issue of > > > > > kernel module packages yet. > > > > > > > > Right, at least three issues remain: how to name the modules, how to > > > > make depsolvers do the right thing with them, and how to request builds > > > > for i586 and i686 from the build system for the same package. > > > > > > Screw i586 for now. > > > > I'll screw it once the i586 kernel is screwed from FC :) Seriously, > > there are cases where i586 and external kernel modules are a valid > > scenario; > As architectures actually are switched outside of rpm-specs > (rpmbuild --target=..) this isn't a packaging issue, but actually is a > build system issue. > > I.e. the buildsystem has to be equipped with means to specify > architectures, because rpm specs can't handle it. It's also an rpmdb issue as you (or at least *I*) can't have kernel-devel.i586 and kernel-devel.i686 installed simultaneously even though there are no file conflicts between the packages. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 ivazquez at ivazquez.net Tue Jun 28 16:39:09 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 28 Jun 2005 12:39:09 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1119973378.9688.109.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1119973378.9688.109.camel@localhost.localdomain> Message-ID: <1119976750.4427.70.camel@ignacio.ignacio.lan> On Tue, 2005-06-28 at 18:42 +0300, Ville Skytt? wrote: > But anyway, even in the hypothetical case that i586 would be ignored, > I'm not 100% sure how to implement i686 build only for the ix86 family > in the build system, while keeping in mind that the modules should > probably be built for x86_64 and ppc too. %ifarch %{ix86} \ BuildArch: > i686 \ %endif? Clearly the kernel buildsystem (I can see this being separate from Plague, at least in the beginning) would have to be able to parse BuildArch properly in order to determine which archs it should be built for. It *may* be possible to leverage rpmlib for this, but I don't have time to look into it atm. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Jun 28 18:00:55 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 28 Jun 2005 21:00:55 +0300 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1119976750.4427.70.camel@ignacio.ignacio.lan> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1119973378.9688.109.camel@localhost.localdomain> <1119976750.4427.70.camel@ignacio.ignacio.lan> Message-ID: <1119981655.9688.134.camel@localhost.localdomain> On Tue, 2005-06-28 at 12:39 -0400, Ignacio Vazquez-Abrams wrote: > Clearly the kernel buildsystem (I can see this being separate from > Plague, at least in the beginning) And I can see _that_ happening sometime around FC-8 ;) AFAIK there's no absolute _need_ to have a separate buildsystem, not even because of the current impossibility to have both i586 and i686 kernel-devel for the same kernel installed at the same time. Just specify for example BuildRequires: kernel-devel-%{_target_cpu} = %{kernel} in the module specfile (where %{kernel} is the "uname -r" output for the target kernel, and the correct --target has been passed to the build), and let the depsolver do its job. There are no kernel-devel packages included in the default minimal build roots that could screw this up, right? If so, a simple (from the module packager POV, dunno about the buildsys side) extension to the current CVS target could be for example: make build ARCH="i586 i686 x86_64 ppc" This could be a useful feature for other packages than kernel module ones too, should we ever want to ship eg. something built for i686 in the i386 repo. From jjneely at pams.ncsu.edu Tue Jun 28 19:04:52 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Tue, 28 Jun 2005 15:04:52 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1119973378.9688.109.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1119973378.9688.109.camel@localhost.localdomain> Message-ID: <20050628190452.GU1972@anduril.pams.ncsu.edu> > > As for naming, the kernel version needs to be stored > > *somewhere*. > > Dependencies, surely, but it does not _have_ to be in the package's NVR, > as demonstrated by the external kernel module packages in FC4 (eg. > GFS-kernel). Having it in the NVR somewhere is useful for humans, and > it can be (ab?)used to get depsolvers to do "stuff". > Your kernel module should require the kernel it was built for. Its simple and already common practice. I already have depresolver code that examines the EVR of any Requires that are in the list of packages considered kernel packages. I strongly oppose having the kernel version/type in the packages NVR. The depresolver should be smart enough to know when to install kernel module packages and in what conditions to erase them. Kernel module packages are never upgraded. > > And we need to finalize the naming issue before we can > > decide what behavior depsolvers need. > I prefer the naming scheme of -kernel However the depresolver should not hinge off of a specific naming scheme. Kernel modules should Provide kernel-modules to trigger the extra functionality in the depresolver. Jack Neely -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jjneely at pams.ncsu.edu Tue Jun 28 19:09:42 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Tue, 28 Jun 2005 15:09:42 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1119976514.4427.66.camel@ignacio.ignacio.lan> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1119973378.9688.109.camel@localhost.localdomain> <1119974456.6288.89.camel@mccallum.corsepiu.local> <1119976514.4427.66.camel@ignacio.ignacio.lan> Message-ID: <20050628190942.GV1972@anduril.pams.ncsu.edu> On Tue, Jun 28, 2005 at 12:35:14PM -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-06-28 at 18:00 +0200, Ralf Corsepius wrote: > > On Tue, 2005-06-28 at 18:42 +0300, Ville Skytt? wrote: > > > On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote: > > > > On Tue, 2005-06-28 at 18:04 +0300, Ville Skytt? wrote: > > > > > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote: > > > > > > As an aside, I didn't think Extras was ready to tackle the issue of > > > > > > kernel module packages yet. > > > > > > > > > > Right, at least three issues remain: how to name the modules, how to > > > > > make depsolvers do the right thing with them, and how to request builds > > > > > for i586 and i686 from the build system for the same package. > > > > > > > > Screw i586 for now. > > > > > > I'll screw it once the i586 kernel is screwed from FC :) Seriously, > > > there are cases where i586 and external kernel modules are a valid > > > scenario; > > As architectures actually are switched outside of rpm-specs > > (rpmbuild --target=..) this isn't a packaging issue, but actually is a > > build system issue. > > > > I.e. the buildsystem has to be equipped with means to specify > > architectures, because rpm specs can't handle it. > > It's also an rpmdb issue as you (or at least *I*) can't have > kernel-devel.i586 and kernel-devel.i686 installed simultaneously even > though there are no file conflicts between the packages. > > -- > Ignacio Vazquez-Abrams > http://fedora.ivazquez.net/ > > gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 To me this is really a multilib issue. Multiple packages with the same name installed but built for different arches. The spec file needs to be able to require the kernel-devel packages of the same arch as the current build. Jack Neely > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From ville.skytta at iki.fi Tue Jun 28 19:35:56 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 28 Jun 2005 22:35:56 +0300 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050628190942.GV1972@anduril.pams.ncsu.edu> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1119973378.9688.109.camel@localhost.localdomain> <1119974456.6288.89.camel@mccallum.corsepiu.local> <1119976514.4427.66.camel@ignacio.ignacio.lan> <20050628190942.GV1972@anduril.pams.ncsu.edu> Message-ID: <1119987356.9688.204.camel@localhost.localdomain> On Tue, 2005-06-28 at 15:09 -0400, Jack Neely wrote: > The spec file needs to > be able to require the kernel-devel packages of the same arch as the > current build. Not a problem, one solution already mentioned in this thread: https://www.redhat.com/archives/fedora-packaging/2005-June/msg00020.html From altblue at n0i.net Tue Jun 28 19:52:47 2005 From: altblue at n0i.net (Marius Feraru) Date: Tue, 28 Jun 2005 22:52:47 +0300 (EEST) Subject: [Fedora-packaging] %check script issues In-Reply-To: <1119894342.4656.42.camel@localhost.localdomain> References: <1119894342.4656.42.camel@localhost.localdomain> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 27, at 20:45 (+0300), 'Ville Skytt?' wrote: > Can you come up with a generic case where running the test suite before > doing the staged install would be useful? I cannot at the moment. Hm, my mileage varies a lot on this, as I would rephrase it quite the opposite: what would be the generic cases where a staged install is necessary for running its test suite? I cannot at the moment :)) But anyway, I'll answer your question: perl modules (and obviously not only). Remember the adviced way of install a module: perl Makefile.PL make make test make install ^ as you see, "install" _after_ "test" I could bring you more examples (OFC, not perl related - mysql e.g.), but I'm sure it's not really necessary. Better - risking to repeat myself - I'll try to explain again my point/opinion: "%check" at the end of "%install" is GOOD. I argue that its current use is BAD, as in using it for "make test", which testing IMHO has nothing to do with the staged installation. Now, I'll explain (again) why this testing after install bothers me alot: because I cannot easily repeat testing, previously done with: rpmbuild -bc --short-circuit pkg.spec Using "make test" in "%check" nowadays just makes my delay (much) longer, as you surely know what a PITA currently are the various scripts run in _spec_install_* (e.g. the dependencies checking). So, for the last time, please don't understand me wrong - I'm not against the existence of a "check" script, but against the "policy" to use that block for "make test" & co. >> b) What is the "easy" way to disable %check? "--define 'check exit 0'" >> doesn't sound as "easy" as e.g. "--without check". > Right, but it doesn't have to be easy :) Sorry, I'm on a different side again, but I surely understand (and sometimes even agree) that enforced rules should more seldom drive into sloppy development comparing to systems/rules/policies promoting self discipline. Anyway, I'll stop here with this, I prefer not to get into advocacy stuff. > If a test suite of a package does or requires something that is not > appropriate (taking into account all situations where it might be run > in, generic/minimal build roots and personal workstations or desktops > etc.), report a bug against the package. Hm, as long as the packager provides clarifying BuildRequires, I see no problem with that. > Mileages vary, but I'd suggest at least running the test suite after > %install, no matter what way you choose. OK, I understand now that I failed explaining my premises in my previous message. I hope now you understood that I'm NOT trying to avoid testing, but just trying to ease packagers' jobs. cheers. - -- Marius Feraru http://www.altblue.com/ "It isn't easy being the parent of a three-years-old. However, it's a pretty small price to pay for having somebody around the house who understands computers." -----BEGIN PGP SIGNATURE----- iD8DBQFCwaqYn0ZKufYp8iURAnErAJ9h5yyr/OWOPs0DBS8/VH6O38Re2wCfcI7K 4znwPlVNUAX2KKr4VpMGdcY= =9yZg -----END PGP SIGNATURE----- From ville.skytta at iki.fi Tue Jun 28 21:21:00 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 29 Jun 2005 00:21:00 +0300 Subject: [Fedora-packaging] %check script issues In-Reply-To: References: <1119894342.4656.42.camel@localhost.localdomain> Message-ID: <1119993660.9688.273.camel@localhost.localdomain> On Tue, 2005-06-28 at 22:52 +0300, Marius Feraru wrote: > On Jun 27, at 20:45 (+0300), 'Ville Skytt' wrote: > > Can you come up with a generic case where running the test suite before > > doing the staged install would be useful? I cannot at the moment. > > Hm, my mileage varies a lot on this, as I would rephrase it quite the > opposite: what would be the generic cases where a staged install is > necessary for running its test suite? I cannot at the moment :)) It's not necessary nor does it really have anything directly to do with it. But in the vast majority of cases, the test suite must not affect what gets installed. I think running tests after the staged install is a cheap way to be almost certain that it doesn't happen, even if whatever does the staged install would be buggy as in "too lax wildcards", or if the test suite would be buggy as in "modifies/removes files to be installed" or the like. (Of course this assumes we're dealing with non-malicious software. If not, none of this matters anyway.) > But anyway, I'll answer your question: perl modules (and obviously not > only). Remember the adviced way of install a module: > perl Makefile.PL > make > make test > make install > ^ as you see, "install" _after_ "test" Sure, but that's different. In the above case, you're actually _installing_ stuff into their final runtime locations, not doing a staged install the results of which will be installed to their runtime environment later. The above advice applies well to the situation it documents ("how to install these modules"); not doing it that way would be shooting before asking. But it applies less well in packaging IMO. > Now, I'll explain (again) why this testing after install bothers me > alot: because I cannot easily repeat testing, previously done with: > rpmbuild -bc --short-circuit pkg.spec > Using "make test" in "%check" nowadays just makes my delay (much) longer, > as you surely know what a PITA currently are the various scripts run in > _spec_install_* (e.g. the dependencies checking). With %check blocks in use, you can work around that PITA if you want to stick with rpmbuild alone: rpmbuild -bi --short-circuit --define 'install exit 0' foo.spec Not quite as short as your example above, and may spew errors about unpackaged files, though. But doable. Another way would be to do a rpmbuild -bc, cd into the build root, and run the test suite manually. > I'm not > against the existence of a "check" script, but against the "policy" to > use that block for "make test" & co. What else would it be useful for? > > If a test suite of a package does or requires something that is not > > appropriate (taking into account all situations where it might be run > > in, generic/minimal build roots and personal workstations or desktops > > etc.), report a bug against the package. > > Hm, as long as the packager provides clarifying BuildRequires, I see no > problem with that. There are things that a packager may want to test locally but which cannot be specified as build dependencies, nor even completely written in the specfile by other means so that they would apply everywhere. For example, testing database drivers which require a running database and the configuration to access it, or test suites that require internet access, or stuff that can be only run as root, or need some files outside of the build root somewhere, or import GPG keys, to name a few I've seen. > > Mileages vary, but I'd suggest at least running the test suite after > > %install, no matter what way you choose. > > OK, I understand now that I failed explaining my premises in my previous > message. I hope now you understood that I'm NOT trying to avoid testing, > but just trying to ease packagers' jobs. Yep, got it. And I'm just another package monkey explaining one's understanding of the %check script/block, and opinions on running test suites as part of rpmbuild in general, FWIW. I'm slightly advocating %check over other "homebrew" solutions because the former is a standard part of rpmbuild which behaves in a certain predictable way (as such), which cannot be said of the latter without massive coordination efforts and agreements between packagers. Computers vs. packagers (humans, yuk :)) and their opinions, kind of. From tcallawa at redhat.com Wed Jun 29 00:40:52 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 28 Jun 2005 19:40:52 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1119972361.4427.59.camel@ignacio.ignacio.lan> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> Message-ID: <1120005652.2513.47.camel@localhost.localdomain> On Tue, 2005-06-28 at 11:26 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-06-28 at 18:04 +0300, Ville Skytt? wrote: > > On Tue, 2005-06-28 at 10:40 -0400, Jeff Spaleta wrote: > > > As an aside, I didn't think Extras was ready to tackle the issue of > > > kernel module packages yet. > > > > Right, at least three issues remain: how to name the modules, how to > > make depsolvers do the right thing with them, and how to request builds > > for i586 and i686 from the build system for the same package. > > Screw i586 for now. As for naming, the kernel version needs to be stored > *somewhere*. And we need to finalize the naming issue before we can > decide what behavior depsolvers need. Actually, no. I'm not going to standardize kernel module packaging _UNTIL_ at least yum is fixed. Let me reiterate some points that I have made in the past: - I do not plan to overload the %{name} value for kernel module packages. This means that we will NOT be shoving the kernel version in %{name}. Its ugly, it screws up bugzilla, breaks existing packaging guidelines, and is altogether wrong. - Given that, we WILL need to put the kernel version (in some part) in either %{version} or %{release}. Let me explain why: On SMP systems, at a bare minimum, there will be two kernels installed: kernel-smp-2.6.12-1.1400_FC5 kernel-2.6.12-1.1400_FC5 If we do not use kernel version in either %{version} or %{release}, we'll have no way to generate two packages with unique %{name}-%{version}-%{release} values. We have to assume that each installed kernel will want to have a matching module addon installed for it. I originally proposed (back in March) that we put the kernel version in Release. This is a slightly revised proposal. Name: kernel-module-openafs (where the value in the Name field is the name of the module, prepended with "kernel-module-") Version: 1.1 (where the value in the Version field is equivalent to the kernel module version, NOT the kernel version we're building against (in this example, "1", followed by the build revision, in this example ".1") Release: %{kver} (Where %{kver} is the kernel we're building against) Requires: kernel-%{_target_cpu} = %{kver} BuildRequires: kernel-devel-%{_target_cpu} = %{kver} %{kver} gets passed by the buildsystem, for each kernel found in the branch for which that package is being built. So, for our example kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp, respectively. FC4 and newer kernels have this value in the provides for "kernel-%{arch}", so it should not be too difficult for the build system to figure out the correct value for %{kver} from the target kernel package. There is no need to use dist tags here, since %{kver} includes the dist name. If a bugfix needs to be made to the package, then the .1 (build revision) is incremented. If a new version of the kernel driver is released, then the first part of the Version is incremented, and the build revision is reset to .1 (if it is not .1). So, after the buildsystem does its thing, we've generated two new binary rpms: kernel-module-openafs-1.1-2.6.12-1.1400_FC5.i686.rpm kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp.i686.rpm Since no previous packages with those n-v-r's exist, yum installs them, just as it would kernels, doing the equivalent of an rpm -i action. Now, on the system we have all four packages installed: kernel-2.6.12-1.1400_FC5 kernel-module-openafs-1.1-2.6.12-1.1400_FC5 kernel-smp-2.6.12-1.1400_FC5 kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp But wait, I've found a bug in kernel-module-openafs. Easy enough to fix, I patch it away, increment my build revision to .2, and we now have these new packages available: kernel-module-openafs-1.2-2.6.12-1.1400_FC5.i686.rpm kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp.i686.rpm But, here yum doesn't know what to do. We can't do a -i, those packages would conflict with the existing kernel-module-openafs packages. We can't do a -U, because then we'd only end up with one kernel-module-openafs package on the system. What we need yum to do is a special operation that does the following (only for kernel-module packages): - Does any kernel-module-openafs package exist on the system with the same %{release}? - If yes, remove it (rpm -e). If no, continue. - Install new package (rpm -i). After this process, the system has: kernel-2.6.12-1.1400_FC5 kernel-module-openafs-1.2-2.6.12-1.1400_FC5 kernel-smp-2.6.12-1.1400_FC5 kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp Now, if someone is willing and able to write the exception case needed for yum in kernel-module-* packages, then I think we can document the remaining standard bits, duct tape the necessary logic into the buildsystem, and start doing kernel-module-* packages for FC4 and devel. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Wed Jun 29 00:56:45 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 28 Jun 2005 20:56:45 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120005652.2513.47.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> Message-ID: <1120006605.4427.81.camel@ignacio.ignacio.lan> On Tue, 2005-06-28 at 19:40 -0500, Tom 'spot' Callaway wrote: > Version: 1.1 > (where the value in the Version field is equivalent to the kernel module > version, NOT the kernel version we're building against (in this example, > "1", followed by the build revision, in this example ".1") > If a bugfix needs to be made to the package, then the .1 (build > revision) is incremented. If a new version of the kernel driver is > released, then the first part of the Version is incremented, and the > build revision is reset to .1 (if it is not .1). Where do you propose that we put the version number of the module itself, if it's not an integer (e.g., 0.6.3)? Should we have 0.6.3.1 in that case? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Wed Jun 29 01:14:22 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 28 Jun 2005 20:14:22 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120006605.4427.81.camel@ignacio.ignacio.lan> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <1120006605.4427.81.camel@ignacio.ignacio.lan> Message-ID: <1120007662.2513.53.camel@localhost.localdomain> On Tue, 2005-06-28 at 20:56 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-06-28 at 19:40 -0500, Tom 'spot' Callaway wrote: > > Version: 1.1 > > (where the value in the Version field is equivalent to the kernel module > > version, NOT the kernel version we're building against (in this example, > > "1", followed by the build revision, in this example ".1") > > > If a bugfix needs to be made to the package, then the .1 (build > > revision) is incremented. If a new version of the kernel driver is > > released, then the first part of the Version is incremented, and the > > build revision is reset to .1 (if it is not .1). > > Where do you propose that we put the version number of the module > itself, if it's not an integer (e.g., 0.6.3)? Should we have 0.6.3.1 in > that case? Yes. If you need to use the version number of the module itself without a build revision, then we can use something like: Provides: kernel-module-openafs-version = 0.6.3 We could also standardize on a macro, something like %{modulever}, define it at the top, then use it throughout the spec file for clarity. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Wed Jun 29 01:24:39 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 28 Jun 2005 21:24:39 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120005652.2513.47.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> Message-ID: <20050629012439.GA16473@jadzia.bu.edu> On Tue, Jun 28, 2005 at 07:40:52PM -0500, Tom 'spot' Callaway wrote: > - I do not plan to overload the %{name} value for kernel module > packages. This means that we will NOT be shoving the kernel version in > %{name}. Its ugly, it screws up bugzilla, breaks existing packaging > guidelines, and is altogether wrong. Leaving everything else aside for a sec, this doesn't screw up bugzilla if you do it as a subpackage -- same way kernel and kernel-smp don't. [...] Oh wait, something else I want to comment on -- > Version: 1.1 > (where the value in the Version field is equivalent to the kernel module > version, NOT the kernel version we're building against (in this example, > "1", followed by the build revision, in this example ".1") Ouch -- this won't work. The .1 here will be very very confusing. For openafs 1.3.84, the _package_ release shouldn't be 1.3.84.1 or whatever -- it'll make it hard to match up to the actual source. I think this is *worse* than putting the version in the name. I think it's better to have this in the release: > Release: %{kver} > (Where %{kver} is the kernel we're building against) > Requires: kernel-%{_target_cpu} = %{kver} > BuildRequires: kernel-devel-%{_target_cpu} = %{kver} Release: %{realpackagerelease}.%{kver} 'cause hey, that's what the Release tag is supposed to be fore*. > %{kver} gets passed by the buildsystem, for each kernel found in the > branch for which that package is being built. So, for our example > kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp, Oh, there's another problem -- can't have a "-" in the release #. > respectively. FC4 and newer kernels have this value in the provides for > "kernel-%{arch}", so it should not be too difficult for the build system > to figure out the correct value for %{kver} from the target kernel > package. Passed in in a loop from the buildsystem? That seems decent. My only concern here is maybe particular to openafs -- the kernel module source isn't distributed separately from the other library/userspace/gunk. I guess I *could* make an openafs.src.rpm and a separate openafs-kernel.src.rpm both containing the same source tarball, but that seems kinda wrong. On the other hand, hey, maybe it isn't. [...] > kernel-module-openafs package on the system. What we need yum to do is a > special operation that does the following (only for kernel-module > packages): > > - Does any kernel-module-openafs package exist on the system with the > same %{release}? > - If yes, remove it (rpm -e). If no, continue. > - Install new package (rpm -i). Haven't thought this through completely, but there's one more factor too: kernel-module-openafs-1.3.84 will be required by the openafs-client package. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From mattdm at mattdm.org Wed Jun 29 01:27:31 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 28 Jun 2005 21:27:31 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120007662.2513.53.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <1120006605.4427.81.camel@ignacio.ignacio.lan> <1120007662.2513.53.camel@localhost.localdomain> Message-ID: <20050629012731.GB16473@jadzia.bu.edu> On Tue, Jun 28, 2005 at 08:14:22PM -0500, Tom 'spot' Callaway wrote: > Yes. If you need to use the version number of the module itself without > a build revision, then we can use something like: > Provides: kernel-module-openafs-version = 0.6.3 This seems yicky. What if we do this, and so we're providing kernel-module-openafs-version = 1.3.84, and then the upstream decides to do a bugfix release and call it 1.3.84.1? With your scheme, our old kernel module was *already* 1.3.84.1. Why *not* just put package release #s in the package release #? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From jjneely at pams.ncsu.edu Wed Jun 29 01:42:48 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Tue, 28 Jun 2005 21:42:48 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120005652.2513.47.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> Message-ID: <20050629014248.GC1972@anduril.pams.ncsu.edu> > Actually, no. I'm not going to standardize kernel module packaging > _UNTIL_ at least yum is fixed. > > Let me reiterate some points that I have made in the past: Good, gets us all back on track. :-) > > - I do not plan to overload the %{name} value for kernel module > packages. This means that we will NOT be shoving the kernel version in > %{name}. Its ugly, it screws up bugzilla, breaks existing packaging > guidelines, and is altogether wrong. > > - Given that, we WILL need to put the kernel version (in some part) in > either %{version} or %{release}. Let me explain why: > I can tolerate %{release} > On SMP systems, at a bare minimum, there will be two kernels installed: > > kernel-smp-2.6.12-1.1400_FC5 > kernel-2.6.12-1.1400_FC5 > > If we do not use kernel version in either %{version} or %{release}, > we'll have no way to generate two packages with unique > %{name}-%{version}-%{release} values. > > We have to assume that each installed kernel will want to have a > matching module addon installed for it. > > I originally proposed (back in March) that we put the kernel version in > Release. This is a slightly revised proposal. > > Name: kernel-module-openafs > (where the value in the Name field is the name of the module, prepended > with "kernel-module-") > Version: 1.1 > (where the value in the Version field is equivalent to the kernel module > version, NOT the kernel version we're building against (in this example, > "1", followed by the build revision, in this example ".1") So %{version} ends up having the upstream version number and the release number combined. I think this is the worst part as its confusing to the packager. Why I advocate requiring %{kver}. However, I did not propose a solution for a unique NVR for eatch kernel type (smp, xen, etc). > Release: %{kver} > (Where %{kver} is the kernel we're building against) > Requires: kernel-%{_target_cpu} = %{kver} > BuildRequires: kernel-devel-%{_target_cpu} = %{kver} > > %{kver} gets passed by the buildsystem, for each kernel found in the > branch for which that package is being built. So, for our example > kernels, %{kver} would be 2.6.12-1.1400_FC5 and 2.6.12-1.1400_FC5smp, > respectively. FC4 and newer kernels have this value in the provides for > "kernel-%{arch}", so it should not be too difficult for the build system > to figure out the correct value for %{kver} from the target kernel > package. > > There is no need to use dist tags here, since %{kver} includes the dist > name. > > If a bugfix needs to be made to the package, then the .1 (build > revision) is incremented. If a new version of the kernel driver is > released, then the first part of the Version is incremented, and the > build revision is reset to .1 (if it is not .1). > > So, after the buildsystem does its thing, we've generated two new binary > rpms: > > kernel-module-openafs-1.1-2.6.12-1.1400_FC5.i686.rpm > kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp.i686.rpm > > Since no previous packages with those n-v-r's exist, yum installs them, > just as it would kernels, doing the equivalent of an rpm -i action. > > Now, on the system we have all four packages installed: > > kernel-2.6.12-1.1400_FC5 > kernel-module-openafs-1.1-2.6.12-1.1400_FC5 > kernel-smp-2.6.12-1.1400_FC5 > kernel-module-openafs-1.1-2.6.12-1.1400_FC5smp > > But wait, I've found a bug in kernel-module-openafs. Easy enough to fix, > I patch it away, increment my build revision to .2, and we now have > these new packages available: > > kernel-module-openafs-1.2-2.6.12-1.1400_FC5.i686.rpm > kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp.i686.rpm > > But, here yum doesn't know what to do. We can't do a -i, those packages > would conflict with the existing kernel-module-openafs packages. We > can't do a -U, because then we'd only end up with one > kernel-module-openafs package on the system. What we need yum to do is a > special operation that does the following (only for kernel-module > packages): > > - Does any kernel-module-openafs package exist on the system with the > same %{release}? > - If yes, remove it (rpm -e). If no, continue. > - Install new package (rpm -i). > I have a patch for yum that does exactly this except it keys off of the kernel requires. (Does kernel-module-openafs-1.1-2.6.12-1.1400_FC5 require the same kernel as kernel-module-openafs-1.2-2.6.12-1.1400_FC5?) So in a day or two I could probably have it edited to do the above. > After this process, the system has: > > kernel-2.6.12-1.1400_FC5 > kernel-module-openafs-1.2-2.6.12-1.1400_FC5 > kernel-smp-2.6.12-1.1400_FC5 > kernel-module-openafs-1.2-2.6.12-1.1400_FC5smp > > Now, if someone is willing and able to write the exception case needed > for yum in kernel-module-* packages, then I think we can document the > remaining standard bits, duct tape the necessary logic into the > buildsystem, and start doing kernel-module-* packages for FC4 and devel. > Since I already have a good bit of the code done... Spot, the only change I would like in this is to have the build number not in %{version} but as part of %{release}. So using your example, kernel-module-openafs-1-2.2.6.12-1.1400_FC5 Where the %{release} == build#.%{kver} This doesn't add or subtract any complexity from the code in Yum. It does make the versioning a little easier to grok. Reading the new mail I got as I wrote this it looks like Matthew and I agree. Cool. Jack > ~spot > -- > Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From skvidal at phy.duke.edu Wed Jun 29 03:11:15 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 28 Jun 2005 23:11:15 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120005652.2513.47.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> Message-ID: <1120014675.6824.5.camel@cutter> > Actually, no. I'm not going to standardize kernel module packaging > _UNTIL_ at least yum is fixed. You realize how backward this is, right? 'Fixing' yum is quite hard until the kernel module packaging is standardized. Implementing a single policy is a whole lot easier than coding to meet every possible policy. -sv From ivazquez at ivazquez.net Wed Jun 29 11:09:15 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 29 Jun 2005 07:09:15 -0400 Subject: [Fedora-packaging] Kernel modules In-Reply-To: <1119972361.4427.59.camel@ignacio.ignacio.lan> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> Message-ID: <1120043355.18405.3.camel@ignacio.ignacio.lan> I've taken the liberty of starting a page at http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is intended to be a collection of what we have so far. Judging from what has been said to date we still don't have an effective scheme for Version and Release. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Wed Jun 29 13:38:45 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 29 Jun 2005 08:38:45 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050629012439.GA16473@jadzia.bu.edu> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> Message-ID: <1120052325.2513.75.camel@localhost.localdomain> On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote: > On Tue, Jun 28, 2005 at 07:40:52PM -0500, Tom 'spot' Callaway wrote: > > - I do not plan to overload the %{name} value for kernel module > > packages. This means that we will NOT be shoving the kernel version in > > %{name}. Its ugly, it screws up bugzilla, breaks existing packaging > > guidelines, and is altogether wrong. > > Leaving everything else aside for a sec, this doesn't screw up bugzilla if > you do it as a subpackage -- same way kernel and kernel-smp don't. I think we have to assume that there will be some kernel-module packages that just consist of drivers, with no extra user space addons. > I think it's better to have this in the release: > > > Release: %{kver} > > (Where %{kver} is the kernel we're building against) > > Requires: kernel-%{_target_cpu} = %{kver} > > BuildRequires: kernel-devel-%{_target_cpu} = %{kver} > > > Release: %{realpackagerelease}.%{kver} OK, so lets say we do this. In this case, we have %{kver} in %{release} to keep %{release} unique (and thus, have unique NVR). However, we can no longer just use %{release} as our check variable in yum. In this scenario, we need to instead make yum check some sort of "magic" provides that only kernel-module packages will have (not as much of a hack as might be thought). In the spec, we put: Provides: kernel-module-openafs-kver = %{kver} Basically, to modify my original yum logic path: - Does any kernel-module-openafs package exist on the system with the same kernel-module-openafs-kver? - If yes, remove it (rpm -e). If no, continue. - Install new package (rpm -i). > Oh, there's another problem -- can't have a "-" in the release #. %define cleankver %(echo %{kver} | sed s,-,_,g) > My only concern here is maybe particular to openafs -- the kernel module > source isn't distributed separately from the other library/userspace/gunk. I > guess I *could* make an openafs.src.rpm and a separate > openafs-kernel.src.rpm both containing the same source tarball, but that > seems kinda wrong. On the other hand, hey, maybe it isn't. Or you could make the userspace gunk in a subpackage. No reason that kernel-module-openafs can't generate both kernel-module-openafs and openafs packages. You can override the version and release for the openafs package. > Haven't thought this through completely, but there's one more factor too: > kernel-module-openafs-1.3.84 will be required by the openafs-client package. Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps the remove, knowing that the install is coming right afterward. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 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 phy.duke.edu Wed Jun 29 13:41:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 29 Jun 2005 09:41:51 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120052325.2513.75.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> Message-ID: <1120052511.10448.6.camel@cutter> > > Haven't thought this through completely, but there's one more factor too: > > kernel-module-openafs-1.3.84 will be required by the openafs-client package. > > Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps > the remove, knowing that the install is coming right afterward. umm, what? no we won't. we're not adding --nodeps or that tsflag into yum. -sv From tcallawa at redhat.com Wed Jun 29 13:42:10 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 29 Jun 2005 08:42:10 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120052325.2513.75.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> Message-ID: <1120052530.2513.79.camel@localhost.localdomain> On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote: > > > Requires: kernel-%{_target_cpu} = %{kver} > In the spec, we put: > > Provides: kernel-module-openafs-kver = %{kver} Or, we just leave that nonsense out and key off the Requires: kernel-%{_target_cpu} So, once more: - Does any kernel-module-openafs package exist on the system that requires the same kernel-%{_target_cpu} = %{kver} as me? - If yes, remove it (rpm -e --nodeps). If no, continue. - Install new package (rpm -i) I suspect this is very close to Jack's existing patch. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 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 phy.duke.edu Wed Jun 29 13:44:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 29 Jun 2005 09:44:14 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120052530.2513.79.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120052530.2513.79.camel@localhost.localdomain> Message-ID: <1120052654.10448.10.camel@cutter> On Wed, 2005-06-29 at 08:42 -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote: > > > > > Requires: kernel-%{_target_cpu} = %{kver} > > > In the spec, we put: > > > > Provides: kernel-module-openafs-kver = %{kver} > > Or, we just leave that nonsense out and key off the Requires: > kernel-%{_target_cpu} > > So, once more: > - Does any kernel-module-openafs package exist on the system that > requires the same kernel-%{_target_cpu} = %{kver} as me? > - If yes, remove it (rpm -e --nodeps). If no, continue. > - Install new package (rpm -i) > > I suspect this is very close to Jack's existing patch. I suspect that were NOT adding --nodeps. no matter what. think again if you think we are. -sv From tcallawa at redhat.com Wed Jun 29 13:48:11 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 29 Jun 2005 08:48:11 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120052325.2513.75.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> Message-ID: <1120052891.2513.82.camel@localhost.localdomain> On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote: > Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps > the remove, knowing that the install is coming right afterward. In fact, its not even a problem. skvidal> it's a simultaneous transaction skvidal> if bar (installed) requires foo skvidal> and you're removing baz (provides foo) skvidal> and installing quux(provides foo) skvidal> and it is all in one transaction then there are no broken dependencies spot> ok. :) then its a non issue. skvidal> there's no need for --nodeps skvidal> right but I feel it is a necessity to smack any discussion of --nodeps at all times :) Consider me duly smacked. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jjneely at pams.ncsu.edu Wed Jun 29 13:59:30 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 29 Jun 2005 09:59:30 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120052530.2513.79.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120052530.2513.79.camel@localhost.localdomain> Message-ID: <20050629135930.GD1972@anduril.pams.ncsu.edu> On Wed, Jun 29, 2005 at 08:42:10AM -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote: > > > > > Requires: kernel-%{_target_cpu} = %{kver} > > > In the spec, we put: > > > > Provides: kernel-module-openafs-kver = %{kver} > > Or, we just leave that nonsense out and key off the Requires: > kernel-%{_target_cpu} > > So, once more: > - Does any kernel-module-openafs package exist on the system that > requires the same kernel-%{_target_cpu} = %{kver} as me? > - If yes, remove it (rpm -e --nodeps). If no, continue. > - Install new package (rpm -i) > > I suspect this is very close to Jack's existing patch. Very. I'm missing a detail or two but I'll get that out tonight. Jack > > ~spot > -- > Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jjneely at pams.ncsu.edu Wed Jun 29 14:03:57 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 29 Jun 2005 10:03:57 -0400 Subject: [Fedora-packaging] Kernel modules In-Reply-To: <1120043355.18405.3.camel@ignacio.ignacio.lan> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120043355.18405.3.camel@ignacio.ignacio.lan> Message-ID: <20050629140357.GE1972@anduril.pams.ncsu.edu> On Wed, Jun 29, 2005 at 07:09:15AM -0400, Ignacio Vazquez-Abrams wrote: > I've taken the liberty of starting a page at > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is > intended to be a collection of what we have so far. Judging from what > has been said to date we still don't have an effective scheme for > Version and Release. > > -- > Ignacio Vazquez-Abrams > http://fedora.ivazquez.net/ > > gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 %{version} and %{release} being what they would normally be is what we've boiled down to. Neither one contains the kernel VR. %{version} is the version of the kernel module ('1.3.84' for kernel-module-openafs) and %{release} being the build ID ('1'), per normal. Spot, I think keying off the requires works very well. Jack > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From tcallawa at redhat.com Wed Jun 29 14:19:02 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 29 Jun 2005 09:19:02 -0500 Subject: [Fedora-packaging] Kernel modules In-Reply-To: <20050629140357.GE1972@anduril.pams.ncsu.edu> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120043355.18405.3.camel@ignacio.ignacio.lan> <20050629140357.GE1972@anduril.pams.ncsu.edu> Message-ID: <1120054742.2513.85.camel@localhost.localdomain> On Wed, 2005-06-29 at 10:03 -0400, Jack Neely wrote: > On Wed, Jun 29, 2005 at 07:09:15AM -0400, Ignacio Vazquez-Abrams wrote: > > I've taken the liberty of starting a page at > > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is > > intended to be a collection of what we have so far. Judging from what > > has been said to date we still don't have an effective scheme for > > Version and Release. > > > > -- > > Ignacio Vazquez-Abrams > > http://fedora.ivazquez.net/ > > > > gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 > > %{version} and %{release} being what they would normally be is what > we've boiled down to. Neither one contains the kernel VR. %{version} > is the version of the kernel module ('1.3.84' for kernel-module-openafs) > and %{release} being the build ID ('1'), per normal. We really need a unique NVR for each package. Using kver in %{release} is the best way to accomplish this. Otherwise, we overwrite in the repo. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jjneely at pams.ncsu.edu Wed Jun 29 14:19:39 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 29 Jun 2005 10:19:39 -0400 Subject: [Fedora-packaging] Kernel modules In-Reply-To: <20050629140357.GE1972@anduril.pams.ncsu.edu> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120043355.18405.3.camel@ignacio.ignacio.lan> <20050629140357.GE1972@anduril.pams.ncsu.edu> Message-ID: <20050629141939.GF1972@anduril.pams.ncsu.edu> On Wed, Jun 29, 2005 at 10:03:57AM -0400, Jack Neely wrote: > On Wed, Jun 29, 2005 at 07:09:15AM -0400, Ignacio Vazquez-Abrams wrote: > > I've taken the liberty of starting a page at > > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal which is > > intended to be a collection of what we have so far. Judging from what > > has been said to date we still don't have an effective scheme for > > Version and Release. > > > > -- > > Ignacio Vazquez-Abrams > > http://fedora.ivazquez.net/ > > > > gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 > > %{version} and %{release} being what they would normally be is what > we've boiled down to. Neither one contains the kernel VR. %{version} > is the version of the kernel module ('1.3.84' for kernel-module-openafs) > and %{release} being the build ID ('1'), per normal. > > Spot, I think keying off the requires works very well. > > Jack > > Its obviously too early in the morning. Ignacio, I must correct myself. The kernel VR should be appened to the %{release} tag for the packages. -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From mattdm at mattdm.org Wed Jun 29 14:24:59 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Jun 2005 10:24:59 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120052325.2513.75.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> Message-ID: <20050629142459.GA11611@jadzia.bu.edu> On Wed, Jun 29, 2005 at 08:38:45AM -0500, Tom 'spot' Callaway wrote: > > Leaving everything else aside for a sec, this doesn't screw up bugzilla if > > you do it as a subpackage -- same way kernel and kernel-smp don't. > I think we have to assume that there will be some kernel-module packages > that just consist of drivers, with no extra user space addons. That can work too -- look at the pump RPM, which only generates subpackages with different names. But I only think this is preferable to putting the package release number in the version -- my preferences is for kernel and package release number to both go in the release. > > Release: %{realpackagerelease}.%{kver} > OK, so lets say we do this. > In this case, we have %{kver} in %{release} to keep %{release} unique > (and thus, have unique NVR). However, we can no longer just use > %{release} as our check variable in yum. In this scenario, we need to Right -- anything that wants to do something smart with these packages will have to be smart about it. I think it's better to require whatever smartness in as few places as possible, even at the price of requiring more of it in those places. Redefining what 'version' means to mean "somes the upstream version, sometimes some numbers we made up" seems a lot worse in general. And, the "cleanver" thing to get rid of the '-' already requires some parsing. As much as I hate _ in package names, we could do: Release: %{realpackagerelease}_%{cleankver} or maybe Release: %{realpackagerelease}.kver%{cleankver} (Ugh, very long and ugly, though.) > instead make yum check some sort of "magic" provides that only > kernel-module packages will have (not as much of a hack as might be > thought). The more I think about this (Jack's) approach, the more I feel okay about it. Maybe it's contagious. :) [...] > > My only concern here is maybe particular to openafs -- the kernel module > > source isn't distributed separately from the other library/userspace/gunk. I > > guess I *could* make an openafs.src.rpm and a separate > > openafs-kernel.src.rpm both containing the same source tarball, but that > > seems kinda wrong. On the other hand, hey, maybe it isn't. > Or you could make the userspace gunk in a subpackage. No reason that > kernel-module-openafs can't generate both kernel-module-openafs and > openafs packages. That seems backwards. Right now, the kernel modules are a subpackage of the openafs package -- making the package kernel-module-openafs seems like putting the cart before the horse. (Why would openafs-server be a subpackage of that, for example?) > You can override the version and release for the openafs package. Except, if we're building for five different kernels, each of those would then generate the identical openafs-server, openafs-client, and openafs packages. At the very least, that's a lot of wasted CPU. > > Haven't thought this through completely, but there's one more factor > > too: kernel-module-openafs-1.3.84 will be required by the openafs-client > > package. > Shouldn't be a problem. We'll just pretend we're anaconda and --nodeps > the remove, knowing that the install is coming right afterward. Ow, must we? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From ville.skytta at iki.fi Wed Jun 29 14:31:31 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 29 Jun 2005 17:31:31 +0300 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120052325.2513.75.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> Message-ID: <1120055491.9688.330.camel@localhost.localdomain> On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote: > On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote: > > > > Leaving everything else aside for a sec, this doesn't screw up bugzilla if > > you do it as a subpackage -- same way kernel and kernel-smp don't. > > I think we have to assume that there will be some kernel-module packages > that just consist of drivers, with no extra user space addons. Just for the record as we don't seem to be needing this stuff: does not matter, those could be implemented so that the SRPM would produce _only_ one binary "subpackage". > > My only concern here is maybe particular to openafs -- the kernel module > > source isn't distributed separately from the other library/userspace/gunk. I > > guess I *could* make an openafs.src.rpm and a separate > > openafs-kernel.src.rpm both containing the same source tarball, but that > > seems kinda wrong. On the other hand, hey, maybe it isn't. > > Or you could make the userspace gunk in a subpackage. No reason that > kernel-module-openafs can't generate both kernel-module-openafs and > openafs packages. What about archs? We probably don't want i586 and i686 userland openafs stuff, but just i386. Choices: 1) Just ship userland as i586 and i686 too 2) Split userland and module SRPMS 3) Conditionalize whether to build the modules or the userland or both based on some passed in build options (rpm.livna.org uses "--without modules" and "--without userland") 4) Hardcode our assumptions based on arch somewhere, eg. if target=i586 or i686, no userland will be built, and if target=i386, no modules will be built 2) gets my vote. From mattdm at mattdm.org Wed Jun 29 14:39:38 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Jun 2005 10:39:38 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120052891.2513.82.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120052891.2513.82.camel@localhost.localdomain> Message-ID: <20050629143938.GB11611@jadzia.bu.edu> On Wed, Jun 29, 2005 at 08:48:11AM -0500, Tom 'spot' Callaway wrote: > skvidal> and installing quux(provides foo) > skvidal> and it is all in one transaction then there are no broken dependencies > spot> ok. :) then its a non issue. > skvidal> there's no need for --nodeps Okay, just to get this all concrete for me.... On the system, we've got: kernel-2.6.11-1.27_FC3 kernel-2.6.11-1.35_FC3 kernel-smp-2.6.11-1.27_FC3 kernel-smp-2.6.11-1.35_FC3 openafs-1.3.84-1 openafs-client-1.3.84-1 kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3smp kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3smp If we add a new kernel, say: kernel-2.6.11-1.40_FC3 kernel-smp-2.6.11-1.40_FC3 Okay, the Magic makes the depsolver pull in kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3smp and we're all good. Okay, but now say there's an updated openafs-1.3.85. So we've got to figure out that: kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3 -> 1.3.85-1_2.6.11-1.27_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3 -> 1.3.85-1_2.6.11-1.35_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3 -> 1.3.85-1_2.6.11-1.40_FC3 (plus smp) And to complicate things, you also have the potential to have to deal with kernel-module-openafs-1.3.84-1_2.6.11-1.27_FC3 -> 1.3.85-2_2.6.11-1.27_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.35_FC3 -> 1.3.85-2_2.6.11-1.35_FC3 kernel-module-openafs-1.3.84-1_2.6.11-1.40_FC3 -> 1.3.85-2_2.6.11-1.40_FC3 and kernel-module-openafs-1.3.85-1_2.6.11-1.27_FC3 -> 1.3.85-2_2.6.11-1.27_FC3 kernel-module-openafs-1.3.85-1_2.6.11-1.35_FC3 -> 1.3.85-2_2.6.11-1.35_FC3 kernel-module-openafs-1.3.85-1_2.6.11-1.40_FC3 -> 1.3.85-2_2.6.11-1.40_FC3 . Maybe this'll all work, but, gah. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From mattdm at mattdm.org Wed Jun 29 14:50:33 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Jun 2005 10:50:33 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120055491.9688.330.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> Message-ID: <20050629145033.GC11611@jadzia.bu.edu> On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skytt? wrote: > 1) Just ship userland as i586 and i686 too > 2) Split userland and module SRPMS > 3) Conditionalize whether to build the modules or the userland or both > based on some passed in build options > (rpm.livna.org uses "--without modules" and "--without userland") > 4) Hardcode our assumptions based on arch somewhere, eg. if target=i586 > or i686, no userland will be built, and if target=i386, no modules > will be built > > 2) gets my vote. For 4), remember that we've also got smp (and in CentOS 4, which I'd also like to support, hugemem). #2 has some appeal, particularly since it avoids rebuilding the userland stuff for every kernel update, but it requires some careful consideration about the dependency relationship between the userland and module packages.... (I've been assuming a requires version-release kind of thing, but on reflection, that'd be *hard* and generally *not* wanted -- but then, in the cases where it *is* wanted, not possible. Gah.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From jjneely at pams.ncsu.edu Wed Jun 29 14:58:27 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 29 Jun 2005 10:58:27 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120055491.9688.330.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> Message-ID: <20050629145827.GG1972@anduril.pams.ncsu.edu> On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skytt? wrote: > On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote: > > On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote: > > > > > > Leaving everything else aside for a sec, this doesn't screw up bugzilla if > > > you do it as a subpackage -- same way kernel and kernel-smp don't. > > > > I think we have to assume that there will be some kernel-module packages > > that just consist of drivers, with no extra user space addons. > > Just for the record as we don't seem to be needing this stuff: does not > matter, those could be implemented so that the SRPM would produce _only_ > one binary "subpackage". > One spec file can produce packages like the following IIRC: openafs-V-R openafs-client-V-R kernel-module-openafs-V-R.%{cleankver} openafs-devel-V-R > > > My only concern here is maybe particular to openafs -- the kernel module > > > source isn't distributed separately from the other library/userspace/gunk. I > > > guess I *could* make an openafs.src.rpm and a separate > > > openafs-kernel.src.rpm both containing the same source tarball, but that > > > seems kinda wrong. On the other hand, hey, maybe it isn't. > > > > Or you could make the userspace gunk in a subpackage. No reason that > > kernel-module-openafs can't generate both kernel-module-openafs and > > openafs packages. > > What about archs? We probably don't want i586 and i686 userland openafs > stuff, but just i386. Choices: > > 1) Just ship userland as i586 and i686 too > 2) Split userland and module SRPMS > 3) Conditionalize whether to build the modules or the userland or both > based on some passed in build options > (rpm.livna.org uses "--without modules" and "--without userland") > 4) Hardcode our assumptions based on arch somewhere, eg. if target=i586 > or i686, no userland will be built, and if target=i386, no modules > will be built My openafs packages only build the userland packages if the current arch you are building for is a basearch. Conversely, it does not build a kernel module for the i386 arch. Yes *sigh* my spec has a list of basearchs hard coded in. This makes the most since, however it would be nice for RPM to provide basearch information rather than hard coding it. > > 2) gets my vote. Beleive me. This is very yucky. You really don't want to. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From ivazquez at ivazquez.net Wed Jun 29 15:07:56 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 29 Jun 2005 11:07:56 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050629145827.GG1972@anduril.pams.ncsu.edu> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> Message-ID: <1120057676.1864.2.camel@ignacio.ignacio.lan> On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote: > On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skytt? wrote: > > On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote: > > > On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote: > > > > > > > > Leaving everything else aside for a sec, this doesn't screw up bugzilla if > > > > you do it as a subpackage -- same way kernel and kernel-smp don't. > > > > > > I think we have to assume that there will be some kernel-module packages > > > that just consist of drivers, with no extra user space addons. > > > > Just for the record as we don't seem to be needing this stuff: does not > > matter, those could be implemented so that the SRPM would produce _only_ > > one binary "subpackage". > > > > One spec file can produce packages like the following IIRC: > > openafs-V-R > openafs-client-V-R > kernel-module-openafs-V-R.%{cleankver} > openafs-devel-V-R Indeed. Just give the subpackage its own Release tag. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Jun 29 15:20:08 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 29 Jun 2005 18:20:08 +0300 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050629145827.GG1972@anduril.pams.ncsu.edu> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> Message-ID: <1120058408.9688.346.camel@localhost.localdomain> On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote: > On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skytt? wrote: > > What about archs? We probably don't want i586 and i686 userland openafs > > stuff, but just i386. Choices: > > Hm, actually, I don't know a thing about openafs, just used it as an example. s/openafs/foo/ in the above. > My openafs packages only build the userland packages if the current arch > you are building for is a basearch. Conversely, it does not build a > kernel module for the i386 arch. What's a basearch, the same as in yum/rpmUtils? If x86_64 or ppc is one, does your package build modules for it? From tcallawa at redhat.com Wed Jun 29 15:35:06 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 29 Jun 2005 10:35:06 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120057676.1864.2.camel@ignacio.ignacio.lan> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> Message-ID: <1120059306.2513.112.camel@localhost.localdomain> On Wed, 2005-06-29 at 11:07 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote: > > On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skytt? wrote: > > > On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote: > > > > On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote: > > > > > > > > > > Leaving everything else aside for a sec, this doesn't screw up bugzilla if > > > > > you do it as a subpackage -- same way kernel and kernel-smp don't. > > > > > > > > I think we have to assume that there will be some kernel-module packages > > > > that just consist of drivers, with no extra user space addons. > > > > > > Just for the record as we don't seem to be needing this stuff: does not > > > matter, those could be implemented so that the SRPM would produce _only_ > > > one binary "subpackage". > > > > > > > One spec file can produce packages like the following IIRC: > > > > openafs-V-R > > openafs-client-V-R > > kernel-module-openafs-V-R.%{cleankver} > > openafs-devel-V-R > > Indeed. Just give the subpackage its own Release tag. I honestly don't care which is the base and which is the subpackage. The biggest issue I see is with arch determination, since they HAVE to be the same between base and subpackage. The userland package should only have the userland arch (i386, sparc, ia64, ppc, x86_64), whereas the kernel-module package needs to exist for all of these arches (i386, i586, i686, ia64, ppc, ppc64, sparc, sparc64, x86_64). I think that overcoming this obstacle may require that the two packages be built from separate SRPMS. As always, I'm open to suggestions. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Wed Jun 29 16:23:26 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 29 Jun 2005 18:23:26 +0200 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120059306.2513.112.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> Message-ID: <1120062206.6288.113.camel@mccallum.corsepiu.local> On Wed, 2005-06-29 at 10:35 -0500, Tom 'spot' Callaway wrote: > On Wed, 2005-06-29 at 11:07 -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2005-06-29 at 10:58 -0400, Jack Neely wrote: > > > On Wed, Jun 29, 2005 at 05:31:31PM +0300, Ville Skytt? wrote: > > > > On Wed, 2005-06-29 at 08:38 -0500, Tom 'spot' Callaway wrote: > > > > > On Tue, 2005-06-28 at 21:24 -0400, Matthew Miller wrote: > > > > > > > > > > > > Leaving everything else aside for a sec, this doesn't screw up bugzilla if > > > > > > you do it as a subpackage -- same way kernel and kernel-smp don't. > > > > > > > > > > I think we have to assume that there will be some kernel-module packages > > > > > that just consist of drivers, with no extra user space addons. > > > > > > > > Just for the record as we don't seem to be needing this stuff: does not > > > > matter, those could be implemented so that the SRPM would produce _only_ > > > > one binary "subpackage". > > > > > > > > > > One spec file can produce packages like the following IIRC: > > > > > > openafs-V-R > > > openafs-client-V-R > > > kernel-module-openafs-V-R.%{cleankver} > > > openafs-devel-V-R > > > > Indeed. Just give the subpackage its own Release tag. > > I honestly don't care which is the base and which is the subpackage. The > biggest issue I see is with arch determination, since they HAVE to be > the same between base and subpackage. Not, if you separate "building the rpm" from "releasing the rpm". Example: # rpm -q --qf '%{ARCH} %{SOURCERPM}\n' glibc-headers glibc i386 glibc-2.3.5-10.src.rpm i686 glibc-2.3.5-10.src.rpm Ralf From tcallawa at redhat.com Wed Jun 29 16:55:18 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 29 Jun 2005 11:55:18 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120062206.6288.113.camel@mccallum.corsepiu.local> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> Message-ID: <1120064118.2513.139.camel@localhost.localdomain> On Wed, 2005-06-29 at 18:23 +0200, Ralf Corsepius wrote: > > I honestly don't care which is the base and which is the subpackage. The > > biggest issue I see is with arch determination, since they HAVE to be > > the same between base and subpackage. > Not, if you separate "building the rpm" from "releasing the rpm". > > Example: > # rpm -q --qf '%{ARCH} %{SOURCERPM}\n' glibc-headers glibc > i386 glibc-2.3.5-10.src.rpm > i686 glibc-2.3.5-10.src.rpm Thats a very good point, but it will certainly make conditionalizing the spec file fun. :) I'm not opposed to that. Example spec: # This is defined by the buildsystem, NOT on a per package basis. #%define kver 2.6.11-1.1369_FC4 %define cleankver %(echo %{kver} | sed s,-,_,g) %define kernelonlyarches i586 i686 ppc64 sparc64 %define userspacearches i386 ppc sparc %define kernelanduserarches ia64 x86_64 Name: foo Version: 0.3.6 Release: 1 Summary: Userspace components for foo Group: System Environment/Base License: Whatever URL: http://www.example.com/foo Source0: http://www.example.com/foo/foo-%{version}.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: kernel-module-%{name} BuildRequires: kernel-devel-%{_target_cpu} = %{kver} ExclusiveArch: %{kernelonlyarches} %{userspacearches} %{kernelanduserarches} %description These are userspace libraries and binaries to make the foo module usable. %package devel Group: Development/Libraries Summary: Development headers and libraries for foo Requires: %{name} = %{version}-%{release} %description devel This package contains the include files and static libraries for developing applications that use foo. %package -n kernel-module-%{name} Group: System Environment/Base Version: %{version} Release: %{release}.%{cleankver} Requires: kernel-%{_target_cpu} = %{kver} Provides: kernel-module %description -n kernel-module-%{name} This package contains the foo module compiled for kernel %{kver} on %{_target_cpu}. %prep %setup -q %build make %{?_smp_mflags} ... %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT %post -n kernel-module-%{name} [ $1 -eq 1 ] && depmod -ae -F /boot/System.map-%{kver} %{kver} >/dev/null || : %postun -n kernel-module-%{name} depmod -ae -F /boot/System.map-%{kver} %{kver} >/dev/null || : %ifarch %{userspacearches} %{kernelanduserarches} %files %defattr(-,root,root,0755) # docs go here %doc ... %{_bindir}/fooexec %{_libdir}/*.so.* %files devel %defattr(-,root,root,0755) %{_includedir}/* %{_libdir}/*.a %{_libdir}/*.so %endif %ifarch %{kernelspacearches} %{kernelanduserarches} %files -n kernel-module-%{name} %defattr(-,root,root,-) # This package should NOT have anything besides the module, to avoid file conflicts. /lib/modules/%{kver}/... %endif %changelog * Gud Fez 74 6395 Foobly Barowitz - Initial RPM release ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 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 Wed Jun 29 17:00:46 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 29 Jun 2005 12:00:46 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120064118.2513.139.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> Message-ID: <1120064446.2513.143.camel@localhost.localdomain> On Wed, 2005-06-29 at 11:55 -0500, Tom 'spot' Callaway wrote: > %ifarch %{kernelspacearches} %{kernelanduserarches} This line should be: %ifarch %{kernelonlyarches} %{kernelanduserarches} ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Wed Jun 29 18:05:57 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Jun 2005 14:05:57 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120064118.2513.139.camel@localhost.localdomain> References: <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> Message-ID: <20050629180557.GA20164@jadzia.bu.edu> On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote: > # This is defined by the buildsystem, NOT on a per package basis. > #%define kver 2.6.11-1.1369_FC4 If kver isn't defined, probably the canonical specfile should have a way to either die in an explanatory way, or else guess at a default somehow. > URL: http://www.example.com/foo > Source0: http://www.example.com/foo/foo-%{version}.tar.bz2 > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > Requires: kernel-module-%{name} *Probably* Requires: kernel-module-%{name} = %{version}, yeah? Maybe not, but I bet in the general case these need to match. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From ville.skytta at iki.fi Wed Jun 29 18:09:57 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 29 Jun 2005 21:09:57 +0300 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120064446.2513.143.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <1120064446.2513.143.camel@localhost.localdomain> Message-ID: <1120068597.2815.25.camel@localhost.localdomain> On Wed, 2005-06-29 at 12:00 -0500, Tom 'spot' Callaway wrote: > This line should be: > > %ifarch %{kernelonlyarches} %{kernelanduserarches} With that approach, when a new kernel is released for one of %{kernelanduserarches}, and only the kernel modules need a rebuild, the result is that both userspace and the module packages will be built anyway. And the userspace package will not have its NEVR changed compared to the previous one -> something somewhere needs to be able to just discard it, and NOT push it into the repository. Also, note that NEVR of -debuginfo is derived from the main package. So, if the NEVR of the main package does not change between updates (eg. kernel-update-rebuild-only ones, when the module one is not the "main" package), the resulting -debuginfo packages will be screwed. More info in a semi-related bug report from the FC1 days when I was first bitten by this: https://bugzilla.redhat.com/113276 There may be ways around these, but I think it'll end up messy. Splitting the SRPMs would be a much simpler approach, and I don't think that the maintenance burden of doing that would be untolerable at all. From mattdm at mattdm.org Wed Jun 29 18:10:33 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Jun 2005 14:10:33 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120064118.2513.139.camel@localhost.localdomain> References: <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> Message-ID: <20050629181033.GB20164@jadzia.bu.edu> On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote: > %define kernelonlyarches i586 i686 ppc64 sparc64 > %define userspacearches i386 ppc sparc > %define kernelanduserarches ia64 x86_64 Is there a reason to not just do: %define kernelmodulearches i586 i686 ppc64 sparc64 ia64 x86_64 %define userspacearches i386 ppc sparc ia64 x86_64 Also, how to deal with smp/hugemem? Separate kernel-module-smp-%{name} and kernel-module-hugemem-%{name} subpackages? (Or is that kernel-smp-module, to match kernel-smp-devel?) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From ville.skytta at iki.fi Wed Jun 29 18:47:32 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 29 Jun 2005 21:47:32 +0300 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050629180557.GA20164@jadzia.bu.edu> References: <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <20050629180557.GA20164@jadzia.bu.edu> Message-ID: <1120070852.2815.28.camel@localhost.localdomain> On Wed, 2005-06-29 at 14:05 -0400, Matthew Miller wrote: > On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote: > > # This is defined by the buildsystem, NOT on a per package basis. > > #%define kver 2.6.11-1.1369_FC4 > > If kver isn't defined, probably the canonical specfile should have a way to > either die in an explanatory way, or else guess at a default somehow. This would implement the latter, which is useful for local rebuilds for the current running kernel: %{!?kver: %define kver %(uname -r)} From ville.skytta at iki.fi Wed Jun 29 18:49:44 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 29 Jun 2005 21:49:44 +0300 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050629181033.GB20164@jadzia.bu.edu> References: <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <20050629181033.GB20164@jadzia.bu.edu> Message-ID: <1120070984.2815.30.camel@localhost.localdomain> On Wed, 2005-06-29 at 14:10 -0400, Matthew Miller wrote: > Also, how to deal with smp/hugemem? Separate kernel-module-smp-%{name} and > kernel-module-hugemem-%{name} subpackages? > > (Or is that kernel-smp-module, to match kernel-smp-devel?) None of the above; the variant is included in %{kver}, which is the output of "uname -r" for the target kernel. From mattdm at mattdm.org Wed Jun 29 19:00:26 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Jun 2005 15:00:26 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120070984.2815.30.camel@localhost.localdomain> References: <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <20050629181033.GB20164@jadzia.bu.edu> <1120070984.2815.30.camel@localhost.localdomain> Message-ID: <20050629190026.GA22523@jadzia.bu.edu> On Wed, Jun 29, 2005 at 09:49:44PM +0300, Ville Skytt? wrote: > > Also, how to deal with smp/hugemem? Separate kernel-module-smp-%{name} and > > kernel-module-hugemem-%{name} subpackages? > > (Or is that kernel-smp-module, to match kernel-smp-devel?) > None of the above; the variant is included in %{kver}, which is the > output of "uname -r" for the target kernel. Oh; duh. In the case of openafs, that requires some more hackery to figure out if we're supposed to be giving the options for an smp build. But I suspect this *way* falls into the category of "openafs is a weird bad example case". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From ville.skytta at iki.fi Wed Jun 29 19:13:27 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 29 Jun 2005 22:13:27 +0300 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050629190026.GA22523@jadzia.bu.edu> References: <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <20050629181033.GB20164@jadzia.bu.edu> <1120070984.2815.30.camel@localhost.localdomain> <20050629190026.GA22523@jadzia.bu.edu> Message-ID: <1120072407.2815.46.camel@localhost.localdomain> On Wed, 2005-06-29 at 15:00 -0400, Matthew Miller wrote: > In the case of openafs, that requires some more hackery to figure out if > we're supposed to be giving the options for an smp build. Doesn't the openafs build figure that out automatically from the kernel tree you're pointing it at [1]? Upstream issue? [1] %{_usrsrc}/kernels/%{kver}-%{_target_cpu} in FC4+ From jjneely at pams.ncsu.edu Wed Jun 29 19:19:37 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 29 Jun 2005 15:19:37 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120072407.2815.46.camel@localhost.localdomain> References: <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <20050629181033.GB20164@jadzia.bu.edu> <1120070984.2815.30.camel@localhost.localdomain> <20050629190026.GA22523@jadzia.bu.edu> <1120072407.2815.46.camel@localhost.localdomain> Message-ID: <20050629191937.GH1972@anduril.pams.ncsu.edu> On Wed, Jun 29, 2005 at 10:13:27PM +0300, Ville Skytt? wrote: > On Wed, 2005-06-29 at 15:00 -0400, Matthew Miller wrote: > > > In the case of openafs, that requires some more hackery to figure out if > > we're supposed to be giving the options for an smp build. > > Doesn't the openafs build figure that out automatically from the kernel > tree you're pointing it at [1]? Upstream issue? > > [1] %{_usrsrc}/kernels/%{kver}-%{_target_cpu} in FC4+ > > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging OpenAFS sucks...you have to pass the build different options for UP versus SMP. # UP first %configure --with-afs-sysname=%{sysname} --with-linux-kernel-headers=%{ksource_dir} --enable-kernel-module make LOCAL_SMP_DEF="$EXTRAKDEFS -D__BOOT_KERNEL_UP=1" MPS=UP only_libafs # then SMP %configure --with-afs-sysname=%{sysname} --with-linux-kernel-headers=%{ksource_dir_smp} --enable-kernel-module make LOCAL_SMP_DEF="$EXTRAKDEFS -D__BOOT_KERNEL_SMP=1" MPS=MP only_libafs Jack -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jjneely at pams.ncsu.edu Wed Jun 29 19:21:16 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 29 Jun 2005 15:21:16 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120064118.2513.139.camel@localhost.localdomain> References: <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> Message-ID: <20050629192116.GI1972@anduril.pams.ncsu.edu> Spot, I like. :-) Jack -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From mattdm at mattdm.org Wed Jun 29 20:11:59 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Jun 2005 16:11:59 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050629191937.GH1972@anduril.pams.ncsu.edu> References: <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <20050629181033.GB20164@jadzia.bu.edu> <1120070984.2815.30.camel@localhost.localdomain> <20050629190026.GA22523@jadzia.bu.edu> <1120072407.2815.46.camel@localhost.localdomain> <20050629191937.GH1972@anduril.pams.ncsu.edu> Message-ID: <20050629201159.GA25948@jadzia.bu.edu> On Wed, Jun 29, 2005 at 03:19:37PM -0400, Jack Neely wrote: > > > In the case of openafs, that requires some more hackery to figure out if > > > we're supposed to be giving the options for an smp build. > > Doesn't the openafs build figure that out automatically from the kernel > > tree you're pointing it at [1]? Upstream issue? > OpenAFS sucks...you have to pass the build different options for UP > versus SMP. Capital Letter Upstream Issue. :) In their defense, they're trying to maintain software with kernel modules for a dozen different operating systems. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From tcallawa at redhat.com Wed Jun 29 23:52:33 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 29 Jun 2005 18:52:33 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050629181033.GB20164@jadzia.bu.edu> References: <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <20050629181033.GB20164@jadzia.bu.edu> Message-ID: <1120089153.2513.150.camel@localhost.localdomain> On Wed, 2005-06-29 at 14:10 -0400, Matthew Miller wrote: > On Wed, Jun 29, 2005 at 11:55:18AM -0500, Tom 'spot' Callaway wrote: > > %define kernelonlyarches i586 i686 ppc64 sparc64 > > %define userspacearches i386 ppc sparc > > %define kernelanduserarches ia64 x86_64 > > Is there a reason to not just do: > > %define kernelmodulearches i586 i686 ppc64 sparc64 ia64 x86_64 > %define userspacearches i386 ppc sparc ia64 x86_64 Not really. :) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 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 Wed Jun 29 23:55:59 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 29 Jun 2005 18:55:59 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120068597.2815.25.camel@localhost.localdomain> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <1120064446.2513.143.camel@localhost.localdomain> <1120068597.2815.25.camel@localhost.localdomain> Message-ID: <1120089359.2513.155.camel@localhost.localdomain> On Wed, 2005-06-29 at 21:09 +0300, Ville Skytt? wrote: > There may be ways around these, but I think it'll end up messy. > Splitting the SRPMs would be a much simpler approach, and I don't think > that the maintenance burden of doing that would be untolerable at all. Honestly? I agree. Even if it means we end up with two copies of the full source in two SRPMS. Unless someone is violently opposed to splitting the SRPMS as policy (and can come up with a way to resolve the unnecessary userland package bumps/rebuilds), thats what I'm inclined to adopt. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Thu Jun 30 01:48:19 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Jun 2005 21:48:19 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <1120089359.2513.155.camel@localhost.localdomain> References: <1120052325.2513.75.camel@localhost.localdomain> <1120055491.9688.330.camel@localhost.localdomain> <20050629145827.GG1972@anduril.pams.ncsu.edu> <1120057676.1864.2.camel@ignacio.ignacio.lan> <1120059306.2513.112.camel@localhost.localdomain> <1120062206.6288.113.camel@mccallum.corsepiu.local> <1120064118.2513.139.camel@localhost.localdomain> <1120064446.2513.143.camel@localhost.localdomain> <1120068597.2815.25.camel@localhost.localdomain> <1120089359.2513.155.camel@localhost.localdomain> Message-ID: <20050630014819.GA4158@jadzia.bu.edu> On Wed, Jun 29, 2005 at 06:55:59PM -0500, Tom 'spot' Callaway wrote: > Honestly? I agree. Even if it means we end up with two copies of the > full source in two SRPMS. > Unless someone is violently opposed to splitting the SRPMS as policy > (and can come up with a way to resolve the unnecessary userland package > bumps/rebuilds), thats what I'm inclined to adopt. I'm fine with this or with the ifarch conditional plan -- either way has its ugliness. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From jjneely at pams.ncsu.edu Thu Jun 30 04:06:29 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 30 Jun 2005 00:06:29 -0400 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050629135930.GD1972@anduril.pams.ncsu.edu> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120052530.2513.79.camel@localhost.localdomain> <20050629135930.GD1972@anduril.pams.ncsu.edu> Message-ID: <20050630040629.GR1972@anduril.pams.ncsu.edu> Folks, Attached is a patch that implements some of the kernel magic needed by Yum to work with kernel modules as decided on fedora-packaging-list. This keys off of kernel modules requiring kernel-%{_target_cpu} = %{kver} Couple points of note: * You must still have your kernel modules provide "kernel-modules" to enable the install only behavior. However, the code uses the package name "kernel-module-foo" to identify if this is a kernel module. * The next question is when you do "yum install kernel-module-openafs" which packages do we apply to the system? Not covered by this patch. Jack -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 -------------- next part -------------- ? .transactioninfo.py.swp ? kernel-module-2.patch ? rhn.py Index: depsolve.py =================================================================== RCS file: /home//groups/yum/cvs/yum/yum/depsolve.py,v retrieving revision 1.66 diff -u -r1.66 depsolve.py --- depsolve.py 27 Jun 2005 06:34:05 -0000 1.66 +++ depsolve.py 30 Jun 2005 03:51:57 -0000 @@ -110,7 +110,39 @@ return 1 return 0 - + + def handleKernelModule(self, txmbr): + """Figure out what special magic needs to be done to install/upgrade + this kernel module.""" + + def getKernelReqs(hdr): + kernels = ["kernel-%s" % a for a in rpmUtils.arch.arches.keys()] + reqs = [] + names = hdr[rpm.RPMTAG_REQUIRENAME] + flags = hdr[rpm.RPMTAG_REQUIREFLAGS] + ver = hdr[rpm.RPMTAG_REQUIREVERSION] + if names is not None: + reqs = zip(names, flags, ver) + return filter(lambda r: r[0] in kernels, reqs) + + kernelReqs = getKernelReqs(txmbr.po.returnLocalHeader()) + instPkgs = self.rpmdb.returnTupleByKeyword(name=txmbr.po.name) + for pkg in instPkgs: + hdr = self.rpmdb.returnHeaderByTuple(pkg)[0] + instKernelReqs = getKernelReqs(hdr) + + for r in kernelReqs: + if r in instKernelReqs: + # we know that an incoming kernel module requires the + # same kernel as an already installed module of the + # same name. "Upgrade" this module instead of install + po = packages.YumInstalledPackage(hdr) + self.tsInfo.addErase(po) + self.log(4, 'Removing kernel module %s upgraded to %s' % + (po, txmbr.po)) + break + + def populateTs(self, test=0, keepold=1): """take transactionData class and populate transaction set""" @@ -139,6 +171,8 @@ rpmfile = txmbr.po.localPkg() if txmbr.ts_state == 'u': + if txmbr.po.name.startswith("kernel-module-"): + self.handleKernelModule(txmbr) if self.allowedMultipleInstalls(txmbr.po): self.log(5, '%s converted to install' % (txmbr.po)) txmbr.ts_state = 'i' From tcallawa at redhat.com Thu Jun 30 12:36:15 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 30 Jun 2005 07:36:15 -0500 Subject: [Fedora-packaging] Kernel modules (was: Re: tpctl in extras missing dependancy for kernel-module-thinkpad) In-Reply-To: <20050630040629.GR1972@anduril.pams.ncsu.edu> References: <604aa791050628074059f67fe7@mail.gmail.com> <1119971087.9688.76.camel@localhost.localdomain> <1119972361.4427.59.camel@ignacio.ignacio.lan> <1120005652.2513.47.camel@localhost.localdomain> <20050629012439.GA16473@jadzia.bu.edu> <1120052325.2513.75.camel@localhost.localdomain> <1120052530.2513.79.camel@localhost.localdomain> <20050629135930.GD1972@anduril.pams.ncsu.edu> <20050630040629.GR1972@anduril.pams.ncsu.edu> Message-ID: <1120134976.2513.176.camel@localhost.localdomain> On Thu, 2005-06-30 at 00:06 -0400, Jack Neely wrote: > Folks, > > Attached is a patch that implements some of the kernel magic needed by > Yum to work with kernel modules as decided on fedora-packaging-list. > This keys off of kernel modules requiring > > kernel-%{_target_cpu} = %{kver} > > Couple points of note: > > * You must still have your kernel modules provide "kernel-modules" to > enable the install only behavior. However, the code uses the package > name "kernel-module-foo" to identify if this is a kernel module. > > * The next question is when you do "yum install kernel-module-openafs" > which packages do we apply to the system? Not covered by this patch. As far as I'm concerned, we look at what kernels are on the system (in the rpmdb), and try our best to match them all against the kernel-module-openafs packages in the repo. When we find a kernel for which no kernel-module-openafs package exists in the repo, we throw a warning, but don't exit, and install the ones we do find matches for. Warning: No kernel-module-openafs package was found for kernel-2.6.12-1.1400spot I really can't think of a situation in which we would not want to install an addon kernel-module for all kernels installed via rpm. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 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 Thu Jun 30 13:52:22 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Jun 2005 15:52:22 +0200 Subject: [Fedora-packaging] example kernel-module package Message-ID: <1120139542.3714.22.camel@notebook.thl.home> Hi guys, sorry, I was mostly away the last two days so you had to fight with kernel-modules alone. I'll try to catch up and reply where I think it's needed. Anyway, I created a example package with kernel-modules for ndiswrapper to play a bit with the discussed scheme. It I maintain ndiswrapper (and some other kernel-module-packages) already for livna. I just chooesed it for this example cause it's small, builds fast and needs a userspace-program and a kernel-module. I followed the example in the wiki and some posts on this list. I split the package in a userland package that creates a %{name}-kmsrc.rpm that is used by the kernel-module-package as source. Something like this would be neat package like nvidia als ati drivers where a single srpm is quite big if you want to rebuild only the kernel-module (yes, it seems a lot of users of livna users do that). Find the specs and SRPMS at http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ Comments? -- Thorsten Leemhuis From tcallawa at redhat.com Thu Jun 30 14:07:53 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 30 Jun 2005 09:07:53 -0500 Subject: [Fedora-packaging] example kernel-module package In-Reply-To: <1120139542.3714.22.camel@notebook.thl.home> References: <1120139542.3714.22.camel@notebook.thl.home> Message-ID: <1120140474.2513.187.camel@localhost.localdomain> On Thu, 2005-06-30 at 15:52 +0200, Thorsten Leemhuis wrote: > Hi guys, > > sorry, I was mostly away the last two days so you had to fight with > kernel-modules alone. I'll try to catch up and reply where I think it's > needed. > > Anyway, I created a example package with kernel-modules for ndiswrapper > to play a bit with the discussed scheme. It > > I maintain ndiswrapper (and some other kernel-module-packages) already > for livna. I just chooesed it for this example cause it's small, builds > fast and needs a userspace-program and a kernel-module. > > I followed the example in the wiki and some posts on this list. I split > the package in a userland package that creates a %{name}-kmsrc.rpm that > is used by the kernel-module-package as source. Something like this > would be neat package like nvidia als ati drivers where a single srpm is > quite big if you want to rebuild only the kernel-module (yes, it seems a > lot of users of livna users do that). I think the source should be a Source0 in kernel-module-ndiswrapper. I'm not very comfortable with confusing people with src.rpms that have no source in them. Yes, I know this means duplication of source code in two SRPMS, but disk is cheap. Nosrc.rpms are part of the slipperly slope to SuSE town. :/ Otherwise, I think you're right on target. (Ignoring the fact that I think ndiswrapper should probably be ExclusiveArch: i586 i686) ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Thu Jun 30 14:11:10 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 30 Jun 2005 17:11:10 +0300 Subject: [Fedora-packaging] example kernel-module package In-Reply-To: <1120139542.3714.22.camel@notebook.thl.home> References: <1120139542.3714.22.camel@notebook.thl.home> Message-ID: <1120140670.2815.123.camel@localhost.localdomain> On Thu, 2005-06-30 at 15:52 +0200, Thorsten Leemhuis wrote: > I split > the package in a userland package that creates a %{name}-kmsrc.rpm that > is used by the kernel-module-package as source. Something like this > would be neat package like nvidia als ati drivers where a single srpm is > quite big if you want to rebuild only the kernel-module I don't see the point of the kmsrc package. If you want to optimize SRPM download sizes, why not just supply a separate trimmed-down tarball containing only the kernel module bits in the kernel module SRPM (and include comments in the specfile how it was created from the upstream dist tarball, or include a script to do it in the source rpm)? And if you want, another similar trimmed one in the userland SRPM containing only the non-kernel-module parts. Unless I'm missing something, using your approach, the user who wants to locally build only the kernel modules needs to have not only the SRPM that produces the modules, but also one extra binary package (which actually contains the sources). Further, the sources and the build routines for the kernel modules are now split into two packages, which means also extra work and care from the maintainer. Isn't this just more work for both maintainers and end users? Did I miss something? From ville.skytta at iki.fi Thu Jun 30 14:17:39 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 30 Jun 2005 17:17:39 +0300 Subject: [Fedora-packaging] example kernel-module package In-Reply-To: <1120140474.2513.187.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120140474.2513.187.camel@localhost.localdomain> Message-ID: <1120141059.2815.129.camel@localhost.localdomain> On Thu, 2005-06-30 at 09:07 -0500, Tom 'spot' Callaway wrote: > (Ignoring the fact that I > think ndiswrapper should probably be ExclusiveArch: i586 i686) Regarding ExclusiveArch in general (for module packages that can be built on whatever platform), what is it needed for in the proposal? http://fedoraproject.org/wiki/Extras/KernelModuleProposal Does the build system decide that it _will_ (as opposed to won't) build something based on ExclusiveArch? That would sound backwards to me. From fedora at leemhuis.info Thu Jun 30 14:41:33 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Jun 2005 16:41:33 +0200 Subject: [Fedora-packaging] example kernel-module package In-Reply-To: <1120140474.2513.187.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120140474.2513.187.camel@localhost.localdomain> Message-ID: <1120142494.3714.25.camel@notebook.thl.home> Am Donnerstag, den 30.06.2005, 09:07 -0500 schrieb Tom 'spot' Callaway: > On Thu, 2005-06-30 at 15:52 +0200, Thorsten Leemhuis wrote: > > Hi guys, > > > > sorry, I was mostly away the last two days so you had to fight with > > kernel-modules alone. I'll try to catch up and reply where I think it's > > needed. > > > > Anyway, I created a example package with kernel-modules for ndiswrapper > > to play a bit with the discussed scheme. It > > > > I maintain ndiswrapper (and some other kernel-module-packages) already > > for livna. I just chooesed it for this example cause it's small, builds > > fast and needs a userspace-program and a kernel-module. > > > > I followed the example in the wiki and some posts on this list. I split > > the package in a userland package that creates a %{name}-kmsrc.rpm that > > is used by the kernel-module-package as source. Something like this > > would be neat package like nvidia als ati drivers where a single srpm is > > quite big if you want to rebuild only the kernel-module (yes, it seems a > > lot of users of livna users do that). > > I think the source should be a Source0 in kernel-module-ndiswrapper. No problem with that. Was just a idea to save space. > Otherwise, I think you're right on target. (Ignoring the fact that I > think ndiswrapper should probably be ExclusiveArch: i586 i686) x86_64 also, but yes, ppc was wrong here -- i just included it here cause it's an example ;) -- Thorsten Leemhuis From fedora at leemhuis.info Thu Jun 30 16:46:52 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Jun 2005 18:46:52 +0200 Subject: [Fedora-packaging] example kernel-module package In-Reply-To: <1120140670.2815.123.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120140670.2815.123.camel@localhost.localdomain> Message-ID: <1120150012.3714.40.camel@notebook.thl.home> Am Donnerstag, den 30.06.2005, 17:11 +0300 schrieb Ville Skytt?: > On Thu, 2005-06-30 at 15:52 +0200, Thorsten Leemhuis wrote: > > > I split > > the package in a userland package that creates a %{name}-kmsrc.rpm that > > is used by the kernel-module-package as source. Something like this > > would be neat package like nvidia als ati drivers where a single srpm is > > quite big if you want to rebuild only the kernel-module > > I don't see the point of the kmsrc package. As I said in the mail to spot -- I removed it. > If you want to optimize SRPM download sizes, why not just supply a > separate trimmed-down tarball containing only the kernel module bits in > the kernel module SRPM (and include comments in the specfile how it was > created from the upstream dist tarball, or include a script to do it in > the source rpm)? Yes, that is my plan for the ati-fglrx package because the srpm is now 22M, but the src for the kernel-module is a lot smaller. > And if you want, another similar trimmed one in the > userland SRPM containing only the non-kernel-module parts. I don't see a reason for this. > Further, the sources and the build routines for the kernel modules are > now split into two packages, which means also extra work and care from > the maintainer. In the case of ati-fglrx or nvidia-glx I think it's worth the trouble. For ndiswrapper it's probably not. BTW, I updated the packages/specs at http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ and also the proposal at http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal I added it as real world example/second proposal with split packages for userland and kernel-module. -- Thorsten Leemhuis From rc040203 at freenet.de Thu Jun 30 16:47:22 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 30 Jun 2005 18:47:22 +0200 Subject: [Fedora-packaging] example kernel-module package In-Reply-To: <1120140670.2815.123.camel@localhost.localdomain> References: <1120139542.3714.22.camel@notebook.thl.home> <1120140670.2815.123.camel@localhost.localdomain> Message-ID: <1120150042.3741.62.camel@mccallum.corsepiu.local> On Thu, 2005-06-30 at 17:11 +0300, Ville Skytt? wrote: > On Thu, 2005-06-30 at 15:52 +0200, Thorsten Leemhuis wrote: > > > I split > > the package in a userland package that creates a %{name}-kmsrc.rpm that > > is used by the kernel-module-package as source. Something like this > > would be neat package like nvidia als ati drivers where a single srpm is > > quite big if you want to rebuild only the kernel-module > > I don't see the point of the kmsrc package. ACK. > If you want to optimize SRPM download sizes, why not just supply a > separate trimmed-down tarball containing only the kernel module bits in > the kernel module SRPM (and include comments in the specfile how it was > created from the upstream dist tarball, or include a script to do it in > the source rpm)? And if you want, another similar trimmed one in the > userland SRPM containing only the non-kernel-module parts. Actually, I fail to see where this approach _really_ reduces bandwidth requirements. Users who are rebuilding the rpms, should learn to download the srpm once. Afterwards, they'll have it "on disk" and don't have to re-download it again. I would expect the high rate of downloads of kernel-module-*src.rpms you might be seeing at Livna to originate from delays between kernel releases in FC and kernel-module releases at Livna. > Further, the sources and the build routines for the kernel modules are > now split into two packages, which means also extra work and care from > the maintainer. Agreed. Also, it might not always be possible or not possible with further effort, sometimes for technical reasons (Makefiles, build infrastructure etc.), sometimes for licensing reasons ("Unmodified sources"). > Isn't this just more work for both maintainers and end users? Not for end users. They'd only see a kernel-module*.src.rpm and will not know about the fact it had been split out elsewhere. But .. no matter if the source are split into userland/kernel srpms they will have to rebuild _one_ srpm. Ralf From fedora at leemhuis.info Thu Jun 30 17:26:08 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Jun 2005 19:26:08 +0200 Subject: [Fedora-packaging] example kernel-module package In-Reply-To: <1120150042.3741.62.camel@mccallum.corsepiu.local> References: <1120139542.3714.22.camel@notebook.thl.home> <1120140670.2815.123.camel@localhost.localdomain> <1120150042.3741.62.camel@mccallum.corsepiu.local> Message-ID: <1120152368.3714.64.camel@notebook.thl.home> Am Donnerstag, den 30.06.2005, 18:47 +0200 schrieb Ralf Corsepius: > On Thu, 2005-06-30 at 17:11 +0300, Ville Skytt? wrote: > > On Thu, 2005-06-30 at 15:52 +0200, Thorsten Leemhuis wrote: > > If you want to optimize SRPM download sizes, why not just supply a > > separate trimmed-down tarball containing only the kernel module bits in > > the kernel module SRPM (and include comments in the specfile how it was > > created from the upstream dist tarball, or include a script to do it in > > the source rpm)? And if you want, another similar trimmed one in the > > userland SRPM containing only the non-kernel-module parts. > Actually, I fail to see where this approach _really_ reduces bandwidth > requirements. Sourcecode for the kernel-module parts livna ati-fglrx package: around 4,5 MByte for x86 and x86_64 together. Whole SRPM (includes x86_64 and x86): 22 MByte. > Users who are rebuilding the rpms, should learn to download the srpm > once. Every two month when ati releases a new driver. > Afterwards, they'll have it "on disk" and don't have to > re-download it again. Sure. > I would expect the high rate of downloads of kernel-module-*src.rpms you > might be seeing at Livna to originate from delays between kernel > releases in FC and kernel-module releases at Livna. People use those to build against rawhide, kernels from updates-testing and even self-compiled kernels (not possible with the scheme we currently discuss here for extras). If I broke something there I got bug-reports shortly after release... > [...] CU thl -- Thorsten Leemhuis