From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Aug 1 22:37:30 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 2 Aug 2005 00:37:30 +0200 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <604aa791050720135376dcd0be@mail.gmail.com> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> <42DE7ED5.3040603@cora.nwra.com> <42DE8080.6070103@math.unl.edu> <604aa791050720135376dcd0be@mail.gmail.com> Message-ID: <20050802003730.16983d1d@python2> Jeff Spaleta wrote : > On 7/20/05, Rex Dieter wrote: > > Yes, the Fedora Extras buildsystem defines this macro. You expected > > otherwise? > > actually.. i sort of do. I'd very much expect my workstation running > fc4 to have access to a package with the fedora specific macro > definitions set to values the fedora-whatever build system uses for > building packages for fc4. [...] Just to point this out : When Dag and I were searching for agreements on many diverging points in our ways of building packages, one we easily got to was to have the default (i.e. "without any manual defines") rebuild for the latest release of the distribution available. In this case, this means that if someone checks for %{fedora}'s value, but it isn't defined, the behavior should default to the proper one for FC4 (since it's the latest ATM). For me, this is a sane default, and I'd like to see Extras use it as much as possible too ;-) So "if %fedora >= 4 then foo else bar" should be replaced by something else that works as expected (like what Ignacio wrote). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.06 0.16 0.44 From jspaleta at gmail.com Mon Aug 1 23:09:48 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 1 Aug 2005 19:09:48 -0400 Subject: [Fedora-packaging] Using %{dist} for conditional compilation In-Reply-To: <20050802003730.16983d1d@python2> References: <42D82113.5030005@cora.nwra.com> <1121461276.10063.11.camel@ignacio.lan> <42D83A17.9060302@cora.nwra.com> <42DE7ED5.3040603@cora.nwra.com> <42DE8080.6070103@math.unl.edu> <604aa791050720135376dcd0be@mail.gmail.com> <20050802003730.16983d1d@python2> Message-ID: <604aa79105080116093f4eef10@mail.gmail.com> On 8/1/05, Matthias Saou wrote: > In this case, this means that if someone checks for %{fedora}'s value, but > it isn't defined, the behavior should default to the proper one for FC4 > (since it's the latest ATM). For me, this is a sane default, and I'd like > to see Extras use it as much as possible too ;-) I didnt say anything about default behavior.. i just want access to a package that gives me the canonical buildsystem macro settings for the release I'm trying to build on regardless of its vintage. So when I'm doing local building when prepping a package I can have very good confidence that I am using the the correct build environment without having to resort to building inside mock for every local build attempt I make when I'm troubleshooting packaging bugs. -jef From orion at cora.nwra.com Fri Aug 5 21:38:20 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Aug 2005 15:38:20 -0600 Subject: [Fedora-packaging] Tool to determine what files require what Message-ID: <42F3DC4C.6050406@cora.nwra.com> I'm packaging some software that provides interfaces for lots of different libraries and languages. I'd like to split it up into sub-packages for the different components. It would be useful to have a tool that would report a "requires" for each file in the package in order to "sort" them into the different sub-packages. Any suggestions? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From i.pilcher at comcast.net Sat Aug 6 16:40:06 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Sat, 06 Aug 2005 11:40:06 -0500 Subject: [Fedora-packaging] Re: Tool to determine what files require what In-Reply-To: <42F3DC4C.6050406@cora.nwra.com> References: <42F3DC4C.6050406@cora.nwra.com> Message-ID: Orion Poplawski wrote: > I'm packaging some software that provides interfaces for lots of > different libraries and languages. I'd like to split it up into > sub-packages for the different components. It would be useful to have a > tool that would report a "requires" for each file in the package in > order to "sort" them into the different sub-packages. If the files in question are binary executables or libraries, ldd should do what you want. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From orion at cora.nwra.com Mon Aug 8 16:14:03 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 08 Aug 2005 10:14:03 -0600 Subject: [Fedora-packaging] Re: Tool to determine what files require what In-Reply-To: References: <42F3DC4C.6050406@cora.nwra.com> Message-ID: <42F784CB.1080302@cora.nwra.com> Ian Pilcher wrote: > > If the files in question are binary executables or libraries, ldd should > do what you want. > Yeah, I was hoping for something a little more ready to go. Does anyone know what script/process is run during the rpmbuild that generates the rpm dependecies, perhaps I can use/modify that... -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From pmatilai at laiskiainen.org Mon Aug 8 16:35:23 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 08 Aug 2005 19:35:23 +0300 Subject: [Fedora-packaging] Re: Tool to determine what files require what In-Reply-To: <42F784CB.1080302@cora.nwra.com> References: <42F3DC4C.6050406@cora.nwra.com> <42F784CB.1080302@cora.nwra.com> Message-ID: <1123518923.6104.4.camel@weasel.turre.laiskiainen.org> On Mon, 2005-08-08 at 10:14 -0600, Orion Poplawski wrote: > Ian Pilcher wrote: > > > > If the files in question are binary executables or libraries, ldd should > > do what you want. > > > Yeah, I was hoping for something a little more ready to go. Does anyone > know what script/process is run during the rpmbuild that generates the > rpm dependecies, perhaps I can use/modify that... That'd be /usr/lib/rpm/find-requires, it takes a list of filenames in stdin and outputs the dependencies, eg [pmatilai at weasel ~]$ echo /usr/bin/telnet | /usr/lib/rpm/find-requires libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.3)(64bit) libncurses.so.5()(64bit) libutil.so.1()(64bit) ..and then you can further process that if you want, with rpmquery or repoquery where appropriate: [pmatilai at weasel ~]$ echo /usr/bin/telnet | /usr/lib/rpm/find-requires| xargs rpm -q --whatprovides|sort -u glibc-2.3.5-10 ncurses-5.4-17 - Panu - From orion at cora.nwra.com Mon Aug 8 16:40:13 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 08 Aug 2005 10:40:13 -0600 Subject: [Fedora-packaging] Re: Tool to determine what files require what In-Reply-To: <42F784CB.1080302@cora.nwra.com> References: <42F3DC4C.6050406@cora.nwra.com> <42F784CB.1080302@cora.nwra.com> Message-ID: <42F78AED.4050605@cora.nwra.com> Orion Poplawski wrote: > > Yeah, I was hoping for something a little more ready to go. Does anyone > know what script/process is run during the rpmbuild that generates the > rpm dependecies, perhaps I can use/modify that... > > Well, to answer my question, this basically does what I want: #Requires find $RPM_BUILD_ROOT -type f | while read file do deps=`/usr/lib/rpm/rpmdeps -R $file` if [ -n "$deps" ] then echo -n "$file: " | sed s,$RPM_BUILD_ROOT,, >> ../requires echo $deps >> ../requires fi done Then with a simple perl script I can invert the list to files show per requirement. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From toshio at tiki-lounge.com Mon Aug 8 19:19:01 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 08 Aug 2005 12:19:01 -0700 Subject: [Fedora-packaging] updating versions policy In-Reply-To: <1121414942.2665.26.camel@locolhost.localdomain> References: <1121414942.2665.26.camel@locolhost.localdomain> Message-ID: <1123528741.28869.14.camel@localhost> On Fri, 2005-07-15 at 01:09 -0700, Michael A. Peters wrote: > I know that with shared libraries, it generally is not a good idea to > push an update that involves versioning a shared library because the > user may have software their system that is linked against the older > shared library, but is there a general policy about other software? > > One of the packages I maintain in Extras is likely to be named as a > sourceforge project of the month. The upstream developer is working > overtime to finish implementing some things before that happens. The > package is gourmet (PyGTK recipe manager) and absolutely nothing depends > upon it - and I'm thinking that when he has these things finished, that > might be a good time to update the package in Extras. > > Since it is not a package which is designed to have anything else depend > on it, I'm assuming there is not a problem with a version update in > Extras? Is that the case? For applications instead of shared libraries there may still be some artifacts on the system that need updating to a new version. These would be save files, data stores, and other pieces of persistent data that may need to be ported from an older version of the package to a new one. The discussion of whether to package git and cogito a few months back was one example of this. PostgreSQL's need to dump and restore between major version upgrades is another. For gourmet, the questions would probably be -- is the new version capable of loading the recipes saved in the old version transparently? If not, is there some way to manually import them? If not, is it a planned feature for a later date? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Tue Aug 9 15:27:02 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 09 Aug 2005 09:27:02 -0600 Subject: [Fedora-packaging] rpmlint warning Message-ID: <42F8CB46.10500@cora.nwra.com> Can someone explain this rpmlint error? E: plplot-tk no-dependency-on locales-tk -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From ville.skytta at iki.fi Tue Aug 9 15:50:08 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 09 Aug 2005 18:50:08 +0300 Subject: [Fedora-packaging] rpmlint warning In-Reply-To: <42F8CB46.10500@cora.nwra.com> References: <42F8CB46.10500@cora.nwra.com> Message-ID: <1123602608.621.31.camel@localhost.localdomain> On Tue, 2005-08-09 at 09:27 -0600, Orion Poplawski wrote: > Can someone explain this rpmlint error? > > E: plplot-tk no-dependency-on locales-tk Mandriva'ism, I think, but then again, I don't know about tk stuff. Please report it in Bugzilla so I don't forget to take care of it in the next rpmlint revision. From orion at cora.nwra.com Thu Aug 11 16:29:38 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 11 Aug 2005 10:29:38 -0600 Subject: [Fedora-packaging] To .pyo or not to .pyo? Message-ID: <42FB7CF2.50407@cora.nwra.com> I'm a python neophyte, but I've been packaging some python packages and have questions about .pyo files. I've gotten various feedback about including them, not including them, and using %ghost on them. Can someone please explain what the issues are (both with arch and noarch packages)? Also, what does %ghost do? Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From symbiont at berlios.de Thu Aug 11 17:20:00 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 11 Aug 2005 11:20:00 -0600 Subject: [Fedora-packaging] To .pyo or not to .pyo? In-Reply-To: <42FB7CF2.50407@cora.nwra.com> References: <42FB7CF2.50407@cora.nwra.com> Message-ID: <200508111120.01240.symbiont@berlios.de> On Thursday 11 August 2005 10:29, Orion Poplawski wrote: > I'm a python neophyte, but I've been packaging some python packages > and have questions about .pyo files. ?I've gotten various feedback > about including them, not including them, and using %ghost on them. > ?Can someone please explain what the issues are (both with arch and > noarch packages)? ?Also, what does %ghost do? Arch/Noarch, it's the same. The issues have to do with whether they provide the bang vs. buck (buck being diskspace in this case) that you'd want. I think fedora-extras in general goes with the %ghost method because it was deemed that they don't. %ghost deletes those files upon package removal. The reason you want %ghost is because if you run a python script that starts with: #!/usr/bin/python -O or # python -O /usr/share/script/main.py Then .pyo files will automatically litter your harddrive. %ghost will clean these up. Currently, .pyo provides two optimizations: 1. (-O) some peephole bytecode optimization to improve startup. 2. (-OO) get rid of the docstrings to streamline the code. #2 could be bad in that some testing relies on docstrings. -OO is never really used in packages. #1 -- I heard that this may be just included without -O in a future release. I don't know. Depends on how pedantic the PowersThatBe want the bytecode to map against the code that's just been parsed/lexed. Anyway, hope that helps. Policy is to %ghost .pyo for add-on modules in extras, I believe. (Although baseline python will always have .pyo in the lib directory.) I for one, don't really care since were talking about saving kilobytes of diskspace... YMMV. -- -jeff From orion at cora.nwra.com Thu Aug 11 17:26:34 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 11 Aug 2005 11:26:34 -0600 Subject: [Fedora-packaging] To .pyo or not to .pyo? In-Reply-To: <200508111120.01240.symbiont@berlios.de> References: <42FB7CF2.50407@cora.nwra.com> <200508111120.01240.symbiont@berlios.de> Message-ID: <42FB8A4A.5080209@cora.nwra.com> Jeff Pitman wrote: > > %ghost deletes those files upon package removal. The reason you want > %ghost is because if you run a python script that starts with: > So, %ghost says don't install these, and when they show up remove them on package removal? Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From symbiont at berlios.de Thu Aug 11 17:57:06 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 11 Aug 2005 11:57:06 -0600 Subject: [Fedora-packaging] To .pyo or not to .pyo? In-Reply-To: <42FB8A4A.5080209@cora.nwra.com> References: <42FB7CF2.50407@cora.nwra.com> <200508111120.01240.symbiont@berlios.de> <42FB8A4A.5080209@cora.nwra.com> Message-ID: <200508111157.07087.symbiont@berlios.de> On Thursday 11 August 2005 11:26, Orion Poplawski wrote: > Jeff Pitman wrote: > > %ghost deletes those files upon package removal. ?The reason you > > want %ghost is because if you run a python script that starts with: > > So, %ghost says don't install these, and when they show up remove > them on package removal? That is correct. -- -jeff From agruen at suse.de Thu Aug 18 17:56:04 2005 From: agruen at suse.de (Andreas Gruenbacher) Date: Thu, 18 Aug 2005 19:56:04 +0200 Subject: [Fedora-packaging] Kernel Module Packages Message-ID: <200508181956.05154.agruen@suse.de> Hello, I have thought about rpm packages containing kernel modules independently of the threads in this mailing list, which Matt Domsch was friendly enough to pointed me at --- thanks, Matt. Maybe we can share some thoughts, and even move our implementations a little closer together. We've been looking at DKMS, and decided not to use it in favor of a purely rpm based solution, so that the rpm database knows which modules belong to which packages, etc. That's the same as with your proposals on http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal. One of the benefits of DKMS we saw was the ability to query which driver packages were installed for a specific kernel. The same can be achieved by checking which packages beside the kernel package itself install *.ko files below /lib/modules/$(uname -r), so we'll achieve this feature by a script that does that. Easy enough. You seem to also prefix kernel module package names with ``kernel-module-'' to make them easier to identify. Not really necessary I believe, especially since they can as well be listed with --whatrequires. We thought it useful to include a unique provider prefix in the package name though, so that different vendors won't produce name clashes. Our plan was to use the LANANA provider names registry (http://www.lanana.org/) for that. The driver name, driver version, and kernel release ($KERNELRELEASE) are also stored differently in rpm tags: our build system likes to be able to freely assign the package release number, so we don't store extra information there. Rather, we put the driver version in the Name, and the kernel release in the Version: > %define provider_prefix novell > %define driver_name foo > %define driver_version 1.1 > %define flavor smp > > %define kver %(rpm -q --qf '%{VERSION}-%{RELEASE}' kernel-source) > > Name: %provider_prefix-%driver_name-%driver_version > Version: %(echo %kver-%flavor | tr - _) > Release: > Requires: kernel-%flavor = %kver The kernel version and release %kver is determined by the installed kernel-source package. The %flavor thing deserves some explanation: for each architecture, we have a number of differerent kernel configurations which we call "flavors". The config files for those flavors are found in arch/$ARCH/defconfig.$FLAVOR in the SUSE kernel-source package, by the way. The kernel packages are called kernel-$flavor, with version and release %kver. They additionally provide the symbol kernel = %kver. There is some documentation at http://www.suse.de/~agruen/kernel-doc/, in case anybody is interested. Storing the driver version in the package name allows driver vendors to offer multiple versions of the same driver for use with the same kernel. These packages won't interfere with each other on updates, unless one of the drivers Provides and Obsoletes another. We have learned with pain that vendors sometimes drop features in drivers with higher versions, leading to interesting customer situations. Because of that, we want kernel updates to update driver versions only if explicitly requested. One feature we allow is, we allow modules for multiple flavors (from the same architecture) in the same kernel driver package. For example, a kernel driver package could contain modules for 2.6.13-rc6-1-default, 2.6.13-rc6-1-smp, and 2.6.13-rc6-1-xen. It is very easy to build those modules, and most modules are really small, so this reduces the number of packages we need to build, and manage. In that case, the Version and Requires tags change to: > Version: %(echo %kver | tr - _) > Requires: kernel = %kver Another interesting case is module package reuse: often modules from the previous kernel can be reused with the new kernel after a kernel upgrade, in case a new module package is not available. Dropping driver packages might render systems unbootable (consider a raid adapter driver or similar). It's quite easy to check if the modversions a module requires have changed. We offer to reuse module packages if possible. When a user choses to reuse a module package, we repackage the files in the old module package for the new kernel, and move modules from /lib/modules/$old_kernel to /lib/modules/$new_kernel. That way we can keep proper record in the rpm database, and everything stays nicely manageable. What I'm also missing in your proposals is mkinitrd calls: When modules that are part of initrds get replaced, you also want to update it the initrds I guess. Regards, Andreas. From tcallawa at redhat.com Thu Aug 18 19:27:18 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 18 Aug 2005 14:27:18 -0500 Subject: [Fedora-packaging] Kernel Module Packages In-Reply-To: <200508181956.05154.agruen@suse.de> References: <200508181956.05154.agruen@suse.de> Message-ID: <1124393238.2753.89.camel@localhost.localdomain> On Thu, 2005-08-18 at 19:56 +0200, Andreas Gruenbacher wrote: > Hello, > > I have thought about rpm packages containing kernel modules independently of > the threads in this mailing list, which Matt Domsch was friendly enough to > pointed me at --- thanks, Matt. Maybe we can share some thoughts, and even > move our implementations a little closer together. Welcome to the unified flame-war... i mean, party. :) > You seem to also prefix kernel module package names with ``kernel-module-'' to > make them easier to identify. Not really necessary I believe, especially > since they can as well be listed with --whatrequires. We're doing this for user sanity as well, and to help differentiate userspace packages from kernel-module packages. (Yum might be checking for it as well, but I'm not the expert on that). > We thought it useful to include a unique provider prefix in the package name > though, so that different vendors won't produce name clashes. Our plan was to > use the LANANA provider names registry (http://www.lanana.org/) for that. Ugh. I really don't want to cram everything and the kitchen sink into the package name. I'd rather see the package check for a SuSE/Fedora/Whatever only file on the system and use that to determine if its in the right place or not. We also have dist tags for that purpose in Fedora Extras. > The driver name, driver version, and kernel release ($KERNELRELEASE) are also > stored differently in rpm tags: our build system likes to be able to freely > assign the package release number, so we don't store extra information there. > Rather, we put the driver version in the Name, and the kernel release in the > Version: Hmm. Again, I don't want to overload %{name}. That's not what its there for, imho. > What I'm also missing in your proposals is mkinitrd calls: When modules that > are part of initrds get replaced, you also want to update it the initrds I > guess. That's not too hard, really. We can use the same /sbin/new-kernel-pkg that the Fedora kernel uses: /sbin/new-kernel-pkg --mkinitrd --depmod --install %{KVERREL} ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jspaleta at gmail.com Thu Aug 18 20:55:58 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 18 Aug 2005 16:55:58 -0400 Subject: [Fedora-packaging] Kernel Module Packages In-Reply-To: <1124393238.2753.89.camel@localhost.localdomain> References: <200508181956.05154.agruen@suse.de> <1124393238.2753.89.camel@localhost.localdomain> Message-ID: <604aa79105081813553faa3152@mail.gmail.com> On 8/18/05, Tom 'spot' Callaway wrote: > We're doing this for user sanity as well, and to help differentiate > userspace packages from kernel-module packages. (Yum might be checking > for it as well, but I'm not the expert on that). Just FYI on my rawhide box, the current yum magic seems to be partly relying on packagename syntax and partly on provides syntax right now. Unless i've misread yum sniplet2 below. yum sniplet2 seems to say if the packagename starts with "kernel-module-" then handle it like a kernel module and check for an upgrade situation versus an install situation by looking at whether the required kernel version is installed already (see sniplet1). sniplet2 also says to check to see if the package is in the installonly list (see sniplet1). For kernel modules to be in the installonly list by default they need to provide "kernel-modules" according to sniplet0 from /usr/lib/python2.4/site-packages/yum/config.py ('installonlypkgs', ['kernel', 'kernel-bigmem', 'kernel-enterprise','kernel-smp', 'kernel-modules', 'kernel-debug', 'kernel-unsupported', 'kernel-source', 'kernel-devel']), Anything providing "kernel-modules" will be treated as installonly by default. >From /usr/lib/python2.4/site-packages/yum/depsolve.py on my rawhide box def allowedMultipleInstalls(self, po): """takes a packageObject, returns 1 or 0 depending on if the package should/can be installed multiple times with different vers like kernels and kernel modules, for example""" if po.name in self.conf.installonlypkgs: return 1 provides = po.getProvidesNames() if filter (lambda prov: prov in self.conf.installonlypkgs, provides): 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 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' txmbr.output_state = 'installing' -jef From jjneely at pams.ncsu.edu Thu Aug 18 21:35:34 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 18 Aug 2005 17:35:34 -0400 Subject: [Fedora-packaging] Kernel Module Packages In-Reply-To: <604aa79105081813553faa3152@mail.gmail.com> References: <200508181956.05154.agruen@suse.de> <1124393238.2753.89.camel@localhost.localdomain> <604aa79105081813553faa3152@mail.gmail.com> Message-ID: <1124400934.31789.54.camel@anduril.pams.ncsu.edu> Well...that's one way to summon me...post my code all over the internet. :-) The ideas and methods we had on the table a while back were...not always inline with each other. The information I had when I wrote that mess was that a kernel module package was deemed a kernel module package by having the %{name} kernel-module-. Providing kernel-modules seemed to have gotten lost. Then I became frustrated because folks kept making the specs more and more complex. Way too complex for sane package managers. Mostly the ways to get the packages not to generate source packages on each rebuild and crap. Secondly, in the Yum world we decided to start doing some big changes and I commited this bit. Then we thought better and decided to release 2.4.0 and do the big changes in 2.5.x. Hence, I should probably remove that code from the 2.4.x series. If we want kernel module packages to be successful they can't be that complex for the packager. Are there lots of special cases? You bet. Let the special cases be handled once in Yum code. Let the other special cases be handled once in Plague. Otherwise, each packager will do things ever so slightly different which leads to breakage. Not to mention how tired we will be of correcting and explaining. Jack On Thu, 2005-08-18 at 16:55 -0400, Jeff Spaleta wrote: > On 8/18/05, Tom 'spot' Callaway wrote: > > We're doing this for user sanity as well, and to help differentiate > > userspace packages from kernel-module packages. (Yum might be checking > > for it as well, but I'm not the expert on that). > > Just FYI on my rawhide box, the current yum magic seems to be partly > relying on packagename syntax and partly on provides syntax right now. > Unless i've misread yum sniplet2 below. > > yum sniplet2 seems to say if the packagename starts with > "kernel-module-" then handle it like a kernel module and check for an > upgrade situation versus an install situation by looking at whether > the required kernel version is installed already (see sniplet1). > sniplet2 also says to check to see if the package is in the > installonly list (see sniplet1). For kernel modules to be in the > installonly list by default they need to provide "kernel-modules" > according to sniplet0 > > > from /usr/lib/python2.4/site-packages/yum/config.py > > ('installonlypkgs', ['kernel', 'kernel-bigmem', > 'kernel-enterprise','kernel-smp', > 'kernel-modules', > 'kernel-debug', > 'kernel-unsupported', > 'kernel-source', 'kernel-devel']), > > > Anything providing "kernel-modules" will be treated as installonly by default. > > >From /usr/lib/python2.4/site-packages/yum/depsolve.py on my rawhide box > > def allowedMultipleInstalls(self, po): > """takes a packageObject, returns 1 or 0 depending on if the package > should/can be installed multiple times with different vers > like kernels and kernel modules, for example""" > > if po.name in self.conf.installonlypkgs: > return 1 > > provides = po.getProvidesNames() > if filter (lambda prov: prov in self.conf.installonlypkgs, provides): > 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 > > > > 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' > txmbr.output_state = 'installing' > > > -jef > > -- > 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 jspaleta at gmail.com Thu Aug 18 21:52:41 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 18 Aug 2005 17:52:41 -0400 Subject: [Fedora-packaging] Kernel Module Packages In-Reply-To: <1124400934.31789.54.camel@anduril.pams.ncsu.edu> References: <200508181956.05154.agruen@suse.de> <1124393238.2753.89.camel@localhost.localdomain> <604aa79105081813553faa3152@mail.gmail.com> <1124400934.31789.54.camel@anduril.pams.ncsu.edu> Message-ID: <604aa79105081814525df0e6a5@mail.gmail.com> On 8/18/05, Jack Neely wrote: > If we want kernel module packages to be successful they can't be that > complex for the packager. Are there lots of special cases? You bet. > Let the special cases be handled once in Yum code. Let the other > special cases be handled once in Plague. Otherwise, each packager will > do things ever so slightly different which leads to breakage. Not to > mention how tired we will be of correcting and explaining. I'm just trying to get this conversation moving forward again by making sure everyone is aware of where the current implementation stands. This particular issue seems to be forever stalled in a debate over where to start.. policy or tools. I'd hate to see this conversation frustrated further by an inaccurate accessment of current reality. If packagers provided "kernel-modules" the current magic in yum would work pretty well for most of the situations an end-user would care about. What are the real hold ups here... why isn't it good enough to make a policy decision that all Core and Extras module packages provide "kernel-modules" and be named "kernel-module-whatever" as a starting point to get some packages out? -jef From agruen at suse.de Thu Aug 18 22:16:29 2005 From: agruen at suse.de (Andreas Gruenbacher) Date: Fri, 19 Aug 2005 00:16:29 +0200 Subject: [Fedora-packaging] Kernel Module Packages In-Reply-To: <1124393238.2753.89.camel@localhost.localdomain> References: <200508181956.05154.agruen@suse.de> <1124393238.2753.89.camel@localhost.localdomain> Message-ID: <200508190016.29766.agruen@suse.de> On Thursday 18 August 2005 21:27, Tom 'spot' Callaway wrote: > On Thu, 2005-08-18 at 19:56 +0200, Andreas Gruenbacher wrote: > > We thought it useful to include a unique provider prefix in the package > > name though, so that different vendors won't produce name clashes. Our > > plan was to use the LANANA provider names registry > > (http://www.lanana.org/) for that. > > Ugh. I really don't want to cram everything and the kitchen sink into > the package name. I'd rather see the package check for a > SuSE/Fedora/Whatever only file on the system and use that to determine > if its in the right place or not. We also have dist tags for that > purpose in Fedora Extras. My example was not perfectly well chosen. The idea was to have provider prefixes like adaptec, nvidia, ati and similar, so an example out-of-line aic7xxx upgrade would be adaptec-aic7xxx-8.9.10-2.6.13_99_smp-3, etc. > > The driver name, driver version, and kernel release ($KERNELRELEASE) are > > also stored differently in rpm tags: our build system likes to be able to > > freely assign the package release number, so we don't store extra > > information there. Rather, we put the driver version in the Name, and the > > kernel release in the Version: > > Hmm. Again, I don't want to overload %{name}. That's not what its there > for, imho. What makes %version or %release more appropriate for overloading? With the driver version as part of %version or %release, you can't easily offer packages for more than one version of a driver for the same kernel, and yet have working updates. I would be surprised if you didn't ever have this situation with RHEL. -- Andreas. From tcallawa at redhat.com Thu Aug 18 23:00:57 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 18 Aug 2005 18:00:57 -0500 Subject: [Fedora-packaging] Kernel Module Packages In-Reply-To: <200508190016.29766.agruen@suse.de> References: <200508181956.05154.agruen@suse.de> <1124393238.2753.89.camel@localhost.localdomain> <200508190016.29766.agruen@suse.de> Message-ID: <1124406057.2753.105.camel@localhost.localdomain> On Fri, 2005-08-19 at 00:16 +0200, Andreas Gruenbacher wrote: > My example was not perfectly well chosen. The idea was to have provider > prefixes like adaptec, nvidia, ati and similar, so an example out-of-line > aic7xxx upgrade would be adaptec-aic7xxx-8.9.10-2.6.13_99_smp-3, etc. I don't see it serving any purpose. I don't want to have a field that people are trying to shoe-horning ugliness into. This just opens the door to rpms with horrible provider prefixes, and rpms with %{name}: InternationalBusinessMachinesJapanCOPYRIGHT2005ALLRIGHTSRESERVED-mwave-3.1415972-2.6.13_99_smp ... when all we really need is: kernel-module-mwave > > > The driver name, driver version, and kernel release ($KERNELRELEASE) are > > > also stored differently in rpm tags: our build system likes to be able to > > > freely assign the package release number, so we don't store extra > > > information there. Rather, we put the driver version in the Name, and the > > > kernel release in the Version: > > > > Hmm. Again, I don't want to overload %{name}. That's not what its there > > for, imho. > > What makes %version or %release more appropriate for overloading? With the > driver version as part of %version or %release, you can't easily offer > packages for more than one version of a driver for the same kernel, and yet > have working updates. I would be surprised if you didn't ever have this > situation with RHEL. Users won't expect to have the name be overloaded. Users want to search for "kernel-module-foo", query the rpmdb for kernel-module-foo. Not to mention the nightmare of tracking it in bugzilla, and generating massive amounts of unnecessary SRPMs. And we can certainly offer multiple packages. kernel-module-foo-1.2-1.2.6.13_93smp (driver version 1.2, build 1) kernel-module-foo-1.2-2.2.6.13_93smp (driver version 1.2, build 2) kernel-moudle-foo-1.3-1.2.6.13_93smp (driver version 1.3, build 1) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From agruen at suse.de Fri Aug 19 10:06:33 2005 From: agruen at suse.de (Andreas Gruenbacher) Date: Fri, 19 Aug 2005 12:06:33 +0200 Subject: [Fedora-packaging] Kernel Module Packages In-Reply-To: <1124406057.2753.105.camel@localhost.localdomain> References: <200508181956.05154.agruen@suse.de> <200508190016.29766.agruen@suse.de> <1124406057.2753.105.camel@localhost.localdomain> Message-ID: <200508191206.33971.agruen@suse.de> On Friday 19 August 2005 01:00, Tom 'spot' Callaway wrote: > On Fri, 2005-08-19 at 00:16 +0200, Andreas Gruenbacher wrote: > > My example was not perfectly well chosen. The idea was to have provider > > prefixes like adaptec, nvidia, ati and similar, so an example out-of-line > > aic7xxx upgrade would be adaptec-aic7xxx-8.9.10-2.6.13_99_smp-3, etc. > > I don't see it serving any purpose. I don't want to have a field that > people are trying to shoe-horning ugliness into. This just opens the > door to rpms with horrible provider prefixes, and rpms with %{name}: > > InternationalBusinessMachinesJapanCOPYRIGHT2005ALLRIGHTSRESERVED-mwave-3.14 >15972-2.6.13_99_smp > > ... when all we really need is: > > kernel-module-mwave Great, thanks for the thoughtful example. I was talking about a prefix from the LANANA provider name registry, http://lanana.org/lsbreg/providers/index.html, and I'm also aware that many potential providers don't have an entry there, yet. Also see http://lsbbook.gforge.freestandards.org/lanana.html about LSB's package naming recommendations. The two proposals, next to each other, and even for the same example, seem to be: Name: kernel-module-aic7xxx Version: 6.2.36 Release: 1.2.6.13_rc6_1_smp vs. Name: adaptec-aic7xxx-6.2.36 Version: 2.6.13_rc6_1_smp Release: 1 > > > > The driver name, driver version, and kernel release ($KERNELRELEASE) > > > > are also stored differently in rpm tags: our build system likes to be > > > > able to freely assign the package release number, so we don't store > > > > extra information there. Rather, we put the driver version in the > > > > Name, and the kernel release in the Version: > > > > > > Hmm. Again, I don't want to overload %{name}. That's not what its there > > > for, imho. > > > > What makes %version or %release more appropriate for overloading? With > > the driver version as part of %version or %release, you can't easily > > offer packages for more than one version of a driver for the same kernel, > > and yet have working updates. I would be surprised if you didn't ever > > have this situation with RHEL. > > Users won't expect to have the name be overloaded. Users want to search > for "kernel-module-foo", query the rpmdb for kernel-module-foo. Not to > mention the nightmare of tracking it in bugzilla, and generating massive > amounts of unnecessary SRPMs. Putting aside FUD for a second, where do you see problems querying the rpm database, or in Bugzilla? And why do you think the number of source rpms would change at all? > And we can certainly offer multiple packages. > > kernel-module-foo-1.2-1.2.6.13_93smp (driver version 1.2, build 1) > kernel-module-foo-1.2-2.2.6.13_93smp (driver version 1.2, build 2) > kernel-moudle-foo-1.3-1.2.6.13_93smp (driver version 1.3, build 1) You can have multiple packets next to each other, but rpm --freshen (and other tools using the same logic) won't work as expected anymore: you will always end up with the most recent driver version. Sticking with the same driver version by default will break. -- Andreas. From tcallawa at redhat.com Fri Aug 19 14:50:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 19 Aug 2005 09:50:19 -0500 Subject: [Fedora-packaging] Kernel Module Packages In-Reply-To: <200508191206.33971.agruen@suse.de> References: <200508181956.05154.agruen@suse.de> <200508190016.29766.agruen@suse.de> <1124406057.2753.105.camel@localhost.localdomain> <200508191206.33971.agruen@suse.de> Message-ID: <1124463019.5951.4.camel@localhost.localdomain> On Fri, 2005-08-19 at 12:06 +0200, Andreas Gruenbacher wrote: > Great, thanks for the thoughtful example. I was talking about a prefix from > the LANANA provider name registry, > http://lanana.org/lsbreg/providers/index.html, and I'm also aware that many > potential providers don't have an entry there, yet. You're presuming that third party entities will follow the letter of such a proposal, rather than attempting to cram garbage in (but stay in the spirit of the proposal). ACPI and DMA prove that conclusively incorrect. > Putting aside FUD for a second, where do you see problems querying the rpm > database, or in Bugzilla? What's the bugzilla entry? adaptec-aic7xxx-6.2.36? adaptec-aic7xxx-6.2.37? adaptec-aic7xxx-6.2.38? rpm -q adaptec-aic7xxx fails. Not only does the user need to know the driver name, they also need to remember the vendor. > And why do you think the number of source rpms > would change at all? Source rpms are generated from %{name}. By putting changing and unique variables in %{name}, you generate a LOT of srpms. > > And we can certainly offer multiple packages. > > > > kernel-module-foo-1.2-1.2.6.13_93smp (driver version 1.2, build 1) > > kernel-module-foo-1.2-2.2.6.13_93smp (driver version 1.2, build 2) > > kernel-moudle-foo-1.3-1.2.6.13_93smp (driver version 1.3, build 1) > > You can have multiple packets next to each other, but rpm --freshen (and other > tools using the same logic) won't work as expected anymore: you will always > end up with the most recent driver version. Sticking with the same driver > version by default will break. We've fixed the tools (specifically yum) to handle this condition. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jjneely at pams.ncsu.edu Fri Aug 19 17:33:39 2005 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Fri, 19 Aug 2005 13:33:39 -0400 Subject: [Fedora-packaging] Kernel Module Packages In-Reply-To: <604aa79105081814525df0e6a5@mail.gmail.com> References: <200508181956.05154.agruen@suse.de> <1124393238.2753.89.camel@localhost.localdomain> <604aa79105081813553faa3152@mail.gmail.com> <1124400934.31789.54.camel@anduril.pams.ncsu.edu> <604aa79105081814525df0e6a5@mail.gmail.com> Message-ID: <1124472819.1376.24.camel@anduril.pams.ncsu.edu> > I'm just trying to get this conversation moving forward again by > making sure everyone is aware of where the current implementation > stands. This particular issue seems to be forever stalled in a > debate over where to start.. policy or tools. I'd hate to see this Well, we've got a small bit of the functionality in Yum working...if oddly. I don't mind doing that work but we need some idea of policy that I can code to. :-) > conversation frustrated further by an inaccurate accessment of current > reality. If packagers provided "kernel-modules" the current magic in > yum would work pretty well for most of the situations an end-user > would care about. What are the real hold ups here... why isn't it > good enough to make a policy decision that all Core and Extras module > packages provide "kernel-modules" and be named > "kernel-module-whatever" as a starting point to get some packages out? > How I would like things to be: Kernel module packages MUST provide "kernel-modules". Not "kernel-module". This keeps in line with previous work and already existing code. This provides will identify to Yum/Plague/Whatever that this package is a kernel module and needs special treatment. Kernel module packages MUST require kernel-%{_targetcpu} = ${kver}. This identifies to Yum what kernel this module works with and will identify other kernel module packages that need to be removed. The release tag will be .%{?kver:.%(echo %{kver} | tr - _)} or something along those lines. This provides no information to Yum/Plague but gives the package a unique EVR. Its really hard to correctly parse information like a kernel version out of the release tag. I really don't like the kernel-module-foo-source base package that produces a subpackage of kernel-module-foo. This adds way to much complexity. The goal here, IIRC, is to be able to have one src.rpm for all the times that the kernel-module-foo has been rebuilt for each kernel version/flavor. Being that the release tag already contains a lot of our magic I suggest we make the release tag be the following. Release: [release]%{!?sourcepackage:%(echo .%{kver} | tr - _)} where [release] is the packager's release number of the package. With this idea we ignore/delete all srpms that are created with rebuilds of the kerenl-module-foo package. To generate the official srpm the build system does: rpmbuild -bs kernel-module-foo.spec [defines] \ --define "sourcepackage 1" [targets] If this srpm already exists in the repository then ignore it. Otherwise, you have a new version of the kernel module itself rather than just 15 hundred rebuilds of it. Jack > -jef > > -- > 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 jamatos at fc.up.pt Sat Aug 20 16:27:11 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 20 Aug 2005 17:27:11 +0100 Subject: [Fedora-packaging] PDFlib-Lite license Message-ID: <200508201727.12078.jamatos@fc.up.pt> Hi, I am starting the process of submitting grace to extras. One of its dependencies is PDFlib-Lite. The FAQ of the license is here: http://www.pdflib.com/purchase/license-lite.html The license itself is here: http://www.pdflib.com/products/pdflib/info/PDFlib-Lite-license.pdf Is this within the boundaries of extras? -- Jos? Ab?lio Matos From ivazquez at ivazquez.net Sat Aug 20 16:36:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 20 Aug 2005 12:36:00 -0400 Subject: [Fedora-packaging] PDFlib-Lite license In-Reply-To: <200508201727.12078.jamatos@fc.up.pt> References: <200508201727.12078.jamatos@fc.up.pt> Message-ID: <1124555760.3414.4.camel@ignacio.lan> On Sat, 2005-08-20 at 17:27 +0100, Jose' Matos wrote: > Hi, > I am starting the process of submitting grace to extras. One of its > dependencies is PDFlib-Lite. > > The FAQ of the license is here: > http://www.pdflib.com/purchase/license-lite.html > > The license itself is here: > http://www.pdflib.com/products/pdflib/info/PDFlib-Lite-license.pdf > > Is this within the boundaries of extras? Commercial use is restricted. -1 -- 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 jamatos at fc.up.pt Sat Aug 20 18:49:15 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 20 Aug 2005 19:49:15 +0100 Subject: [Fedora-packaging] PDFlib-Lite license In-Reply-To: <1124555760.3414.4.camel@ignacio.lan> References: <200508201727.12078.jamatos@fc.up.pt> <1124555760.3414.4.camel@ignacio.lan> Message-ID: <200508201949.15232.jamatos@fc.up.pt> On Saturday 20 August 2005 17:36, Ignacio Vazquez-Abrams wrote: > > Commercial use is restricted. -1 I think that I will do as debian, they have pdf support turned off. As you can see here, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216856 , "(since PDFLib is not entirely free)". -- Jos? Ab?lio Matos From tcallawa at redhat.com Mon Aug 22 15:58:06 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 22 Aug 2005 10:58:06 -0500 Subject: [Fedora-packaging] PDFlib-Lite license In-Reply-To: <1124555760.3414.4.camel@ignacio.lan> References: <200508201727.12078.jamatos@fc.up.pt> <1124555760.3414.4.camel@ignacio.lan> Message-ID: <1124726286.11712.5.camel@nibbler> On Sat, 2005-08-20 at 12:36 -0400, Ignacio Vazquez-Abrams wrote: > On Sat, 2005-08-20 at 17:27 +0100, Jose' Matos wrote: > > Hi, > > I am starting the process of submitting grace to extras. One of its > > dependencies is PDFlib-Lite. > > > > The FAQ of the license is here: > > http://www.pdflib.com/purchase/license-lite.html > > > > The license itself is here: > > http://www.pdflib.com/products/pdflib/info/PDFlib-Lite-license.pdf > > > > Is this within the boundaries of extras? > > Commercial use is restricted. -1 Yeah, unfortunately, because of the usage restriction, we can't include it in Extras. Sorry. ~spot From fedora at leemhuis.info Tue Aug 23 05:47:53 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 Aug 2005 07:47:53 +0200 Subject: [Fedora-packaging] kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4) In-Reply-To: <1124774329.16972.75.camel@cutter> References: <1124533070.8272.22.camel@localhost.localdomain> <1124774329.16972.75.camel@cutter> Message-ID: <1124776073.30231.15.camel@thl.ct.heise.de> CC fedora-packaging because this concerns kernel-module-packaging Am Dienstag, den 23.08.2005, 01:18 -0400 schrieb seth vidal: > On Sat, 2005-08-20 at 12:17 +0200, Thorsten Leemhuis wrote: > > Am Freitag, den 19.08.2005, 21:40 -0400 schrieb Dan Williams: > > > Quite a few things will change for plague 0.4: > > > [...] > > > If anyone has more thoughts, file some RFEs in bugzilla for Fedora Extras > > > Infrastructure. > > > > What is the current status of passing special options to the actual > > rpmbuild call? We should have those for building kernel-modules because > > building kernel-modules for a lot of different kernels would be much > > easier if no changes to the actual kernel-module-specfile are needed. In > > the current KernelModuleProposal-Example2 (*1) this is realized by: > > > > %{!?kver: %define kver %(uname -r)} > > [...] > > make KVERS=%{kver} KSRC="%{_usrsrc}/kernels/%{kver}-%{_target_cpu}" -C driver > > > > So if someone builds the src.rpm at home it is rebuild for the current > > kernel. When build with mock the buildsystem should defined kver. > > Something like: > > > > for kernel in > > do > > mock build /path/to/srpm --define "kver $kernel" > > done > > > > AFACS we need support for this in both mock and plague (or is something > > like that already possible? mach can pass options to rpmbuild, mock > > can't iirc) > > I do not think that adding this into mock or rpmbuild is a good idea, > honestly. For other packages I agree. Kernel-modules should be a exception IMHO. > If the package won't built w/o arbitrary defines then we'll > have a devil of a time figuring out how to REBUILD it later. It builds for the normal user without arbitrary defines. And even better: It automatically builds what you probably want, because with the above it builds the kernel-module for the currently running kernel. If you get a random kernel-module.src.rpm where kver ist hardcoded you have to edit it each time to get compile against a new kernel. BTW, this is in all three proposals in http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal If we all agree that we don't like passing arguments to rpmbuild then we should restart the kernel-module-discussion on fedora-packaging. CU thl From skvidal at phy.duke.edu Tue Aug 23 05:59:27 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 23 Aug 2005 01:59:27 -0400 Subject: [Fedora-packaging] Re: kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4) In-Reply-To: <1124776073.30231.15.camel@thl.ct.heise.de> References: <1124533070.8272.22.camel@localhost.localdomain> <1124774329.16972.75.camel@cutter> <1124776073.30231.15.camel@thl.ct.heise.de> Message-ID: <1124776767.16972.88.camel@cutter> > For other packages I agree. Kernel-modules should be a exception IMHO. I worry that having them as the exception means we have to do the code anyway which makes it a slippery-damn-slope to all packages using arbitrary defines. > It builds for the normal user without arbitrary defines. And even > better: It automatically builds what you probably want, because with the > above it builds the kernel-module for the currently running kernel. If > you get a random kernel-module.src.rpm where kver ist hardcoded you have > to edit it each time to get compile against a new kernel. > why doesn't it automatically build for whatever the highest installed kernel-devel or highest installed kernel package is? -sv From fedora at leemhuis.info Tue Aug 23 06:27:09 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 Aug 2005 08:27:09 +0200 Subject: [Fedora-packaging] Re: kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4) In-Reply-To: <1124776767.16972.88.camel@cutter> References: <1124533070.8272.22.camel@localhost.localdomain> <1124774329.16972.75.camel@cutter> <1124776073.30231.15.camel@thl.ct.heise.de> <1124776767.16972.88.camel@cutter> Message-ID: <1124778429.30231.40.camel@thl.ct.heise.de> Am Dienstag, den 23.08.2005, 01:59 -0400 schrieb seth vidal: > > For other packages I agree. Kernel-modules should be a exception IMHO. > > I worry that having them as the exception means we have to do the code > anyway which makes it a slippery-damn-slope to all packages using > arbitrary defines. :) > > It builds for the normal user without arbitrary defines. And even > > better: It automatically builds what you probably want, because with the > > above it builds the kernel-module for the currently running kernel. If > > you get a random kernel-module.src.rpm where kver ist hardcoded you have > > to edit it each time to get compile against a new kernel. > > > why doesn't it automatically build for whatever the highest installed > kernel-devel or highest installed kernel package is? And who decides when a module for a smp-kernel is build and when not? Doing this with %build buildfunc() { make something } %ifarch i686 x86_64 ppc build up build smp %else build up %endif in the spec is really ugly (and not possible with our current scheme afaics -- need to try, but i suspect it won't work). CU thl From Matt_Domsch at dell.com Tue Aug 23 19:55:38 2005 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 23 Aug 2005 14:55:38 -0500 Subject: [Fedora-packaging] Re: kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4) In-Reply-To: <1124776767.16972.88.camel@cutter> References: <1124533070.8272.22.camel@localhost.localdomain> <1124774329.16972.75.camel@cutter> <1124776073.30231.15.camel@thl.ct.heise.de> <1124776767.16972.88.camel@cutter> Message-ID: <20050823195538.GA7861@lists.us.dell.com> On Tue, Aug 23, 2005 at 01:59:27AM -0400, seth vidal wrote: > why doesn't it automatically build for whatever the highest installed > kernel-devel or highest installed kernel package is? One of the problems is that the build system doesn't know what kernels an end user may be running. Therefore, you've got to a) be able to have the end user rebuild for whatever kernel they're running (easy, works that way today) b) if the driver is needed at install time, the build system needs to provide pre-builts for the installer (and CD media) kernel. (optionally) c) have the build system build binaries for each of the released errata kernels too, so you don't require a kernel upgrade in order to get a given module that matches. I'm not sure how optional c) really is though. Depends on how easy you want to make life for your system administrators to not have to do a) themselves all the time. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com