From skvidal at phy.duke.edu Mon Feb 21 19:48:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 14:48:40 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109013540.10854.77.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> Message-ID: <1109015320.16633.59.camel@opus.phy.duke.edu> On Mon, 2005-02-21 at 13:19 -0600, Tom 'spot' Callaway wrote: > On Mon, 2005-02-21 at 14:05 -0500, seth vidal wrote: > > >we might be able to do something like: > >if two kernel modules have the same name but different versions then > >it's an update. > > > >that would require: > > - kernel-version-in-module-package-name > > - provides: kernel-module in the header > > - consistent use. > > I think that's doable. Lets take this thread over here: > https://www.redhat.com/mailman/listinfo/fedora-packaging Right now yum does the following: if it is a kernel or kernel module (ie provides kernel or provides kernel-modules) then the package is installed not updated. if we can come up with a consistent pattern for when a kernel-module will be updated but not installed then I can add it into the function that determines that sort of stuff. Right now I'm thinking: kernel modules must have kernel-version-release in the package name for the kernel module - this makes for irritating package naming and cvs naming but if a kernel-module has a new version available then it should be updated, not installed. else - kernel modules are installed. Now - how do we go about getting kernel modules pulled in when new kernels come out. Clearly it can't be via an update b/c the package name will change, so yum won't notice it as an update. Doing it via obsoletes is just yucky. We need something like a kernel-module registry. So we can track kernel-modules you have installed by something OTHER than package name. Thoughts? -sv From tcallawa at redhat.com Mon Feb 21 20:04:06 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 14:04:06 -0600 Subject: [Fedora-packaging] Introduction Message-ID: <1109016246.10854.91.camel@localhost.localdomain> Howdy! I'm the sucker who volunteered to head up RPM Standards and Practices for Fedora Extras. I'd like to make a few things clear, before we get to the good stuff: Check your egos at the door. If all you feel like doing is posturing, flaming, or mocking, this is NOT the list to do it in (I hear fedora-list is nice this time of year). If I think you're being more of a nuisance than an asset, I will warn you, then kick you off the list if you continue. I hope it doesn't come to that. Keep an open mind, and back up your opinions. Disagree, but do so politely. Be patient with me. I have a wife, a linux distribution, and a full time job that has nothing to do with Fedora Extras. I wasn't involved in the fedora.us period, so don't assume I know anything. I am not interested in overhauling the existing RPM standards and practices. My task is to identify and document the existing standards and practices, highlight problems in the Fedora Extras packaging world, get them solved in a maintainable fashion. Thanks in advance for your help and time, ~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 Mon Feb 21 20:19:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 14:19:19 -0600 Subject: kernel-module packaging (was Re: [Fedora-packaging] Re: DKMS into Fedora Extras) In-Reply-To: <1109015320.16633.59.camel@opus.phy.duke.edu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> Message-ID: <1109017159.10854.105.camel@localhost.localdomain> For clarity sake, let me state the problem as I see it first: PROBLEM: Kernel modules not in Fedora Core's kernel packages are difficult to package, track, and upgrade, due to dependency issues and the assumption of multiple kernels. To repeat Seth, right now, if it is a kernel or kernel module (ie provides kernel or provides kernel-modules) then the package is installed not updated. If we can come up with a consistent pattern for when a kernel-module will be updated but not installed then yum can get the added logic to deal with this case. So, what should happen with all of these cases? Case 1: kernel-2.6.10-3_FC3 installed. User runs: "yum install kernel-module-unionfs" to get the unionfs module RPM for kernel-2.6.10-3_FC3. Case 2: kernel-2.6.10-3_FC3, kernel-2.6.10-4_FC3, and kernel-2.6.10-5_FC3 are installed. User runs: "yum install kernel-module-unionfs" to get the unionfs module RPM for all installed kernels. (I think it is safe to assume that if a user has multiple kernels installed that they would like an addon kernel module to be installed for all of them) Case 3: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 are installed. User runs: "yum update kernel-module-unionfs" (either implicitly, or as part of a generic update all), and kernel-module-unionfs-2.6.10_3_FC3-2 exists in Fedora Extras. Case 4: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 are installed. User runs: "yum update kernel" (either implicitly, or as part of a generic update all), and both kernel-2.6.10-4_FC3 kernel-module-unionfs-2.6.10_4_FC3-1 exists in Fedora Extras. ~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 cra at WPI.EDU Mon Feb 21 20:41:38 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Mon, 21 Feb 2005 15:41:38 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109015320.16633.59.camel@opus.phy.duke.edu> References: <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> Message-ID: <20050221204138.GA5061@angus.ind.WPI.EDU> On Mon, Feb 21, 2005 at 02:48:40PM -0500, seth vidal wrote: > Right now I'm thinking: > kernel modules must have kernel-version-release in the package name for > the kernel module - this makes for irritating package naming and cvs > naming but > > if a kernel-module has a new version available then it should be > updated, not installed. > else - kernel modules are installed. I think that adding the kernel version-release to the package name of the kernel-module-foo packages is a bad idea. I think it would be better to have the kernel-module-foo actual version-release tag be the same as the corresponding kernel version-release tag. Then you could just parallel install the kernel-module-foo packages in the same way that the kernel is parallel installed. > Now - how do we go about getting kernel modules pulled in when new > kernels come out. Clearly it can't be via an update b/c the package name > will change, so yum won't notice it as an update. Doing it via obsoletes > is just yucky. We need something like a kernel-module registry. So we > can track kernel-modules you have installed by something OTHER than > package name. Using a package name that never changes would avoid this problem... Of course, then we have a problem if you want to update a kernel module without updating the corresponding kernel package. Would this happen that often? From tcallawa at redhat.com Mon Feb 21 20:48:44 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 14:48:44 -0600 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <20050221204138.GA5061@angus.ind.WPI.EDU> References: <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> Message-ID: <1109018925.10854.127.camel@localhost.localdomain> On Mon, 2005-02-21 at 15:41 -0500, Chuck R. Anderson wrote: >I think that adding the kernel version-release to the package name of >the kernel-module-foo packages is a bad idea. I think it would be >better to have the kernel-module-foo actual version-release tag be the >same as the corresponding kernel version-release tag. Then you could >just parallel install the kernel-module-foo packages in the same way >that the kernel is parallel installed. Give me an example for both cases (the case you don't like and the case that you do)? >Using a package name that never changes would avoid this problem... Package name? Or package version? These things exist to identify the package, not so we can work around gaps in our infrastructure. >Of course, then we have a problem if you want to update a kernel >module without updating the corresponding kernel package. Would this >happen that often? Assume it will. :) ~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 Mon Feb 21 22:46:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 17:46:56 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109018925.10854.127.camel@localhost.localdomain> References: <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> Message-ID: <1109026016.24448.16.camel@opus.phy.duke.edu> > Assume it will. :) > assume nothing, it happens. that's why this bug came up at all. -sv From cra at WPI.EDU Tue Feb 22 00:47:52 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Mon, 21 Feb 2005 19:47:52 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109018925.10854.127.camel@localhost.localdomain> References: <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> Message-ID: <20050222004752.GH5061@angus.ind.WPI.EDU> On Mon, Feb 21, 2005 at 02:48:44PM -0600, Tom 'spot' Callaway wrote: > >I think that adding the kernel version-release to the package name of > >the kernel-module-foo packages is a bad idea. I think it would be > >better to have the kernel-module-foo actual version-release tag be the > >same as the corresponding kernel version-release tag. Then you could > >just parallel install the kernel-module-foo packages in the same way > >that the kernel is parallel installed. > > Give me an example for both cases (the case you don't like and the case > that you do)? I don't like this: Name: kernel-module-unionfs-2.6.10-3_FC3 Version: 1.0.9 Release: 15 because it requires special magic in the depsolver to pull in specially named packages when kernels get installed/erased. It is a bad idea to start parsing out parts of a package name. I would also think that it would require the user to do things like "yum install kernel-module-unionfs-2.6.10-3_FC3" which is ugly. I was contemplating this: Name: kernel-module-unionfs Version: 2.6.10 Release: 3_FC3 but that causes the problem below: > >Of course, then we have a problem if you want to update a kernel > >module without updating the corresponding kernel package. Would this > >happen that often? > > Assume it will. :) So, how about we completely divorce the module version number from the kernel version number, since you basically want to be able to update, build, and evolve them separately, and the "version" of an external kernel module doesn't really have any relation to a kernel version-release anyway: Name: kernel-module-unionfs Version: 1.0.9 Release: 15 But you probably still want to stick some info about which kernel each build of the kernel-module package is built against (purely cosmetic, NOT to be used programmatically by depsolvers). Usually the Release: field is used for this purpose. This also gets us unique EVR's which IIRC we need for parallel-installable packages: Name: kernel-module-unionfs Version: 1.0.9 Release: 2.6.10_3_FC3.15 The depsolvers would rely solely on Provides/Requires deps: Name: kernel-module-unionfs Version: 1.0.9 Release: 2.6.10_3_FC3.15 Requires: kernel = 2.6.10-3_FC3 exactarch's would have to be matched, of course. smp is fine, because kernel-smp provides kernel-smp: Name: kernel-module-smp-unionfs Version: 1.0.9 Release: 2.6.10_3_FC3.15 Requires: kernel-smp = 2.6.10-3_FC3 So now lets go through the cases: > Case 1: kernel-2.6.10-3_FC3 installed. User runs: "yum install > kernel-module-unionfs" to get the unionfs module RPM for > kernel-2.6.10-3_FC3. yum notices that kernel-module-unionfs is multiple-installable. It finds that it can only satisfy the deps with kernel-module-unionfs-1.0.9-2.6.10-3_FC3. Since kernel is i686, it installs kernel-module-unionfs-1.0.9-2.6.10-3_FC3.i686. > Case 2: kernel-2.6.10-3_FC3, kernel-2.6.10-4_FC3, and > kernel-2.6.10-5_FC3 are installed. User runs: "yum install > kernel-module-unionfs" to get the unionfs module RPM for all > installed kernels. (I think it is safe to assume that if a user has > multiple kernels installed that they would like an addon kernel > module to be installed for all of them) yum notices that kernel-module-unionfs is multiple-installable. It finds all the matching kernel-module-unionfs-* packages whose deps can be satisfied with the existing installed packages *that are multiple-installable*. If there are multiple install candidates within each Provides: N = E:V-R of installed multiple-installable packages, it picks the one with the highest EVR (to handle updated kernel-module-foo pacakges). If the mechanism for signaling multiple-installable is the same as the current installonlypkgs= (would be advantageous to use pre-existing config statements wherever possible IMO), then one might think that this would make "yum install kernel" install all available kernels, too. If this is undesired, you can make yum require that there exist at least one Require: on another multiple-install package in order to invoke the special muliple-install behavior. Otherwise, standard install behavior is used. > Case 3: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 > are installed. User runs: "yum update kernel-module-unionfs" (either > implicitly, or as part of a generic update all), and > kernel-module-unionfs-2.6.10_3_FC3-2 exists in Fedora Extras. To clarify for my naming convention, if these are installed: kernel-2.6.10-3_FC3 kernel-module-unionfs-1.0.9-2.6.10_3_FC3.15 And this exists in Extras: kernel-module-unionfs-1.0.9-2.6.10_3_FC3.16 (Requires: kernel = 2.6.10-3_FC3) yum notices that there is more than candidate that satisfies the dep kernel-module-unionfs Requires kernel = 2.6.10-3_FC3, where both "kernel-module-unionfs" and "kernel" are marked multiple-installable. It picks the highest EVR on the repo, in this case 1.0.9-2.6.10_3_FC3.16. > Case 4: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 > are installed. User runs: "yum update kernel" (either implicitly, or > as part of a generic update all), and both kernel-2.6.10-4_FC3 > kernel-module-unionfs-2.6.10_4_FC3-1 exists in Fedora Extras. If these are installed: kernel-2.6.10-3_FC3 kernel-module-unionfs-1.0.9-2.6.10_3_FC3.15 And these exist in Extras: kernel-2.6.10-4_FC3 kernel-module-unionfs-1.0.9-2.6.10_4_FC3.15 (Requires: kernel = 2.6.10-4_FC3) yum notices that there are newer packages available that are multiple-installable. The first one, kernel, doesn't have any Requires: on any other multiple-installable packages, so it just installs (not updates) it as usual. The second one, kernel-module-unionfs, does have a Requires: on a multiple-installable package (kernel). yum proceeds as in Case 1 or Case 3. How does this sound? I think this should just "do the right thing" without any more configuration than the existing "installonlypkgs=" we have today. From tcallawa at redhat.com Tue Feb 22 02:44:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 20:44:19 -0600 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <20050222004752.GH5061@angus.ind.WPI.EDU> References: <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> Message-ID: <1109040260.31372.3.camel@localhost.localdomain> On Mon, 2005-02-21 at 19:47 -0500, Chuck R. Anderson wrote: >How does this sound? I think this should just "do the right thing" >without any more configuration than the existing "installonlypkgs=" we >have today. It seems reasonable to me, Seth, what do you think? ~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 Tue Feb 22 04:01:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 23:01:05 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109040260.31372.3.camel@localhost.localdomain> References: <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> Message-ID: <1109044865.28235.25.camel@cutter> On Mon, 2005-02-21 at 20:44 -0600, Tom 'spot' Callaway wrote: >On Mon, 2005-02-21 at 19:47 -0500, Chuck R. Anderson wrote: > >>How does this sound? I think this should just "do the right thing" >>without any more configuration than the existing "installonlypkgs=" we >>have today. > >It seems reasonable to me, Seth, what do you think? > I think it still leaves in a bad place for when a kernel module is updated w/o changing kernel versions. if you have: kernel-module ver=1.0.9 release=2.6.10-1ac-15 and an update which is: kernel-module ver=1.1.0 release=2.6.10-1ac-15 so the kernel module has changed version - but not kernel. so it really, actually, needs to be updated. which isn't a problem - except that b/c the pkg name is the same - an update will remove ALL the older versions for that package. so if you have: kernel-module ver=1.0.9 release=2.6.9-1ac-15 installed - then that goes away on an update. Maybe I missed it but I'm not sure how his proposal solves for that case. -sv From tcallawa at redhat.com Tue Feb 22 04:20:32 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 21 Feb 2005 22:20:32 -0600 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109044865.28235.25.camel@cutter> References: <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> Message-ID: <1109046033.31372.10.camel@localhost.localdomain> On Mon, 2005-02-21 at 23:01 -0500, seth vidal wrote: >Maybe I missed it but I'm not sure how his proposal solves for that >case. Wouldn't this be true for kernel too? $name remains the same, yet older kernels are not removed on update. ~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 Tue Feb 22 04:28:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 23:28:51 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109046033.31372.10.camel@localhost.localdomain> References: <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <1109046033.31372.10.camel@localhost.localdomain> Message-ID: <1109046531.28235.34.camel@cutter> On Mon, 2005-02-21 at 22:20 -0600, Tom 'spot' Callaway wrote: >On Mon, 2005-02-21 at 23:01 -0500, seth vidal wrote: > >>Maybe I missed it but I'm not sure how his proposal solves for that >>case. > >Wouldn't this be true for kernel too? $name remains the same, yet older >kernels are not removed on update. kernels are never updated. ever. -sv From skvidal at phy.duke.edu Tue Feb 22 04:51:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 21 Feb 2005 23:51:45 -0500 Subject: kernel-module packaging (was Re: [Fedora-packaging] Re: DKMS into Fedora Extras) In-Reply-To: <1109017159.10854.105.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <1109017159.10854.105.camel@localhost.localdomain> Message-ID: <1109047905.28235.41.camel@cutter> A couple of items to mention: new kernels in fc4 should have: Provides: kernel-%{arch} = ver-rel in them now. so kernel-modules should definitely dep on: kernel-%{arch} so we don't get any arch mixups b/t kernels and kernel-modules. -sv From pmatilai at welho.com Tue Feb 22 06:20:43 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 22 Feb 2005 08:20:43 +0200 (EET) Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109044865.28235.25.camel@cutter> References: <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> Message-ID: On Mon, 21 Feb 2005, seth vidal wrote: > I think it still leaves in a bad place for when a kernel module is > updated w/o changing kernel versions. > > if you have: > kernel-module > ver=1.0.9 > release=2.6.10-1ac-15 > > and an update which is: > kernel-module > ver=1.1.0 > release=2.6.10-1ac-15 > > so the kernel module has changed version - but not kernel. > > so it really, actually, needs to be updated. > > which isn't a problem - except that b/c the pkg name is the same - an > update will remove ALL the older versions for that package. > > so if you have: > kernel-module > ver=1.0.9 > release=2.6.9-1ac-15 > > installed - then that goes away on an update. > > Maybe I missed it but I'm not sure how his proposal solves for that > case. I don't see it solving that either. Nobody *likes* those kernel-module-foo-2.6.10-1.741_FC3 type names but nobody has come up with a solution which covers all the cases without the kernel version in package name. Oh and I think special name-based hacks are required for this anyway... and I seriously doubt you want those in yum proper. If I understood correctly the Xtrigger-stuff should allow pushing the special kernel-module handling to a separate script/module and enabled only where needed, somewhat like my apt lua-script which handles (or at least tries to :) this mess. - Panu - From skvidal at phy.duke.edu Tue Feb 22 06:26:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 22 Feb 2005 01:26:37 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: References: <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> Message-ID: <1109053597.28235.65.camel@cutter> >I don't see it solving that either. Nobody *likes* those >kernel-module-foo-2.6.10-1.741_FC3 type names but nobody has come up with >a solution which covers all the cases without the kernel version in >package name. Oh and I think special name-based hacks are required for >this anyway... and I seriously doubt you want those in yum proper. > >If I understood correctly the Xtrigger-stuff should allow pushing the >special kernel-module handling to a separate script/module and enabled >only where needed, somewhat like my apt lua-script which handles (or >at least tries to :) this mess. We could spawn things out of xtrigger -however xtrigger will play hell with a gui front end for output reasons. thoughts? -sv From ville.skytta at iki.fi Tue Feb 22 07:13:06 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 22 Feb 2005 09:13:06 +0200 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109015320.16633.59.camel@opus.phy.duke.edu> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> Message-ID: <1109056386.6386.291.camel@bobcat.mine.nu> On Mon, 2005-02-21 at 14:48 -0500, seth vidal wrote: > Right now I'm thinking: > kernel modules must have kernel-version-release in the package name for > the kernel module - this makes for irritating package naming and cvs > naming but I support this because I haven't seen a better solution. But IMO the CVS naming is a no go. There should be one dir per one module package in CVS, not one for each module package for a specific kernel, otherwise it's a major PITA to maintain. I imagine it isn't too hard to achieve that. From fedora at leemhuis.info Tue Feb 22 07:34:07 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 22 Feb 2005 08:34:07 +0100 Subject: kernel-module packaging (was Re: [Fedora-packaging] Re: DKMS into Fedora Extras) In-Reply-To: <1109017159.10854.105.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <1109017159.10854.105.camel@localhost.localdomain> Message-ID: <1109057647.5046.13.camel@thl.ct.heise.de> Am Montag, den 21.02.2005, 14:19 -0600 schrieb Tom 'spot' Callaway: > For clarity sake, let me state the problem as I see it first: > So, what should happen with all of these cases? [...] > Case 4: kernel-2.6.10-3_FC3 and kernel-module-unionfs-2.6.10_3_FC3-1 are > installed. User runs: "yum update kernel" (either implicitly, or as part > of a generic update all), and both kernel-2.6.10-4_FC3 > kernel-module-unionfs-2.6.10_4_FC3-1 exists in Fedora Extras. Case 4.1: What if kernel-module-unionfs-2.6.10_4_FC3-1 is released one/two days behind kernel-2.6.10-3_FC3? This can happen due to build errors that first need to get fixed. Or the build system or all that have access are sleeping. Or simply due due mirroring "problems" when core/updates/ is already mirrored, but extras/ not yet. CU thl From tcallawa at redhat.com Tue Feb 22 13:28:09 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Feb 2005 07:28:09 -0600 Subject: kernel-module packaging (was Re: [Fedora-packaging] Re: DKMS into Fedora Extras) In-Reply-To: <1109057647.5046.13.camel@thl.ct.heise.de> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <1109017159.10854.105.camel@localhost.localdomain> <1109057647.5046.13.camel@thl.ct.heise.de> Message-ID: <1109078890.31372.27.camel@localhost.localdomain> On Tue, 2005-02-22 at 08:34 +0100, Thorsten Leemhuis wrote: >Case 4.1: What if kernel-module-unionfs-2.6.10_4_FC3-1 is released >one/two days behind kernel-2.6.10-3_FC3? This can happen due to build >errors that first need to get fixed. Or the build system or all that >have access are sleeping. Or simply due due mirroring "problems" when >core/updates/ is already mirrored, but extras/ not yet. That's a valid point, since the kernel package doesn't depend on kernel-module-*. Anyone have any idea how to work around this in a sane manner? ~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 cra at WPI.EDU Tue Feb 22 14:11:48 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Tue, 22 Feb 2005 09:11:48 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109044865.28235.25.camel@cutter> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> Message-ID: <20050222141148.GB15948@angus.ind.WPI.EDU> On Mon, Feb 21, 2005 at 11:01:05PM -0500, seth vidal wrote: > so the kernel module has changed version - but not kernel. > so it really, actually, needs to be updated. > > which isn't a problem - except that b/c the pkg name is the same - an > update will remove ALL the older versions for that package. > > so if you have: > kernel-module > ver=1.0.9 > release=2.6.9-1ac-15 > > installed - then that goes away on an update. > > Maybe I missed it but I'm not sure how his proposal solves for that > case. I think you missed my logic for this case. If there would be an update for a kernel-module, and the update has the same Requires: as an existing installed kernel-module of the same name, then replace the installed one with the new one, but don't touch any others that have Requires: for a different kernel. Repeat for each kernel version. In other words, you limit updates to within the universe of each distinct Requires: on another multiple-installable package, so that you don't wipe out the other parallel installations. From skvidal at phy.duke.edu Tue Feb 22 15:00:04 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 22 Feb 2005 10:00:04 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <20050222141148.GB15948@angus.ind.WPI.EDU> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> Message-ID: <1109084404.15038.0.camel@opus.phy.duke.edu> > I think you missed my logic for this case. If there would be an > update for a kernel-module, and the update has the same Requires: as > an existing installed kernel-module of the same name, then replace the > installed one with the new one, but don't touch any others that have > Requires: for a different kernel. and I think you missed my point: rpm can't do that. it doesn't just update a single older version - it updates ALL older versions. -sv From tcallawa at redhat.com Tue Feb 22 15:18:32 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Feb 2005 09:18:32 -0600 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109084404.15038.0.camel@opus.phy.duke.edu> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> Message-ID: <1109085512.31372.57.camel@localhost.localdomain> On Tue, 2005-02-22 at 10:00 -0500, seth vidal wrote: >> I think you missed my logic for this case. If there would be an >> update for a kernel-module, and the update has the same Requires: as >> an existing installed kernel-module of the same name, then replace the >> installed one with the new one, but don't touch any others that have >> Requires: for a different kernel. > >and I think you missed my point: >rpm can't do that. OK, so if rpm isn't smart enough to do that, can we teach yum to deal with this case? If new package is of type "foo" (where foo is kernel-module in this case), check for existing installed package of the same name. If exists, rpm -e existing, then rpm -ivh new package. (yes, i realize this is a bit icky, but this case is nasty as is) Hopefully, nothing is depending on a kernel-module package (we can always enforce this by saying anything that DOES depend on a kernel-module package should be packaged with it). How many kernel-module packages are we really considering here? openafs: include the tools and the kernel module in the same package unionfs: ditto Now, assuming that livna wants to use the same mechanism, there are several other binary-only modules (ati & nvidia drivers), but no other packages should be depending on them. And when we remove the kernel-module rpm, the driver is either loaded or not. If loaded, its resident in memory, and the user can rmmod it and reload if they want to avoid a reboot. If not, we're fine. thoughts? ~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 pmatilai at welho.com Tue Feb 22 15:25:15 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 22 Feb 2005 17:25:15 +0200 (EET) Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109084404.15038.0.camel@opus.phy.duke.edu> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> Message-ID: On Tue, 22 Feb 2005, seth vidal wrote: > >> I think you missed my logic for this case. If there would be an >> update for a kernel-module, and the update has the same Requires: as >> an existing installed kernel-module of the same name, then replace the >> installed one with the new one, but don't touch any others that have >> Requires: for a different kernel. > > and I think you missed my point: > rpm can't do that. > > it doesn't just update a single older version - it updates ALL older > versions. Mm, you *could* do that by doing a "manual" update of erasing the specific older version of the package and installing the new, instead of using rpm's normal update procedure. Actually this has been brought up before on the subject of kernel-module packages, on freshrpms-list IIRC. I wasn't excited about doing such a "manual" update from apt for this special case then and I'm not now either :) - Panu - From cra at WPI.EDU Tue Feb 22 15:57:53 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Tue, 22 Feb 2005 10:57:53 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109085512.31372.57.camel@localhost.localdomain> References: <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> <1109085512.31372.57.camel@localhost.localdomain> Message-ID: <20050222155753.GB17670@angus.ind.WPI.EDU> On Tue, Feb 22, 2005 at 09:18:32AM -0600, Tom 'spot' Callaway wrote: > OK, so if rpm isn't smart enough to do that, can we teach yum to deal > with this case? I think we can and should. Yum has already been taught to install certain packages instead of update them. This is just a slightly modified case, where you erase then install, instead of update. From cra at WPI.EDU Tue Feb 22 16:02:43 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Tue, 22 Feb 2005 11:02:43 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: References: <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> Message-ID: <20050222160243.GC17670@angus.ind.WPI.EDU> On Tue, Feb 22, 2005 at 05:25:15PM +0200, Panu Matilainen wrote: > Mm, you *could* do that by doing a "manual" update of erasing the specific > older version of the package and installing the new, instead of using > rpm's normal update procedure. Actually this has been brought up before on > the subject of kernel-module packages, on freshrpms-list IIRC. I wasn't > excited about doing such a "manual" update from apt for this special case > then and I'm not now either :) I'd rather see a special case of an erase/install manual update, rather than a special case of parsing package name tags, splitting off the kernel version, and matching that to installed kernel versions. From fedora at leemhuis.info Tue Feb 22 16:10:53 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 22 Feb 2005 17:10:53 +0100 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109085512.31372.57.camel@localhost.localdomain> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> <1109085512.31372.57.camel@localhost.localdomain> Message-ID: <1109088653.5990.4.camel@localhost.localdomain> Am Dienstag, den 22.02.2005, 09:18 -0600 schrieb Tom 'spot' Callaway: > Now, assuming that livna wants to use the same mechanism, there are > several other binary-only modules (ati & nvidia drivers), but no other > packages should be depending on them. spot, just FYI. I'm also involved in livna also and maintain two out of three kernel-module-packages there (and got my hands dirty on the other one and two in QA also). And yes, we (at least I) want to use the same mechanism in extras and livna-packages ;-) -- Thorsten Leemhuis From fedora at leemhuis.info Tue Feb 22 16:17:28 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 22 Feb 2005 17:17:28 +0100 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109085512.31372.57.camel@localhost.localdomain> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> <1109085512.31372.57.camel@localhost.localdomain> Message-ID: <1109089048.5990.11.camel@localhost.localdomain> Am Dienstag, den 22.02.2005, 09:18 -0600 schrieb Tom 'spot' Callaway: > On Tue, 2005-02-22 at 10:00 -0500, seth vidal wrote: > Hopefully, nothing is depending on a kernel-module package (we can > always enforce this by saying anything that DOES depend on a > kernel-module package should be packaged with it). That is bad. Take the ati and nvidia drivers for example. They depend on a kernel-module. Packaging them together is no option there. It would be stupid to package a ~100k module together with a 3,5 MB (numbers from the ATI driver) graphics driver is stupid for kernel updates. Also parallel installation will make problems again. > How many kernel-module packages are we really considering here? In extras we had ony a kerel module for a thinkpad-driver IIRC. We had als in the FC1 days. And as I wrote yesterday already: Also I'm wondering how we should deal with kernel-modules in extras in general. davej/Core refuses everything that is not upstream for a good reason. If we put everything in extras it looks a bit "odd" IMHO. -- Thorsten Leemhuis From tcallawa at redhat.com Tue Feb 22 16:31:49 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Feb 2005 10:31:49 -0600 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109089048.5990.11.camel@localhost.localdomain> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> <1109085512.31372.57.camel@localhost.localdomain> <1109089048.5990.11.camel@localhost.localdomain> Message-ID: <1109089909.31372.87.camel@localhost.localdomain> On Tue, 2005-02-22 at 17:17 +0100, Thorsten Leemhuis wrote: >Also I'm wondering how we should deal with kernel-modules in extras in >general. davej/Core refuses everything that is not upstream for a good >reason. If we put everything in extras it looks a bit "odd" IMHO. Well, we could just push every kernel module addon package away, on the grounds that its not upstream, but that almost feels like passing the buck. I could set policy as "if its licensed compatible with the kernel, it should go upstream, and if not, it goes to Livna." Then I'd be passing the problem to Thorsten. openafs and unionfs are two cases that are valid today for FE, that people seem interested in. ~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 Tue Feb 22 16:35:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 22 Feb 2005 11:35:54 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> Message-ID: <1109090154.15038.14.camel@opus.phy.duke.edu> > Mm, you *could* do that by doing a "manual" update of erasing the specific > older version of the package and installing the new, instead of using > rpm's normal update procedure. Actually this has been brought up before on > the subject of kernel-module packages, on freshrpms-list IIRC. I wasn't > excited about doing such a "manual" update from apt for this special case > then and I'm not now either :) God this is going to be ugly. Like really, really, really ugly. -sv From tcallawa at redhat.com Tue Feb 22 16:46:23 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Feb 2005 10:46:23 -0600 Subject: [Fedora-packaging] kernel-module package naming Message-ID: <1109090783.31372.93.camel@localhost.localdomain> I don't think there is any dispute that magic will be needed to solve this problem. The more I think about it, the more I am opposed to abusing the package %{NAME} to solve it. Let's make the ground level assumption that packages containing kernel modules will be named %{NAME}-module, based on precedence in Fedora Core. So we'll have this: Fedora Core: GFS-module Fedora Extras: openafs-module unionfs-module Livna: ati-module nvidia-module >From there, we work uphill. ~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 cra at WPI.EDU Tue Feb 22 16:54:56 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Tue, 22 Feb 2005 11:54:56 -0500 Subject: [Fedora-packaging] kernel-module package naming In-Reply-To: <1109090783.31372.93.camel@localhost.localdomain> References: <1109090783.31372.93.camel@localhost.localdomain> Message-ID: <20050222165456.GB18355@angus.ind.WPI.EDU> On Tue, Feb 22, 2005 at 10:46:23AM -0600, Tom 'spot' Callaway wrote: > Fedora Extras: > openafs-module > unionfs-module I don't like this. How are we supposed to refer to these packages in the yum configuration for installonly? *-module might collide with other packages that aren't kernel modules (apache module? perl module?). I like kernel-module-unionfs because it is clear that it is a kernel module, and we can use the kernel-module-* glob in yum configuration. From tcallawa at redhat.com Tue Feb 22 16:55:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Feb 2005 10:55:50 -0600 Subject: [Fedora-packaging] kernel-module package naming In-Reply-To: <20050222165456.GB18355@angus.ind.WPI.EDU> References: <1109090783.31372.93.camel@localhost.localdomain> <20050222165456.GB18355@angus.ind.WPI.EDU> Message-ID: <1109091350.31372.96.camel@localhost.localdomain> On Tue, 2005-02-22 at 11:54 -0500, Chuck R. Anderson wrote: >On Tue, Feb 22, 2005 at 10:46:23AM -0600, Tom 'spot' Callaway wrote: >> Fedora Extras: >> openafs-module >> unionfs-module > >I don't like this. How are we supposed to refer to these packages in >the yum configuration for installonly? *-module might collide with >other packages that aren't kernel modules (apache module? perl >module?). I like kernel-module-unionfs because it is clear that it is >a kernel module, and we can use the kernel-module-* glob in yum >configuration. This seems reasonable. Is anyone opposed to: kernel-module-GFS kernel-module-openafs kernel-module-unionfs kernel-module-ati kernel-module-nvidia ? ~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 dag at wieers.com Tue Feb 22 17:05:12 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 22 Feb 2005 18:05:12 +0100 (CET) Subject: [Fedora-packaging] kernel-module package naming In-Reply-To: <1109091350.31372.96.camel@localhost.localdomain> References: <1109090783.31372.93.camel@localhost.localdomain> <20050222165456.GB18355@angus.ind.WPI.EDU> <1109091350.31372.96.camel@localhost.localdomain> Message-ID: On Tue, 22 Feb 2005, Tom 'spot' Callaway wrote: > On Tue, 2005-02-22 at 11:54 -0500, Chuck R. Anderson wrote: > >On Tue, Feb 22, 2005 at 10:46:23AM -0600, Tom 'spot' Callaway wrote: > >> Fedora Extras: > >> openafs-module > >> unionfs-module > > > >I don't like this. How are we supposed to refer to these packages in > >the yum configuration for installonly? *-module might collide with > >other packages that aren't kernel modules (apache module? perl > >module?). I like kernel-module-unionfs because it is clear that it is > >a kernel module, and we can use the kernel-module-* glob in yum > >configuration. > > This seems reasonable. Is anyone opposed to: > > kernel-module-GFS > kernel-module-openafs > kernel-module-unionfs > kernel-module-ati > kernel-module-nvidia Could we also evolve to a lowercase standard for package names ? This example shows a clear example of why uppercase or mixed case could be confusing or problematic. Other distributions already moved (or are evolving) to lower case as the default. (Even though perl is a good exception where uppercase and strict names are important) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From tcallawa at redhat.com Tue Feb 22 17:06:10 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 22 Feb 2005 11:06:10 -0600 Subject: [Fedora-packaging] kernel-module package naming In-Reply-To: References: <1109090783.31372.93.camel@localhost.localdomain> <20050222165456.GB18355@angus.ind.WPI.EDU> <1109091350.31372.96.camel@localhost.localdomain> Message-ID: <1109091971.31372.103.camel@localhost.localdomain> On Tue, 2005-02-22 at 18:05 +0100, Dag Wieers wrote: >Could we also evolve to a lowercase standard for package names ? This >example shows a clear example of why uppercase or mixed case could be >confusing or problematic. I think we should defer to the name of the sourcecode we're packaging. If it is GFS and not gfs, then we should match the name appropriately. Does the yum search deal with case-insensitivity? If not, then its more of an issue. ~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 dag at wieers.com Tue Feb 22 17:23:06 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 22 Feb 2005 18:23:06 +0100 (CET) Subject: [Fedora-packaging] kernel-module package naming In-Reply-To: References: <1109090783.31372.93.camel@localhost.localdomain> <20050222165456.GB18355@angus.ind.WPI.EDU> <1109091350.31372.96.camel@localhost.localdomain> Message-ID: On Tue, 22 Feb 2005, Dag Wieers wrote: > On Tue, 22 Feb 2005, Tom 'spot' Callaway wrote: > > > On Tue, 2005-02-22 at 11:54 -0500, Chuck R. Anderson wrote: > > >On Tue, Feb 22, 2005 at 10:46:23AM -0600, Tom 'spot' Callaway wrote: > > >> Fedora Extras: > > >> openafs-module > > >> unionfs-module > > > > > >I don't like this. How are we supposed to refer to these packages in > > >the yum configuration for installonly? *-module might collide with > > >other packages that aren't kernel modules (apache module? perl > > >module?). I like kernel-module-unionfs because it is clear that it is > > >a kernel module, and we can use the kernel-module-* glob in yum > > >configuration. > > > > This seems reasonable. Is anyone opposed to: > > > > kernel-module-GFS > > kernel-module-openafs > > kernel-module-unionfs > > kernel-module-ati > > kernel-module-nvidia > > Could we also evolve to a lowercase standard for package names ? This > example shows a clear example of why uppercase or mixed case could be > confusing or problematic. > > Other distributions already moved (or are evolving) to lower case as the > default. (Even though perl is a good exception where uppercase and strict > names are important) I once wrote a few documents explaining the package namespace and ideas about that, including the kernel-module namespace. http://svn.rpmforge.net/svn/branches/docs/dag/old/naming-convention.txt http://svn.rpmforge.net/svn/branches/docs/dag/old/renamed-packages.txt Both have pointers to other projects guidelines regarding naming and namespace. The lib%{name} stuff was very controversial back then, even as a proposal. Whatever policy is chosen, I'm sure that the pragmatic way of enforcing it would be to start off (or limit it) to new packages only. The add-on packages is something that is also not yet endorsed by everyone. The basic idea is to have an add-on package start with the name it adds something to. Like a python module starts off with python-%{name} and an xmms plugin starts with xmms-%{name}. Even when it is a sub-package of %{name} or the original name is slightly different (does/does not include a prefix or is named the other way around). I think the biggest difficulty with coming up with a proper naming scheme is that people want to put that next to the current packages and suddenly see a lot of things not complying and then object to the proposed standard. We may have to first acknowledge that the current namespace is the result of not having a naming convention and acknowledge the fact that we don't necessarily need to fix everything that already exists to adopt a naming scheme for new packages. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From skvidal at phy.duke.edu Tue Feb 22 18:28:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 22 Feb 2005 13:28:54 -0500 Subject: [Fedora-packaging] kernel-module package naming In-Reply-To: <1109091971.31372.103.camel@localhost.localdomain> References: <1109090783.31372.93.camel@localhost.localdomain> <20050222165456.GB18355@angus.ind.WPI.EDU> <1109091350.31372.96.camel@localhost.localdomain> <1109091971.31372.103.camel@localhost.localdomain> Message-ID: <1109096935.15038.28.camel@opus.phy.duke.edu> On Tue, 2005-02-22 at 11:06 -0600, Tom 'spot' Callaway wrote: > On Tue, 2005-02-22 at 18:05 +0100, Dag Wieers wrote: > > >Could we also evolve to a lowercase standard for package names ? This > >example shows a clear example of why uppercase or mixed case could be > >confusing or problematic. > > I think we should defer to the name of the sourcecode we're packaging. > If it is GFS and not gfs, then we should match the name appropriately. > > Does the yum search deal with case-insensitivity? If not, then its more > of an issue. yum list and yum search do case-insentive matching. yum install/remove/update does not, for obvious reasons. -sv From pmatilai at welho.com Wed Feb 23 07:10:29 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 23 Feb 2005 09:10:29 +0200 (EET) Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109090154.15038.14.camel@opus.phy.duke.edu> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> <1109090154.15038.14.camel@opus.phy.duke.edu> Message-ID: On Tue, 22 Feb 2005, seth vidal wrote: > >> Mm, you *could* do that by doing a "manual" update of erasing the specific >> older version of the package and installing the new, instead of using >> rpm's normal update procedure. Actually this has been brought up before on >> the subject of kernel-module packages, on freshrpms-list IIRC. I wasn't >> excited about doing such a "manual" update from apt for this special case >> then and I'm not now either :) > > > God this is going to be ugly. > > Like really, really, really ugly. No s**t. I think dealing with that should be possible from apt's lua-scripts just like the current "magic" is but I haven't given it much thought since the current scheme "just works" with the uname-in-package-name scheme which.. I don't like either but at least it works. For your (and others') amusement, there's a long and lively discussion about kernel-module dependencies, naming schemes etc at http://lists.freshrpms.net/pipermail/freshrpms-list/2004-March/thread.html Something inside my head keeps saying there's a nice solution to this all but we're just too blind to see it. Most likely I've just been too much into mushrooms lately however... :P - Panu - From skvidal at phy.duke.edu Wed Feb 23 07:19:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 23 Feb 2005 02:19:36 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> <1109090154.15038.14.camel@opus.phy.duke.edu> Message-ID: <1109143176.3737.5.camel@cutter> >No s**t. I think dealing with that should be possible from apt's >lua-scripts just like the current "magic" is but I haven't given it >much thought since the current scheme "just works" with the >uname-in-package-name scheme which.. I don't like either but at least it >works. > >For your (and others') amusement, there's a long and lively >discussion about kernel-module dependencies, naming schemes etc at >http://lists.freshrpms.net/pipermail/freshrpms-list/2004-March/thread.html >Something inside my head keeps saying there's a nice solution to this all >but we're just too blind to see it. Most likely I've just been too much >into mushrooms lately however... :P One thing we could do. But I'm hesitant to do it. We could ask if, as an option for adding a package into the ts as an update it takes an optional header of the package it is updating. I'm not sure how ugly this would be for rpm but it would allow for the flexibility we'd need/want here. is Paul on this list? any ideas? -sv From pmatilai at welho.com Wed Feb 23 07:17:16 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 23 Feb 2005 09:17:16 +0200 (EET) Subject: kernel-module packaging (was Re: [Fedora-packaging] Re: DKMS into Fedora Extras) In-Reply-To: <1109078890.31372.27.camel@localhost.localdomain> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <1109017159.10854.105.camel@localhost.localdomain> <1109057647.5046.13.camel@thl.ct.heise.de> <1109078890.31372.27.camel@localhost.localdomain> Message-ID: On Tue, 22 Feb 2005, Tom 'spot' Callaway wrote: > On Tue, 2005-02-22 at 08:34 +0100, Thorsten Leemhuis wrote: > >> Case 4.1: What if kernel-module-unionfs-2.6.10_4_FC3-1 is released >> one/two days behind kernel-2.6.10-3_FC3? This can happen due to build >> errors that first need to get fixed. Or the build system or all that >> have access are sleeping. Or simply due due mirroring "problems" when >> core/updates/ is already mirrored, but extras/ not yet. > > That's a valid point, since the kernel package doesn't depend on > kernel-module-*. Anyone have any idea how to work around this in a sane > manner? The current apt implementation of the kernel-module handling prints out warnings if you have kernel modules installed which are not available for the new kernel you're about to install by doing some "fun" calculations with provides and versions. Alternatively it could hold back from installing the new kernel until all the modules are available for the new kernel as well. So, it's possible (at least in the current uname-in-package-name scheme) but fun it is not. - Panu - From skvidal at phy.duke.edu Wed Feb 23 07:24:16 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 23 Feb 2005 02:24:16 -0500 Subject: kernel-module packaging (was Re: [Fedora-packaging] Re: DKMS into Fedora Extras) In-Reply-To: References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <1109017159.10854.105.camel@localhost.localdomain> <1109057647.5046.13.camel@thl.ct.heise.de> <1109078890.31372.27.camel@localhost.localdomain> Message-ID: <1109143456.3737.7.camel@cutter> >The current apt implementation of the kernel-module handling prints out >warnings if you have kernel modules installed which are not available for >the new kernel you're about to install by doing some "fun" calculations >with provides and versions. Alternatively it could hold back from >installing the new kernel until all the modules are available for the new >kernel as well. > >So, it's possible (at least in the current uname-in-package-name scheme) >but fun it is not. My concern is not with it being fun but with it being: 1. confusing to users wanting to install the kernel-module 2. fragile -sv From pnasrat at redhat.com Wed Feb 23 12:30:44 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 23 Feb 2005 12:30:44 +0000 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109143176.3737.5.camel@cutter> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> <1109090154.15038.14.camel@opus.phy.duke.edu> <1109143176.3737.5.camel@cutter> Message-ID: <1109161844.9770.12.camel@anu.eridu> On Wed, 2005-02-23 at 02:19 -0500, seth vidal wrote: >We could ask if, as an option for adding a package into the ts as an >update it takes an optional header of the package it is updating. > >I'm not sure how ugly this would be for rpm but it would allow for the >flexibility we'd need/want here. > >is Paul on this list? any ideas? Yes, I'm here. Just playing catch up. I'll try and digest these things from an rpm/rpm-python point of view. If I'm understanding it you want something ala: ts.addReplacement(hdr1, hdr2) which is equivalent to: addInstall(hdr1, blah, 'i') addErase(hdr2) or am I just on crack. Paul From tcallawa at redhat.com Wed Feb 23 20:18:10 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 14:18:10 -0600 Subject: [Fedora-packaging] Naming Policy (first draft) Message-ID: <1109189890.13305.107.camel@localhost.localdomain> Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers. http://fedoraproject.org/wiki/PackageNamingGuidelines Feedback is welcome, and encouraged. ~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 slawrence at pingtel.com Wed Feb 23 20:22:10 2005 From: slawrence at pingtel.com (Scott Lawrence) Date: Wed, 23 Feb 2005 15:22:10 -0500 Subject: [Fedora-packaging] Overlapping/variant rpms - how to ensure correct resolution Message-ID: <1109190130.3107.44.camel@sukothai.pingtel.com> I'm the project coordinator of the sipXpbx project [1] and we're distributing quite a number of RPMs (in the fullness of time we'd like to get them into Extras, but that is a topic for another list and another day) . The project itself consists of several component RPMs and there are some other open source projects on which we depend that we build RPMs for, mostly because they don't. The one exception to the "mostly because they don't" is the difficulty I'm looking for advice on from those who understand packaging. Fedora Core inludes w3c-libwww.rpm, but that version does not include compilation with openssl. For lots of good reasons, we need the openssl, so we build a version of the w3c-libwww.rpm that has it enabled; that's the only difference. Our first approach to dealing with the conflict was just to instruct our users to configure yum to exclude the w3c-libwww package from all repositories but ours, but that's a bit of a pain. We tried adding a 'requires' line to our spec file that called for 'libwwwssl.so' (which is in our rpm but not the Core rpm for the same package), but then yum seemed to want to load both... In any event, this seems to me to raise a general issue of how to cope with the fact that some packages can be built in (potentially overlapping) variants. How can we make all of the variants available and express what each provides so that tools like yum can make the correct choice? [1] http://www.sipfoundry.org/sipXpbx/ -- Scott Lawrence Consulting Engineer Pingtel Corp. http://www.pingtel.com/ +1.781.938.5306 x162 From tcallawa at redhat.com Wed Feb 23 20:28:37 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 14:28:37 -0600 Subject: [Fedora-packaging] Overlapping/variant rpms - how to ensure correct resolution In-Reply-To: <1109190130.3107.44.camel@sukothai.pingtel.com> References: <1109190130.3107.44.camel@sukothai.pingtel.com> Message-ID: <1109190517.13305.114.camel@localhost.localdomain> On Wed, 2005-02-23 at 15:22 -0500, Scott Lawrence wrote: >Fedora Core inludes w3c-libwww.rpm, but that version does not include >compilation with openssl. For lots of good reasons, we need the >openssl, so we build a version of the w3c-libwww.rpm that has it >enabled; that's the only difference. In this case, this is a bug in Fedora Core's w3c-libwww package. I can't think of a good reason for it not to depend on openssl, since it should be present on the vast majority of installs (and isn't an unreasonable dependency when installing w3c-libwww). >In any event, this seems to me to raise a general issue of how to cope >with the fact that some packages can be built in (potentially >overlapping) variants. How can we make all of the variants available >and express what each provides so that tools like yum can make the >correct choice? One of the hard and fast rules I intend to implement is that Fedora Extras packages cannot duplicate existing packages in Fedora Core. Please open a bug against bugzilla.redhat.com to get w3c-libwww to start building with ssl enabled, and by FC4, this issue should be moot. :) Otherwise we either start hacking conflict overrides, or we end up with rpms that have renamed libraries, effectively doubling the number of libraries on a system. The Red Hat package maintainers are willing to fix issues in their Core packages, and Fedora moves fast enough that it should never be a problem for more than 6 months. (And if the maintainers aren't willing, me and Greg can start beating them over the head with the cluestick) > ~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 Wed Feb 23 20:42:58 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 23 Feb 2005 22:42:58 +0200 Subject: kernel-module packaging (was Re: [Fedora-packaging] Re: DKMS into Fedora Extras) In-Reply-To: <1109143456.3737.7.camel@cutter> References: <42156822.2080600@redhat.com> <1108904731.6115.32.camel@localhost.localdomain> <1108963912.7032.33.camel@cutter> <1108966070.5033.9.camel@thl.ct.heise.de> <1109003370.10854.41.camel@localhost.localdomain> <1109005759.6007.7.camel@localhost.localdomain> <1109005999.10854.53.camel@localhost.localdomain> <1109007481.6007.15.camel@localhost.localdomain> <1109008610.10854.66.camel@localhost.localdomain> <1109011067.6007.34.camel@localhost.localdomain> <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <1109017159.10854.105.camel@localhost.localdomain> <1109057647.5046.13.camel@thl.ct.heise.de> <1109078890.31372.27.camel@localhost.localdomain> <1109143456.3737.7.camel@cutter> Message-ID: <1109191378.6386.353.camel@bobcat.mine.nu> On Wed, 2005-02-23 at 02:24 -0500, seth vidal wrote: > >The current apt implementation of the kernel-module handling prints out > >warnings if you have kernel modules installed which are not available for > >the new kernel you're about to install by doing some "fun" calculations > >with provides and versions. Alternatively it could hold back from > >installing the new kernel until all the modules are available for the new > >kernel as well. > > > >So, it's possible (at least in the current uname-in-package-name scheme) > >but fun it is not. > > My concern is not with it being fun but with it being: > 1. confusing to users wanting to install the kernel-module > 2. fragile IMHO the minimum requirement is to get the above mentioned warnings. Auto-pulling them in is a nice feature too, and has worked for me with apt almost perfectly thus far. From ville.skytta at iki.fi Wed Feb 23 20:47:21 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 23 Feb 2005 22:47:21 +0200 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> <1109090154.15038.14.camel@opus.phy.duke.edu> Message-ID: <1109191641.6386.355.camel@bobcat.mine.nu> On Wed, 2005-02-23 at 09:10 +0200, Panu Matilainen wrote: > Something inside my head keeps saying there's a nice solution to this all > but we're just too blind to see it. Most likely I've just been too much > into mushrooms lately however... :P s/mushrooms/kernel module packaging/ This stuff is strong enough by itself :) From slawrence at pingtel.com Wed Feb 23 20:53:55 2005 From: slawrence at pingtel.com (Scott Lawrence) Date: Wed, 23 Feb 2005 15:53:55 -0500 Subject: [Fedora-packaging] Overlapping/variant rpms - how to ensure correct resolution In-Reply-To: <1109190517.13305.114.camel@localhost.localdomain> References: <1109190130.3107.44.camel@sukothai.pingtel.com> <1109190517.13305.114.camel@localhost.localdomain> Message-ID: <1109192035.8646.1.camel@sukothai.pingtel.com> On Wed, 2005-02-23 at 14:28 -0600, Tom 'spot' Callaway wrote: > One of the hard and fast rules I intend to implement is that Fedora > Extras packages cannot duplicate existing packages in Fedora Core. A good rule, I agree. > Please open a bug against bugzilla.redhat.com to get w3c-libwww to start > building with ssl enabled, and by FC4, this issue should be moot. :) Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149536 -- Scott Lawrence Consulting Engineer Pingtel Corp. http://www.pingtel.com/ +1.781.938.5306 x162 From cra at WPI.EDU Wed Feb 23 21:13:31 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Wed, 23 Feb 2005 16:13:31 -0500 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109189890.13305.107.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> Message-ID: <20050223211331.GB28055@angus.ind.WPI.EDU> On Wed, Feb 23, 2005 at 02:18:10PM -0600, Tom 'spot' Callaway wrote: > Feedback is welcome, and encouraged. In section 1.2 "Multiple packages with the same base name" you might want to mention the exception: parallel-installable packages, like kernel (and kernel-module-*). Otherwise, looks good. From pmatilai at welho.com Wed Feb 23 21:17:32 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 23 Feb 2005 23:17:32 +0200 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109189890.13305.107.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> Message-ID: <1109193452.24989.46.camel@chip.laiskiainen.org> On Wed, 2005-02-23 at 14:18 -0600, Tom 'spot' Callaway wrote: > Working as fast as I can... here is the first draft of the Naming Policy > for Fedora Extras. Its not 100% complete yet, there are at least two > sections missing, but it covers the bases for most new packagers. > > http://fedoraproject.org/wiki/PackageNamingGuidelines > > Feedback is welcome, and encouraged. First of all a big thank you for doing this, a packaging standard for Extras (and for Core as well I hope!) is certainly most welcome and somewhat overdue :) Some comments after a quick read-through: 1) Version and release-tags: Package version should obviously follow upstream version in normal, sane cases but especially things like 1.0- pre1 need special rules to handle without epochs, those should be covered in this doc. The old fedora.us packaging guidelines doc, section C-3 (http://www.fedora.us/wiki/PackageNamingGuidelines) pretty much covers these cases if you drop the 0.fdr tags from the rules. 2) While at versions and releases: can we *please* have a standard on release-tags. Current FC trees have a wild variety of things in there like "3jpp_2fc", in general a truly random FC3 vs fc2 dist-tags for some packages (disttags are just fine when needed but can we standardize on lowercase like with package names, please :) .. and so on. Just do 'rpm -qp --qf "%{release}\n" *|sort -u' on current FC-devel RPMS directory for giggles. Please let's have a standard of allowed characters in release and version tags as well since we're having one for names? 3) Addon packages: when a package is renamed, eg 'adodb' -> 'php-adodb' it *might* be a good idea to add the original name as a "Provides: adodb" so people looking for upstream naming can find it more easily. Oh and FWIW current rawhide contains quite a few packages other than pam_ and SDL_ with underscores in the name (see below). Of these the various apache mod_foo packages are numerous enough to warrant an exception rule of their own, others should perhaps be renamed? [pmatilai at chip RPMS]$ rpm -qp --qf "%{name}\n"|grep _ arptables_jf dhcpv6_client java_cup java_cup-javadoc java_cup-manual knm_new libart_lgpl libart_lgpl-devel lm_sensors lm_sensors-devel microcode_ctl mod_auth_kerb mod_auth_mysql mod_auth_pgsql mod_authz_ldap mod_dav_svn mod_perl mod_perl-devel mod_python mod_ssl nss_db nss_db-compat nss_ldap sg3_utils tcp_wrappers ttfonts-zh_CN ttfonts-zh_TW - Panu - From cra at WPI.EDU Wed Feb 23 21:46:31 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Wed, 23 Feb 2005 16:46:31 -0500 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109193452.24989.46.camel@chip.laiskiainen.org> References: <1109189890.13305.107.camel@localhost.localdomain> <1109193452.24989.46.camel@chip.laiskiainen.org> Message-ID: <20050223214631.GD28055@angus.ind.WPI.EDU> On Wed, Feb 23, 2005 at 11:17:32PM +0200, Panu Matilainen wrote: > 1) Version and release-tags: Package version should obviously follow > upstream version in normal, sane cases but especially things like 1.0- > pre1 need special rules to handle without epochs, those should be > covered in this doc. The old fedora.us packaging guidelines doc, section > C-3 (http://www.fedora.us/wiki/PackageNamingGuidelines) pretty much > covers these cases if you drop the 0.fdr tags from the rules. +1. This will help avoid unnecessary epoch inflation. For even more giggles, see development: rpm -qp --qf='%{epoch}\n' *.rpm | sort | uniq -c | sort -n > 2) While at versions and releases: can we *please* have a standard on > release-tags. Current FC trees have a wild variety of things in there > like "3jpp_2fc", in general a truly random FC3 vs fc2 dist-tags for some > packages (disttags are just fine when needed but can we standardize on > lowercase like with package names, please :) .. and so on. Just do > 'rpm -qp --qf "%{release}\n" *|sort -u' on current FC-devel RPMS > directory for giggles. Please let's have a standard of allowed > characters in release and version tags as well since we're having one > for names? +1 > 3) Addon packages: when a package is renamed, eg 'adodb' -> 'php-adodb' > it *might* be a good idea to add the original name as a "Provides: > adodb" so people looking for upstream naming can find it more easily. Already covered in section 1.7 "Renaming a package". You need the Obsoletes: too. From dag at wieers.com Wed Feb 23 22:09:38 2005 From: dag at wieers.com (Dag Wieers) Date: Wed, 23 Feb 2005 23:09:38 +0100 (CET) Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109189890.13305.107.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> Message-ID: On Wed, 23 Feb 2005, Tom 'spot' Callaway wrote: > Working as fast as I can... here is the first draft of the Naming Policy > for Fedora Extras. Its not 100% complete yet, there are at least two > sections missing, but it covers the bases for most new packagers. > > http://fedoraproject.org/wiki/PackageNamingGuidelines > > Feedback is welcome, and encouraged. Looks good, I would propose a standard SPEC file (in the SRPM) formatted as: %{name}-%{version}-%{release}-%{repotag}.spec If your working on a SPEC file and install several other versions, this would prevent SPEC files replacing others. And the origin is clear too. It's something the buildsystem could do before creating the SRPM (in that respect it may not be that important for FE). For the package release, it may be useful to use < 1 release numbers to indicate a work in progress. (0.1, 0.2) We're doing the same in case we consider something a beta or rc product. (Especially if you're posting incremental test releases for other people to try). The version is always numeric, the release is also always numeric (in case of alpha/beta/rc < 1 and followed by the non numeric portion of the version) postfixed with the disttag and repotag. PS I like the gnome-applet-%{name} convention, I have too many applets now using the upstream name, which is not very clear whether it is a gnome applet or not. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From cra at WPI.EDU Wed Feb 23 22:18:02 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Wed, 23 Feb 2005 17:18:02 -0500 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> Message-ID: <20050223221802.GE28055@angus.ind.WPI.EDU> On Wed, Feb 23, 2005 at 11:09:38PM +0100, Dag Wieers wrote: > Looks good, I would propose a standard SPEC file (in the SRPM) formatted > as: > > %{name}-%{version}-%{release}-%{repotag}.spec -1. It is easier to deal with shorter spec names that match the package %{name} and hence the name in CVS. > If your working on a SPEC file and install several other versions, this > would prevent SPEC files replacing others. And the origin is clear too. The origin is already clear from the contents of the spec file... If you are worried about overwriting spec files from multiple versions, then you should also be worried about overwriting sources and patches... You can already prevent these problems with a suitable .rpmmacros file: %_topdir /home/cra/src/redhat %_ntopdir %{_topdir}/%{name}-%{version}-%{release} %_builddir %{_ntopdir} %_sourcedir %{_ntopdir} %_specdir %{_ntopdir} %_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm %_rpmdir %{_topdir}/RPMS %_srcrpmdir %{_topdir}/SRPMS > It's something the buildsystem could do before creating the SRPM (in that > respect it may not be that important for FE). > > For the package release, it may be useful to use < 1 release numbers to > indicate a work in progress. (0.1, 0.2) We're doing the same in case we > consider something a beta or rc product. (Especially if you're posting > incremental test releases for other people to try). The version is always > numeric, the release is also always numeric (in case of alpha/beta/rc < 1 > and followed by the non numeric portion of the version) postfixed with the > disttag and repotag. +1 This goes along with the old fedora.us guidelines for versioning of alpha/beta/rc releases. From pmatilai at welho.com Wed Feb 23 22:19:50 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 24 Feb 2005 00:19:50 +0200 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> Message-ID: <1109197190.24989.56.camel@chip.laiskiainen.org> On Wed, 2005-02-23 at 23:09 +0100, Dag Wieers wrote: > On Wed, 23 Feb 2005, Tom 'spot' Callaway wrote: > > > Working as fast as I can... here is the first draft of the Naming Policy > > for Fedora Extras. Its not 100% complete yet, there are at least two > > sections missing, but it covers the bases for most new packagers. > > > > http://fedoraproject.org/wiki/PackageNamingGuidelines > > > > Feedback is welcome, and encouraged. > > Looks good, I would propose a standard SPEC file (in the SRPM) formatted > as: > > %{name}-%{version}-%{release}-%{repotag}.spec > > If your working on a SPEC file and install several other versions, this > would prevent SPEC files replacing others. And the origin is clear too. Eek, please lets don't. That's what CVS and distro brances of packages are for. > For the package release, it may be useful to use < 1 release numbers to > indicate a work in progress. (0.1, 0.2) We're doing the same in case we > consider something a beta or rc product. (Especially if you're posting > incremental test releases for other people to try). Yep - this should be covered in the old fedora.us naming standard doc I mentioned but certainly should be explained in the standard. - Panu - From tcallawa at redhat.com Wed Feb 23 23:10:19 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 23 Feb 2005 17:10:19 -0600 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109193452.24989.46.camel@chip.laiskiainen.org> References: <1109189890.13305.107.camel@localhost.localdomain> <1109193452.24989.46.camel@chip.laiskiainen.org> Message-ID: <1109200220.13305.138.camel@localhost.localdomain> On Wed, 2005-02-23 at 23:17 +0200, Panu Matilainen wrote: >Some comments after a quick read-through: > >1) Version and release-tags: Package version should obviously follow >upstream version in normal, sane cases but especially things like 1.0- >pre1 need special rules to handle without epochs, those should be >covered in this doc. The old fedora.us packaging guidelines doc, section >C-3 (http://www.fedora.us/wiki/PackageNamingGuidelines) pretty much >covers these cases if you drop the 0.fdr tags from the rules. The old C-3 section seemed sane, so I dropped the 0.fdr tagging, cleaned up the rules a bit, and included them. >2) While at versions and releases: can we *please* have a standard on >release-tags. Current FC trees have a wild variety of things in there >like "3jpp_2fc", in general a truly random FC3 vs fc2 dist-tags for some >packages (disttags are just fine when needed but can we standardize on >lowercase like with package names, please :) .. and so on. Just do >'rpm -qp --qf "%{release}\n" *|sort -u' on current FC-devel RPMS >directory for giggles. Please let's have a standard of allowed >characters in release and version tags as well since we're having one >for names? Does the current release standard seem sane? Numeric incrementals, starting at 1, with the exception case of packages having non-numeric versions? That way, it keeps all the junk out of the Release field, and any non-numeric characters that do appear are there for a valid reason. >3) Addon packages: when a package is renamed, eg 'adodb' -> 'php-adodb' >it *might* be a good idea to add the original name as a "Provides: >adodb" so people looking for upstream naming can find it more easily. The "Renaming a Package" section covers this. >Oh and FWIW current rawhide contains quite a few packages other than >pam_ and SDL_ with underscores in the name (see below). Of these the >various apache mod_foo packages are numerous enough to warrant an >exception rule of their own, others should perhaps be renamed? Added Apache httpd to the pam/SDL rule, added a "packages with locales" rule, and added an "upstream name uses underscore" rule. ~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 dag at wieers.com Wed Feb 23 23:40:09 2005 From: dag at wieers.com (Dag Wieers) Date: Thu, 24 Feb 2005 00:40:09 +0100 (CET) Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <20050223221802.GE28055@angus.ind.WPI.EDU> References: <1109189890.13305.107.camel@localhost.localdomain> <20050223221802.GE28055@angus.ind.WPI.EDU> Message-ID: On Wed, 23 Feb 2005, Chuck R. Anderson wrote: > On Wed, Feb 23, 2005 at 11:09:38PM +0100, Dag Wieers wrote: > > Looks good, I would propose a standard SPEC file (in the SRPM) formatted > > as: > > > > %{name}-%{version}-%{release}-%{repotag}.spec > > -1. It is easier to deal with shorter spec names that match the > package %{name} and hence the name in CVS. In what sense ? As you have to rename the SPEC files yourself in between installs (or change .rpmmacros). For ordinary users fixing something (those that contribute and I want to stimulate contributing :)) having identifiable SPEC filenames is more important than a short filename. > > If your working on a SPEC file and install several other versions, this > > would prevent SPEC files replacing others. And the origin is clear too. > > The origin is already clear from the contents of the spec file... If > you are worried about overwriting spec files from multiple versions, > then you should also be worried about overwriting sources and > patches... In fact, I have a seperate environment for everything my buildsystem does and what I install from other sources. So I'm not that worried about replaced source files because I do not use them directly. However I often have several SPEC files from several SRPMs installed and if they're all being called the same I have to manually intervene to correct that. (With CVS access to FE this may be less of a problem for FE, but still...) > You can already prevent these problems with a suitable .rpmmacros > file: > > %_topdir /home/cra/src/redhat > %_ntopdir %{_topdir}/%{name}-%{version}-%{release} > %_builddir %{_ntopdir} > %_sourcedir %{_ntopdir} > %_specdir %{_ntopdir} > %_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm > %_rpmdir %{_topdir}/RPMS > %_srcrpmdir %{_topdir}/SRPMS The difference is that this has to be manually configured and 'unique' SPEC files is something users will enjoy without configuration. And SRPMs in the end will be more used by end-users (like I am when looking at other's people work) than by the packagers themselves. Additionally having to use differently versioned directories to diff 2 SPEC files is more annoying than diffing 2 versioned filenames in the same directory. So I prefer the latter, not that it's that important. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Wed Feb 23 23:47:04 2005 From: dag at wieers.com (Dag Wieers) Date: Thu, 24 Feb 2005 00:47:04 +0100 (CET) Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109197190.24989.56.camel@chip.laiskiainen.org> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> Message-ID: On Thu, 24 Feb 2005, Panu Matilainen wrote: > On Wed, 2005-02-23 at 23:09 +0100, Dag Wieers wrote: > > On Wed, 23 Feb 2005, Tom 'spot' Callaway wrote: > > > > > Working as fast as I can... here is the first draft of the Naming Policy > > > for Fedora Extras. Its not 100% complete yet, there are at least two > > > sections missing, but it covers the bases for most new packagers. > > > > > > http://fedoraproject.org/wiki/PackageNamingGuidelines > > > > > > Feedback is welcome, and encouraged. > > > > Looks good, I would propose a standard SPEC file (in the SRPM) formatted > > as: > > > > %{name}-%{version}-%{release}-%{repotag}.spec > > > > If your working on a SPEC file and install several other versions, this > > would prevent SPEC files replacing others. And the origin is clear too. > > Eek, please lets don't. That's what CVS and distro brances of packages > are for. How does that affect SPEC files in SRPMs ? Afaik FE (and RH) SRPMs have a %{name}.spec files inside the SRPM which are not distinguishable. Even when FE or RH is using CVS and distro branches. I'm talking about renaming the SPEC file to something more identifiable as %{name}.spec before creating the SRPM. Nothing else. DAR is doing this as part of the pre-processing stage of the SPEC file. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From skvidal at phy.duke.edu Thu Feb 24 04:34:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 23 Feb 2005 23:34:41 -0500 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109189890.13305.107.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> Message-ID: <1109219681.10915.54.camel@cutter> On Wed, 2005-02-23 at 14:18 -0600, Tom 'spot' Callaway wrote: >Working as fast as I can... here is the first draft of the Naming Policy >for Fedora Extras. Its not 100% complete yet, there are at least two >sections missing, but it covers the bases for most new packagers. > >http://fedoraproject.org/wiki/PackageNamingGuidelines > >Feedback is welcome, and encouraged. > It's straightforward and doesn't suffer from being painfully long-winded. good job. -sv From skvidal at phy.duke.edu Thu Feb 24 04:45:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 23 Feb 2005 23:45:30 -0500 Subject: [Fedora-packaging] Re: DKMS into Fedora Extras In-Reply-To: <1109161844.9770.12.camel@anu.eridu> References: <1109011626.6386.161.camel@bobcat.mine.nu> <1109012266.6007.36.camel@localhost.localdomain> <1109012703.16633.35.camel@opus.phy.duke.edu> <1109013540.10854.77.camel@localhost.localdomain> <1109015320.16633.59.camel@opus.phy.duke.edu> <20050221204138.GA5061@angus.ind.WPI.EDU> <1109018925.10854.127.camel@localhost.localdomain> <20050222004752.GH5061@angus.ind.WPI.EDU> <1109040260.31372.3.camel@localhost.localdomain> <1109044865.28235.25.camel@cutter> <20050222141148.GB15948@angus.ind.WPI.EDU> <1109084404.15038.0.camel@opus.phy.duke.edu> <1109090154.15038.14.camel@opus.phy.duke.edu> <1109143176.3737.5.camel@cutter> <1109161844.9770.12.camel@anu.eridu> Message-ID: <1109220330.10915.61.camel@cutter> >Yes, I'm here. Just playing catch up. I'll try and digest these things >from an rpm/rpm-python point of view. > >If I'm understanding it you want something ala: > >ts.addReplacement(hdr1, hdr2) > >which is equivalent to: > >addInstall(hdr1, blah, 'i') >addErase(hdr2) > >or am I just on crack. sorta. I was actually thinking of an extension to addInstall(hdr1, 'u') so if you have multiple packages of the same name installed rpm would know to only update one of them - not all of them. sorta like being able to set which package gets obsoleted out of a set of multiply installed packages. -sv From pmatilai at welho.com Thu Feb 24 07:38:41 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 24 Feb 2005 09:38:41 +0200 (EET) Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109200220.13305.138.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109193452.24989.46.camel@chip.laiskiainen.org> <1109200220.13305.138.camel@localhost.localdomain> Message-ID: On Wed, 23 Feb 2005, Tom 'spot' Callaway wrote: > On Wed, 2005-02-23 at 23:17 +0200, Panu Matilainen wrote: > >> Some comments after a quick read-through: >> >> 1) Version and release-tags: Package version should obviously follow >> upstream version in normal, sane cases but especially things like 1.0- >> pre1 need special rules to handle without epochs, those should be >> covered in this doc. The old fedora.us packaging guidelines doc, section >> C-3 (http://www.fedora.us/wiki/PackageNamingGuidelines) pretty much >> covers these cases if you drop the 0.fdr tags from the rules. > > The old C-3 section seemed sane, so I dropped the 0.fdr tagging, cleaned > up the rules a bit, and included them. Thanks, looks good. One thing which is open to discussion I think is post-release non-numeric versions like 1.0 -> 1.0a where the 'a' doesn't *have* to move to release tag from rpm's POV. I don't mind either way, perhaps it's best to KISS (like the current draft has) and simply move *all* non-numeric bits to release instead of having separate cases for pre- and post-releases. >> 2) While at versions and releases: can we *please* have a standard on >> release-tags. Current FC trees have a wild variety of things in there >> like "3jpp_2fc", in general a truly random FC3 vs fc2 dist-tags for some >> packages (disttags are just fine when needed but can we standardize on >> lowercase like with package names, please :) .. and so on. Just do >> 'rpm -qp --qf "%{release}\n" *|sort -u' on current FC-devel RPMS >> directory for giggles. Please let's have a standard of allowed >> characters in release and version tags as well since we're having one >> for names? > > Does the current release standard seem sane? Numeric incrementals, > starting at 1, with the exception case of packages having non-numeric > versions? > > That way, it keeps all the junk out of the Release field, and any > non-numeric characters that do appear are there for a valid reason. Yes, it does look sane and the examples are nice and clean. What's missing IMHO is statement outside examples that the different parts (where necessary) in release tag should be separated with dots, not underscores or other creative items and letters should be lowercase wherever possible. > >> 3) Addon packages: when a package is renamed, eg 'adodb' -> 'php-adodb' >> it *might* be a good idea to add the original name as a "Provides: >> adodb" so people looking for upstream naming can find it more easily. > > The "Renaming a Package" section covers this. Mm, yep, indeed. On the subject of renaming: shouldn't the Provides and Obsoletes be versioned there? There have been some examples in the past where an unversioned obsoletes has caused grief (obsolete-loops causing packages flip-floping) in the past... > >> Oh and FWIW current rawhide contains quite a few packages other than >> pam_ and SDL_ with underscores in the name (see below). Of these the >> various apache mod_foo packages are numerous enough to warrant an >> exception rule of their own, others should perhaps be renamed? > > Added Apache httpd to the pam/SDL rule, added a "packages with locales" > rule, and added an "upstream name uses underscore" rule. Ok. So far looking nice and clean :) - Panu - From pmatilai at welho.com Thu Feb 24 07:43:09 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 24 Feb 2005 09:43:09 +0200 (EET) Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> Message-ID: On Thu, 24 Feb 2005, Dag Wieers wrote: > On Thu, 24 Feb 2005, Panu Matilainen wrote: >>>> >>>> Feedback is welcome, and encouraged. >>> >>> Looks good, I would propose a standard SPEC file (in the SRPM) formatted >>> as: >>> >>> %{name}-%{version}-%{release}-%{repotag}.spec >>> >>> If your working on a SPEC file and install several other versions, this >>> would prevent SPEC files replacing others. And the origin is clear too. >> >> Eek, please lets don't. That's what CVS and distro brances of packages >> are for. > > How does that affect SPEC files in SRPMs ? Afaik FE (and RH) SRPMs have a > %{name}.spec files inside the SRPM which are not distinguishable. Even > when FE or RH is using CVS and distro branches. > > I'm talking about renaming the SPEC file to something more identifiable as > %{name}.spec before creating the SRPM. Nothing else. DAR is doing this as > part of the pre-processing stage of the SPEC file. I just don't think that renaming spec to some awfully long name buys you any safety at all and only looks ugly as hell :) The SRPM can contain other bits (patches, sources) which overwrite one another when working with several versions of the package in a "normal" rpm build tree. - Panu - From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 10:26:45 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 11:26:45 +0100 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109189890.13305.107.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> Message-ID: <20050224112645.4ad1ef44@python2> Tom 'spot' Callaway wrote : > Working as fast as I can... here is the first draft of the Naming Policy > for Fedora Extras. Its not 100% complete yet, there are at least two > sections missing, but it covers the bases for most new packagers. > > http://fedoraproject.org/wiki/PackageNamingGuidelines > > Feedback is welcome, and encouraged. One thing : In the "Renaming a package" section, you put : Provides: foo Obsoletes: foo I'd prefer having those versionned to the version of the last known package released with that name, in case the package should be renamed back some day. Typically : You have foo = 1.0-1 that you want to rename to libfoo, then : Provides: foo = %{version}-%{release} Obsoletes: foo <= 1.0-1 Now, say the upstream project changes the name to "foo" for their 1.1 release... having those versions in will save a lot of trouble for upgrades and updates when changing back to the new upstream name. Thoughts? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.18 0.32 0.27 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 10:35:56 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 11:35:56 +0100 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109193452.24989.46.camel@chip.laiskiainen.org> <1109200220.13305.138.camel@localhost.localdomain> Message-ID: <20050224113556.00ca9d6d@python2> Panu Matilainen wrote : > Thanks, looks good. One thing which is open to discussion I think is > post-release non-numeric versions like 1.0 -> 1.0a where the 'a' doesn't > *have* to move to release tag from rpm's POV. I don't mind either way, > perhaps it's best to KISS (like the current draft has) and simply move > *all* non-numeric bits to release instead of having separate cases for > pre- and post-releases. Same here... the gkrellm post-release example where the "a" is moved to the release doesn't seem necessary to me, as it'll go incrementing. Pretty much like 1.0 -> 1.0pl1 -> 1.1 which won't cause any trouble. But I think I'm merely pointing this out as RH/FC has always left post-release version tags like these in the version... and like Panu, I'm not against the change, especially since it's now so well documented ;-) Great work Spot! (and those who wrote the original bits too) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.32 0.30 0.27 From cra at WPI.EDU Thu Feb 24 14:20:10 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Thu, 24 Feb 2005 09:20:10 -0500 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <20050224113556.00ca9d6d@python2> References: <1109189890.13305.107.camel@localhost.localdomain> <1109193452.24989.46.camel@chip.laiskiainen.org> <1109200220.13305.138.camel@localhost.localdomain> <20050224113556.00ca9d6d@python2> Message-ID: <20050224142010.GA11237@angus.ind.WPI.EDU> On Thu, Feb 24, 2005 at 11:35:56AM +0100, Matthias Saou wrote: > like 1.0 -> 1.0pl1 -> 1.1 which won't cause any trouble. Will this cause trouble? 3.0 -> 3.0pl1 -> 3.0pl2 -> 3.0.1 -> 3.0.1pl1 ? From tcallawa at redhat.com Thu Feb 24 15:28:53 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Feb 2005 09:28:53 -0600 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <20050224112645.4ad1ef44@python2> References: <1109189890.13305.107.camel@localhost.localdomain> <20050224112645.4ad1ef44@python2> Message-ID: <1109258933.13305.160.camel@localhost.localdomain> On Thu, 2005-02-24 at 11:26 +0100, Matthias Saou wrote: >I'd prefer having those versionned to the version of the last known package >released with that name, in case the package should be renamed back some >day. Agreed. I've added that. ~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 Thu Feb 24 15:33:33 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Feb 2005 09:33:33 -0600 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <20050224113556.00ca9d6d@python2> References: <1109189890.13305.107.camel@localhost.localdomain> <1109193452.24989.46.camel@chip.laiskiainen.org> <1109200220.13305.138.camel@localhost.localdomain> <20050224113556.00ca9d6d@python2> Message-ID: <1109259214.13305.166.camel@localhost.localdomain> On Thu, 2005-02-24 at 11:35 +0100, Matthias Saou wrote: >Panu Matilainen wrote : > >> Thanks, looks good. One thing which is open to discussion I think is >> post-release non-numeric versions like 1.0 -> 1.0a where the 'a' doesn't >> *have* to move to release tag from rpm's POV. I don't mind either way, >> perhaps it's best to KISS (like the current draft has) and simply move >> *all* non-numeric bits to release instead of having separate cases for >> pre- and post-releases. > >Same here... the gkrellm post-release example where the "a" is moved to the >release doesn't seem necessary to me, as it'll go incrementing. Pretty much >like 1.0 -> 1.0pl1 -> 1.1 which won't cause any trouble. Doing it the way I've documented makes it less likely that we'll hit the need for Epoch in a lot of cases. And the cases like gkrellm fit in nicely enough both ways so it can't hurt to standardize it in the non-numeric release case for packagers that are new (or just confused). Basically, I think the documented method is the simplest method. Hopefully, the Fedora Core folks will see it that way as well, but if not, we'll manage somehow. ;) > ~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 Feb 24 16:53:58 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 24 Feb 2005 18:53:58 +0200 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> Message-ID: <1109264038.6386.387.camel@bobcat.mine.nu> On Thu, 2005-02-24 at 09:43 +0200, Panu Matilainen wrote: > I just don't think that renaming spec to some awfully long name buys you > any safety at all and only looks ugly as hell :) The SRPM can contain > other bits (patches, sources) which overwrite one another when working > with several versions of the package in a "normal" rpm build tree. Seconded. From ville.skytta at iki.fi Thu Feb 24 17:07:40 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 24 Feb 2005 19:07:40 +0200 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109189890.13305.107.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> Message-ID: <1109264860.6386.395.camel@bobcat.mine.nu> On Wed, 2005-02-23 at 14:18 -0600, Tom 'spot' Callaway wrote: > http://fedoraproject.org/wiki/PackageNamingGuidelines > > Feedback is welcome, and encouraged. One point I did not already see mentioned: it's a good idea to check also what the rest of the world uses for a package's %{name}. If there's a common trend to call it something, and it does not conflict with the rest of our guidelines, it'd be a good idea to follow that. Some places where this can be easily checked: http://rpm.pbone.net/ http://www.rpmseek.com/ http://rpmfind.net/ Somewhat related example case: https://bugzilla.redhat.com/149532 From sopwith at redhat.com Thu Feb 24 18:52:58 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 13:52:58 -0500 (EST) Subject: [Fedora-packaging] PackageNamingGuidelines comments Message-ID: Hi guys, I'm late to the party, but overall it looks good. The stuff that could improve is eliminating "non-numeric version in release". For the sake of keeping things sane and simple, the Version: should normally match the upstream version. If there are versions such as 0.1beta that compare as "greater than" 0.1, then epoch should be used. That's one of the situations that epoch was created for. Making rules about munging version & release in the general case, for the sake of avoiding epoch in the special case, just complicates things unnecessarily. Inter-repo wars are going to exist whether or not Fedora chooses to use epoch - they have no bearing on this decision. Cheers, -- Elliot From notting at redhat.com Thu Feb 24 19:01:48 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Feb 2005 14:01:48 -0500 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109189890.13305.107.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> Message-ID: <20050224190148.GA11472@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > Working as fast as I can... here is the first draft of the Naming Policy > for Fedora Extras. Its not 100% complete yet, there are at least two > sections missing, but it covers the bases for most new packagers. > > http://fedoraproject.org/wiki/PackageNamingGuidelines > > Feedback is welcome, and encouraged. Reading the current document: Package Version ... If the version is non-numeric (contains tags that are not letters) ... That doesn't sound right. Moreover, I disagree - upstream versioning should be followed wherever possible. I suppose it depends on the package, though. To pull some recent examples: squid - goes in Version cman - goes in Release Perhaps a quick metric is that if the upstream is: 1.0-preX it goes in Release, while 1.0.x goes in Version. Another way to potentially look at it is that alpha/beta may go in Release, but *post* release letter affixes go in Version; for example, I wouldn't want to move OpenSSL to using the letters in the release. Bill From tcallawa at redhat.com Thu Feb 24 19:08:27 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Feb 2005 13:08:27 -0600 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <20050224190148.GA11472@nostromo.devel.redhat.com> References: <1109189890.13305.107.camel@localhost.localdomain> <20050224190148.GA11472@nostromo.devel.redhat.com> Message-ID: <1109272107.13305.213.camel@localhost.localdomain> On Thu, 2005-02-24 at 14:01 -0500, Bill Nottingham wrote: >Another way to potentially look at it is that alpha/beta may >go in Release, but *post* release letter affixes go in Version; >for example, I wouldn't want to move OpenSSL to using the letters >in the release. I could see that. So, basically: alpha/beta/pre/cvs builds that considered "pre" releases use the Release field to note the value as documented currently. "Final" release versions with characters can stay in the Version field. Thoughts? ~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 sopwith at redhat.com Thu Feb 24 19:14:55 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 14:14:55 -0500 (EST) Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109272107.13305.213.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <20050224190148.GA11472@nostromo.devel.redhat.com> <1109272107.13305.213.camel@localhost.localdomain> Message-ID: On Thu, 24 Feb 2005, Tom 'spot' Callaway wrote: > On Thu, 2005-02-24 at 14:01 -0500, Bill Nottingham wrote: > > >Another way to potentially look at it is that alpha/beta may > >go in Release, but *post* release letter affixes go in Version; > >for example, I wouldn't want to move OpenSSL to using the letters > >in the release. > > I could see that. > > So, basically: > > alpha/beta/pre/cvs builds that considered "pre" releases use the Release > field to note the value as documented currently. > > "Final" release versions with characters can stay in the Version field. > > Thoughts? This is definitely the right direction. Handling alpha/beta releases isn't as high a priority as dealing with the typical release naming schemes. -- Elliot From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 19:18:08 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 20:18:08 +0100 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: References: Message-ID: <20050224201808.61ad3389@python2> Elliot Lee wrote : > Hi guys, I'm late to the party, but overall it looks good. > > The stuff that could improve is eliminating "non-numeric version in > release". For the sake of keeping things sane and simple, the Version: > should normally match the upstream version. If there are versions such as > 0.1beta that compare as "greater than" 0.1, then epoch should be used. > That's one of the situations that epoch was created for. Making rules > about munging version & release in the general case, for the sake of > avoiding epoch in the special case, just complicates things unnecessarily. > > Inter-repo wars are going to exist whether or not Fedora chooses to use > epoch - they have no bearing on this decision. So you mean that external repository maintainers like me can't participate in the discussion or decision? :-) A bit more seriously, though. I really don't like epoch... Sure, it exists for the reason you state, but the current guideline is by far the most sane one we can all agree on, not only for inter-repo compatibility. For instance, what are you going to do when the package is named 1.0-beta1 (and there are lots like this), as rpm doesn't allow dashes in the version? You're going to have to do something a bit ugly to your %{version} and %{source} lines at the least... and in the end, it saves some headaches to simply use a 0.something release tag for upstream pre-release of a given %{version} and tuck the details in that "something" part. What I usually do : %define prever beta1 Version: 1.0 Release: 0.1.%{prever} Source: foo-%{version}%{?prever:-%{prever}}.tar.gz same for %setup line and eventually, but rarely, others Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.00 0.17 0.29 From ville.skytta at iki.fi Thu Feb 24 19:20:12 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 24 Feb 2005 21:20:12 +0200 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: References: Message-ID: <1109272812.1745.18.camel@bobcat.mine.nu> On Thu, 2005-02-24 at 13:52 -0500, Elliot Lee wrote: > Inter-repo wars are going to exist whether or not Fedora chooses to use > epoch - they have no bearing on this decision. Non-zero epochs are very inconvenient for 3rd party packagers in general, and especially those who need versioned dependencies and try to achieve cross-distro specfiles. It's not only "inter-repo"; think "upstream", non-FOSS vendors etc. Yeah, those aren't necessarily the primary target group for FC/FE, but we have a simple, documented workaround that does not make our life harder, and certainly does make someone's easier, so why not apply it? Epochs may also cause nasty surprises even inside a single repository. They just aren't prominent enough. From sopwith at redhat.com Thu Feb 24 19:23:48 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 14:23:48 -0500 (EST) Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <20050224201808.61ad3389@python2> References: <20050224201808.61ad3389@python2> Message-ID: On Thu, 24 Feb 2005, Matthias Saou wrote: > A bit more seriously, though. I really don't like epoch... Sure, it exists > for the reason you state, but the current guideline is by far the most sane > one we can all agree on, not only for inter-repo compatibility. > For instance, what are you going to do when the package is named 1.0-beta1 > (and there are lots like this), as rpm doesn't allow dashes in the version? > You're going to have to do something a bit ugly to your %{version} and > %{source} lines at the least... and in the end, it saves some headaches to > simply use a 0.something release tag for upstream pre-release of a given > %{version} and tuck the details in that "something" part. You're definitely right that there will always be some special cases, and we'll have to deal them on a one-by-one basis. In that particular special case, I'd prefer to use "1.0beta1" as the version. However, the existence of this special case above doesn't prove that epoch is bad or the wrong way to handle things. It's important to keep the users in mind - their package searching and updating lives would be made a lot easier if the Version: is as close to upstream whenever possible. -- Elliot From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 19:23:49 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 20:23:49 +0100 Subject: [Fedora-packaging] Naming Policy (first draft) In-Reply-To: <1109272107.13305.213.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <20050224190148.GA11472@nostromo.devel.redhat.com> <1109272107.13305.213.camel@localhost.localdomain> Message-ID: <20050224202349.25b3d2f2@python2> Tom 'spot' Callaway wrote : > On Thu, 2005-02-24 at 14:01 -0500, Bill Nottingham wrote: > > >Another way to potentially look at it is that alpha/beta may > >go in Release, but *post* release letter affixes go in Version; > >for example, I wouldn't want to move OpenSSL to using the letters > >in the release. > > I could see that. > > So, basically: > > alpha/beta/pre/cvs builds that considered "pre" releases use the Release > field to note the value as documented currently. > > "Final" release versions with characters can stay in the Version field. > > Thoughts? This comes back to what Panu and I commented, and the gkrellm example given in the guidelines. If the upstream version is non-numeric but has always been "sane" to rpm version comparison, like it is the case for squid, openssl or gkrellm, then I'm all for leaving it in the version, where it rightfully belongs. So if "Final" versions stay untouched and the release mangling only applies to pre-releases, that's fine with me. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.04 0.12 0.19 From sopwith at redhat.com Thu Feb 24 19:26:01 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 14:26:01 -0500 (EST) Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <1109272812.1745.18.camel@bobcat.mine.nu> References: <1109272812.1745.18.camel@bobcat.mine.nu> Message-ID: On Thu, 24 Feb 2005, Ville [ISO-8859-1] Skytt? wrote: > > Inter-repo wars are going to exist whether or not Fedora chooses to use > > epoch - they have no bearing on this decision. > > Non-zero epochs are very inconvenient for 3rd party packagers in > general, and especially those who need versioned dependencies and try to > achieve cross-distro specfiles. It's not only "inter-repo"; think > "upstream", non-FOSS vendors etc. > > Yeah, those aren't necessarily the primary target group for FC/FE, but > we have a simple, documented workaround that does not make our life > harder, and certainly does make someone's easier, so why not apply it? The workaround /does/ make things harder in general: packagers will have to learn it, and users will have to decipher it. Neither of those things are as trivial as they seem - the proposed scheme is obvious to us only because we already understand it. > Epochs may also cause nasty surprises even inside a single repository. "may" == FUD :-) -- Elliot From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 24 19:27:52 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 24 Feb 2005 20:27:52 +0100 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: References: <20050224201808.61ad3389@python2> Message-ID: <20050224202752.28aba8b2@python2> Elliot Lee wrote : > You're definitely right that there will always be some special cases, and > we'll have to deal them on a one-by-one basis. In that particular special > case, I'd prefer to use "1.0beta1" as the version. > > However, the existence of this special case above doesn't prove that epoch > is bad or the wrong way to handle things. It's important to keep the users > in mind - their package searching and updating lives would be made a lot > easier if the Version: is as close to upstream whenever possible. Sure, but you've got to make the balance with what Ville just posted... ok, I'm probably a bit biased, but just like him, I think that the current "workaround", which is properly documented and easy to follow is definitely worth it. Oh, that and "epochs are a nightmare"... just ask jbj, he's probably seen some of the wildest bug reports ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3 Load : 0.27 0.12 0.15 From mattdm at mattdm.org Thu Feb 24 19:31:25 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 24 Feb 2005 14:31:25 -0500 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: References: <20050224201808.61ad3389@python2> Message-ID: <20050224193125.GA14348@jadzia.bu.edu> On Thu, Feb 24, 2005 at 02:23:48PM -0500, Elliot Lee wrote: > You're definitely right that there will always be some special cases, and > we'll have to deal them on a one-by-one basis. In that particular special > case, I'd prefer to use "1.0beta1" as the version. But of course that sorts after "1.0", meaning that an epoch is required for the final release. > However, the existence of this special case above doesn't prove that epoch > is bad or the wrong way to handle things. It's important to keep the users > in mind - their package searching and updating lives would be made a lot > easier if the Version: is as close to upstream whenever possible. But epochs make it even more confusing for "the users", since they're a) arbitrary and b) mostly invisible. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sopwith at redhat.com Thu Feb 24 19:36:00 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 24 Feb 2005 14:36:00 -0500 (EST) Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <20050224193125.GA14348@jadzia.bu.edu> References: <20050224201808.61ad3389@python2> <20050224193125.GA14348@jadzia.bu.edu> Message-ID: On Thu, 24 Feb 2005, Matthew Miller wrote: > On Thu, Feb 24, 2005 at 02:23:48PM -0500, Elliot Lee wrote: > > You're definitely right that there will always be some special cases, and > > we'll have to deal them on a one-by-one basis. In that particular special > > case, I'd prefer to use "1.0beta1" as the version. > > But of course that sorts after "1.0", meaning that an epoch is required for > the final release. (Yup) > > However, the existence of this special case above doesn't prove that epoch > > is bad or the wrong way to handle things. It's important to keep the users > > in mind - their package searching and updating lives would be made a lot > > easier if the Version: is as close to upstream whenever possible. > > But epochs make it even more confusing for "the users", since they're a) > arbitrary and b) mostly invisible. That's a good point. At the same time, if epoch is used correctly, it will be used only to help rpm comparisons along, and in that case being invisible is a benefit. It's sounding like most people are comfortable with a policy of "Use upstream version in Version:, unless rpm comparisons will get messed up, in which case you should munge the Release: using the guidelines given". -- Elliot From skvidal at phy.duke.edu Thu Feb 24 19:39:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 24 Feb 2005 14:39:52 -0500 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <20050224193125.GA14348@jadzia.bu.edu> References: <20050224201808.61ad3389@python2> <20050224193125.GA14348@jadzia.bu.edu> Message-ID: <1109273993.15658.23.camel@opus.phy.duke.edu> > > However, the existence of this special case above doesn't prove that epoch > > is bad or the wrong way to handle things. It's important to keep the users > > in mind - their package searching and updating lives would be made a lot > > easier if the Version: is as close to upstream whenever possible. > > But epochs make it even more confusing for "the users", since they're a) > arbitrary and b) mostly invisible. to be fair- yum lists epochs if they exist and are non-zero. So a user listing his/her local packages using yum will see them. they may not know what they mean - but they'll see them. epoch:ver-rel -sv From ville.skytta at iki.fi Thu Feb 24 19:48:39 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 24 Feb 2005 21:48:39 +0200 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <1109273993.15658.23.camel@opus.phy.duke.edu> References: <20050224201808.61ad3389@python2> <20050224193125.GA14348@jadzia.bu.edu> <1109273993.15658.23.camel@opus.phy.duke.edu> Message-ID: <1109274519.1745.38.camel@bobcat.mine.nu> On Thu, 2005-02-24 at 14:39 -0500, seth vidal wrote: > to be fair- yum lists epochs if they exist and are non-zero. Why not just make that: "yum lists epochs". If (none) == 0, show me the 0. From ville.skytta at iki.fi Thu Feb 24 19:50:10 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 24 Feb 2005 21:50:10 +0200 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: References: <1109272812.1745.18.camel@bobcat.mine.nu> Message-ID: <1109274611.1745.41.camel@bobcat.mine.nu> On Thu, 2005-02-24 at 14:26 -0500, Elliot Lee wrote: > The workaround /does/ make things harder in general: packagers will have > to learn it, and users will have to decipher it. Neither of those things > are as trivial as they seem - the proposed scheme is obvious to us only > because we already understand it. I think the proposed scheme is easier to explain to those who seek information how to name the packages than the unpredictability, bugs and wrinkles inherent with Epochs and/or non-numeric stuff in version comparisons. The former is also already documented. No, I don't like how it "looks" either. From tcallawa at redhat.com Thu Feb 24 23:28:38 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Feb 2005 17:28:38 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> Message-ID: <1109287718.13305.238.camel@localhost.localdomain> The idea of disttag is not present in the Naming Policy right now, but I think there is good reason to standardize how it should be used in Fedora Extras. In the event that a single spec file is used for multiple versions of Fedora Extras, it is feasible that two packages with identical "%{name}-%{version}-%{release}" values could exist. This could lead to confusion, especially since their contents provide the same application, merely compiled and linked for different environments and userlands. In this case, a %{disttag} is needed to differentiate between these two packages, in the Release: field. The %{disttag} value should be determined from the build-environment. Using redhat-release for this purpose seems like the sanest method. With this command, we can determine the version of the Red Hat/Fedora distribution present in the build-environment: rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release` The following chart presents the results: RHL 7.3: 7.3 RHL 8: 8.0 RHL 9: 9 RHEL 2.1 AS: 2.1AS RHEL 2.1 ES: 2.1ES RHEL 2.1 WS: 2.1WS RHEL 2.1 AW: 2.1AW RHEL 3 AS: 3AS RHEL 3 ES: 3ES RHEL 3 WS: 3WS RHEL 3 Desktop: 3Desktop RHEL 4 AS: 4AS RHEL 4 ES: 4ES RHEL 4 WS: 4WS RHEL 4 Desktop: 4Desktop FC-1: 1 FC-2: 2 FC-3: 3 Now, in theory, we would have a problem with Fedora Core and Red Hat Linux release versions overlapping, but hopefully, by the time Fedora Core 9 is current, there will be few remaining users of Red Hat Linux 9. A bigger problem is dealing with the overlap of RHEL and Fedora Core releases. The following rpmmacros aren't terribly pretty, but they do work. %disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')} %rheldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/[^0-9.]//g' -e 's/^/EL/')} %rhldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/RH/')} %fcdisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/FC/')} %disttag %{expand:%%(if echo %{disttaglong} | grep "[^0-9.]" > /dev/null; then \ echo %{rheldisttag} \ else \ case "%{disttaglong}" in \ ( "6.2" | "7.0" | "7.1" | "7.2" | "7.3" | "8.0" | "9" ) \ echo %{rhldisttag} \ ;; \ ( "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" ) \ echo %{fcdisttag} \ ;; \ esac; \ fi;)} With macros like these, it is then possible to use %{disttag} in the spec to allow a single spec file to be used for multiple versions of Fedora (and outside of Fedora Extras, for RHEL and RHL). Maintainers would not be required to use %{disttag}. However, should they choose to do so, it should be placed at the end of the release field, preceeded by a period, e.g. Release: 1.%{disttag}. %{disttag} should never be hardcoded in a spec, it will be assigned by the buildsystem based on the version of the package owning /etc/redhat-release. Feedback, thoughts, and macro improvements welcome. ~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 Thu Feb 24 23:32:11 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Feb 2005 17:32:11 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <1109287718.13305.238.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> Message-ID: <1109287931.13305.241.camel@localhost.localdomain> On Thu, 2005-02-24 at 17:28 -0600, Tom 'spot' Callaway wrote: >With macros like these, it is then possible to use %{disttag} in the >spec to allow a single spec file to be used for multiple versions of >Fedora (and outside of Fedora Extras, for RHEL and RHL). Addendum: The %{disttag} values would be: RH6.2, RH7.0, RH7.1, RH7.2, RH7.3, RH8.0, RH9 EL2.1, EL3, EL4 FC1, FC2, FC3, FC4, ... ~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 dag at wieers.com Thu Feb 24 23:49:27 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 25 Feb 2005 00:49:27 +0100 (CET) Subject: [Fedora-packaging] disttag In-Reply-To: <1109287931.13305.241.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> Message-ID: On Thu, 24 Feb 2005, Tom 'spot' Callaway wrote: > On Thu, 2005-02-24 at 17:28 -0600, Tom 'spot' Callaway wrote: > > >With macros like these, it is then possible to use %{disttag} in the > >spec to allow a single spec file to be used for multiple versions of > >Fedora (and outside of Fedora Extras, for RHEL and RHL). > > Addendum: > > The %{disttag} values would be: > > RH6.2, RH7.0, RH7.1, RH7.2, RH7.3, RH8.0, RH9 > EL2.1, EL3, EL4 > FC1, FC2, FC3, FC4, ... With the high probability of being flamed again, RPMforge settled for: 0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5 with the advantage of having an upgrade path between EL and FC. I know it's controversial but at least if fulfills an important goal (even though Red Hat does not support upgrades between Fedora and Enterprise). In the past one of the problems was that RH > FC and therefor RH9 packages would be newer than FC1 packages. The current scheme makes us independant of whatever new name will be given by marketing if we are somewhere in 2008. There is a known catch here with this scheme (numeric part of disttag in release part). Disttags are never part of the SPEC file in our case but the pre-processing of the SPEC file before building makes sure it is there when it is needed. We also have a special disttag '0' to indicate a distribution-agnostic package. Which we mainly use for big packages (artwork, game data, ...). Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From tcallawa at redhat.com Fri Feb 25 00:16:12 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Feb 2005 18:16:12 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> Message-ID: <1109290572.13305.249.camel@localhost.localdomain> On Fri, 2005-02-25 at 00:49 +0100, Dag Wieers wrote: >With the high probability of being flamed again, RPMforge settled for: > >0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5 > >with the advantage of having an upgrade path between EL and FC. I know >it's controversial but at least if fulfills an important goal (even though >Red Hat does not support upgrades between Fedora and Enterprise). The very topic is outside of the scope of Fedora Extras, however, no one is trying to make life harder for anyone upgrading between Fedora and Enterprise (their life is painful enough). I'm not opposed to it. Would you be willing to try and modify the macros I posted earlier to fit that schema? >Disttags are never part of the SPEC file in our case but the >pre-processing of the SPEC file before building makes sure it is there >when it is needed. The goal of the macros is to have %{disttag} defined by the build environment, and thus, always be correct, rather than having to pass a value to the spec for some packages that use it, since some packages won't. >We also have a special disttag '0' to indicate a distribution-agnostic >package. Which we mainly use for big packages (artwork, game data, ...). IMHO, these packages don't need a disttag at all if they're truly distribution agnostic. ~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 Fri Feb 25 00:48:12 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Feb 2005 18:48:12 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <1109290572.13305.249.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> Message-ID: <1109292492.13305.254.camel@localhost.localdomain> On Thu, 2005-02-24 at 18:16 -0600, Tom 'spot' Callaway wrote: >On Fri, 2005-02-25 at 00:49 +0100, Dag Wieers wrote: > >>With the high probability of being flamed again, RPMforge settled for: >> >>0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5 >I'm not opposed to it. Would you be willing to try and modify the macros >I posted earlier to fit that schema? OK. Here is a way to make the macros fit that schema: # Disttag macros (you really only want to use %{disttag}) # When we get to Fedora Core 6, we'll need to revisit this. %disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')} %rheldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/[^0-9.]//g' -e 's/^/el/')} %rhldisttag %{expand:%%(echo %{disttaglong} | cut -d "." -f 1 | sed -e 's/^/rh/')} %fcdisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/fc/')} %disttag %{expand:%%(if echo %{disttaglong} | grep "[^0-9.]" > /dev/null; then \ case "%{rheldisttag}" in \ ( "el2" ) \ echo 0.%{rheldisttag} \ ;; \ ( "el3" ) \ echo 1.%{rheldisttag} \ ;; \ ( "el4" ) \ echo 2.%{rheldisttag} \ ;; \ ( "el5" ) \ echo 3.%{rheldisttag} \ ;; \ esac; \ else \ case "%{disttaglong}" in \ ( "7.0" | "7.1" | "7.2" | "7.3" | "8" | "9" ) \ echo 0.%{rhldisttag} \ ;; \ ( "1" | "2" | "3" ) \ echo 1.%{fcdisttag} \ ;; \ ("4" | "5" | "6" ) \ echo 2.%{fcdisttag} \ ;; \ esac; \ fi;)} This changes the valid disttag values to: 0.el2 0.rh7 0.rh8 0.rh9 1.el3 1.fc1 1.fc2 1.fc3 2.el4 2.fc4 2.fc5 2.fc6 3.el5 ~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 carwyn at carwyn.com Fri Feb 25 00:53:13 2005 From: carwyn at carwyn.com (Carwyn Edwards) Date: Fri, 25 Feb 2005 00:53:13 +0000 Subject: [Fedora-packaging] disttag In-Reply-To: <1109287718.13305.238.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> Message-ID: <421E76F9.2080908@carwyn.com> Tom 'spot' Callaway wrote: >In the event that a single spec file is used for multiple versions of >Fedora Extras, it is feasible that two packages with identical >"%{name}-%{version}-%{release}" values could exist. > This is going on a tanget I admit but .. looking forwards couldn't RPM be taught to use a specific DistTag: tag for this. RPM version comparisons could then be based on something like %{disttag}:%{epoch}:%{version}-%{release} (%{disttag} == 0 signifying a dist agnostic package). Rpmbuild could even implicitly set this using a disttag macro like the one you suggest. To keep overloading the Release: tag with more implicit information seems wrong. Carwyn From dag at wieers.com Fri Feb 25 01:07:01 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 25 Feb 2005 02:07:01 +0100 (CET) Subject: [Fedora-packaging] disttag In-Reply-To: <1109290572.13305.249.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> Message-ID: On Thu, 24 Feb 2005, Tom 'spot' Callaway wrote: > On Fri, 2005-02-25 at 00:49 +0100, Dag Wieers wrote: > > >With the high probability of being flamed again, RPMforge settled for: > > > >0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5 > > > >with the advantage of having an upgrade path between EL and FC. I know > >it's controversial but at least if fulfills an important goal (even though > >Red Hat does not support upgrades between Fedora and Enterprise). > > The very topic is outside of the scope of Fedora Extras, however, no one > is trying to make life harder for anyone upgrading between Fedora and > Enterprise (their life is painful enough). > > I'm not opposed to it. Would you be willing to try and modify the macros > I posted earlier to fit that schema? > > >Disttags are never part of the SPEC file in our case but the > >pre-processing of the SPEC file before building makes sure it is there > >when it is needed. > > The goal of the macros is to have %{disttag} defined by the build > environment, and thus, always be correct, rather than having to pass a > value to the spec for some packages that use it, since some packages > won't. Ok, in my opinion it's better to have every package adore to the disttag for the sole reason that you have a grip on what is upgraded and what isn't. Of course, that's what the Distribution-header can be used for (if Red Hat starts using it ! :)) On the other hand the Distribution-header does not make up for unique filenames, which I think is in favor of mandatory disttags. (Although filenames could be renamed to reflect the disttag, without 'polluting' the release-tag). Previous threads have touched the same subject with all the different opinions attached to it :) PS Another reason why we do not have the disttag inside a macro is because the SRPMs are distribution agnostic too. If the 'dot' is part of the macro and the macro is void when building the SRPM you can achieve the same result. But a single rpmbuild --rebuild will no longer be sufficient, unless you rewrite the SPEC file and define the voided disttag. If you do that, you might as well pre-process the SPEC file before building anyway. > >We also have a special disttag '0' to indicate a distribution-agnostic > >package. Which we mainly use for big packages (artwork, game data, ...). > > IMHO, these packages don't need a disttag at all if they're truly > distribution agnostic. I agree, but on the other hand, tools should be able to tell (by using globs) what packages are distribution agnostic, and a single '0' is something you can more easily glob onto, than the absence of any disttag. I know this is not the best reason to have '0', but checking each file to see if it does not have the disttag (out of a list of disttags) is much harder than just looking of there is a '0' before the repotag. eg. ln -sf packages/*/*.0.$repotag.$arch.rpm redhat/el3/$arch/$repotag/ And the '0' is harmless. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From carwyn at carwyn.com Fri Feb 25 01:58:20 2005 From: carwyn at carwyn.com (Carwyn Edwards) Date: Fri, 25 Feb 2005 01:58:20 +0000 Subject: [Fedora-packaging] disttag In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> Message-ID: <421E863C.9030301@carwyn.com> Dag Wieers wrote: >On the other hand the Distribution-header does not make up for unique >filenames, which I think is in favor of mandatory disttags. (Although >filenames could be renamed to reflect the disttag, without 'polluting' the >release-tag). > Do you mean something like this: %{name}-%{version}-%{release}.%{disttag}.%{arch}.rpm .. where %{disttag} is _not_ an overloaded part of the "Release:" but rather a distinct entity derived from build environment - a bit like %{arch} perhaps with a tag to hard wire it in the spec if required, say "DistTag: any" for agnostic (I'm creating a new RPM tag in this example rather than changing the semantics of "Distribution:"). This would relate well to my previous suggestion where %{disttag} would not be evaluated as part of the release on version comparisons but rather prior to the epoch: %{disttag}:%{epoch}:%{version}-%{release} (hmm, maybe after the epoch would be better?). Carwyn From dag at wieers.com Fri Feb 25 02:23:25 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 25 Feb 2005 03:23:25 +0100 (CET) Subject: [Fedora-packaging] disttag In-Reply-To: <421E863C.9030301@carwyn.com> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> <421E863C.9030301@carwyn.com> Message-ID: On Fri, 25 Feb 2005, Carwyn Edwards wrote: > Dag Wieers wrote: > > > On the other hand the Distribution-header does not make up for unique > > filenames, which I think is in favor of mandatory disttags. (Although > > filenames could be renamed to reflect the disttag, without 'polluting' the > > release-tag). > > Do you mean something like this: > > %{name}-%{version}-%{release}.%{disttag}.%{arch}.rpm > > .. where %{disttag} is _not_ an overloaded part of the "Release:" but rather a > distinct entity derived from build environment - a bit like %{arch} perhaps > with a tag to hard wire it in the spec if required, say "DistTag: any" for > agnostic (I'm creating a new RPM tag in this example rather than changing the > semantics of "Distribution:"). > > This would relate well to my previous suggestion where %{disttag} would not > be evaluated as part of the release on version comparisons but rather prior to > the epoch: %{disttag}:%{epoch}:%{version}-%{release} (hmm, maybe after the > epoch would be better?). The problem with such a scheme of course is that it requires a change to RPM (and all RPM related tools), and for that reason alone is not backward compatible. If you want packages from a certain distribution (or repo) to have a higher priority than other packages disregarding the EVR (or VR). I think that functionality is best put into Yum, Apt, Smart or up2date. Because they understand the notion of repositories. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From carwyn at carwyn.com Fri Feb 25 03:52:37 2005 From: carwyn at carwyn.com (Carwyn Edwards) Date: Fri, 25 Feb 2005 03:52:37 +0000 Subject: [Fedora-packaging] disttag In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> <421E863C.9030301@carwyn.com> Message-ID: <421EA105.2020801@carwyn.com> Dag Wieers wrote: >The problem with such a scheme of course is that it requires a change to >RPM (and all RPM related tools), > > I know, I know - I'm more thinking ahead to when the tag mangling goes away :-) In the meantime, the current direction of the package naming looks good. So far it's letting me define a local naming policy of: %{name}-%{verison}-%{release}.%{local_release}.%{repo} Where: %{release}: Upstream release version if it exists otherwise |0| (zero). %{local_release}: Local release version that adheres to the same rules as the Fedora release field if %{release} is 0, otherwise use a single integer. %{repo}: Local repo tag. I suspect that many Fedora users have their own local repos (maybe not as big as FreshRPMs or Dag :-) ) and being able to define a naming policy that works with upstream is a good thing. A common example of what we need to do is to patch Fedora rpms with things that haven't been integrated yet or to add some feature to the build options. Carwyn From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 25 10:42:27 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 25 Feb 2005 11:42:27 +0100 Subject: [Fedora-packaging] disttag In-Reply-To: <1109292492.13305.254.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> <1109292492.13305.254.camel@localhost.localdomain> Message-ID: <20050225114227.0d55c226@python2> Tom 'spot' Callaway wrote : > %disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep > Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')} Hmm, haven't had enough coffee yet, but is the above just to get the version of the package that contains the redhat-release file!? If so, what about this instead : %(rpm -qf --qf '%{version}' /etc/redhat-release) I _must_ be missing something... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3.radeon Load : 0.23 0.57 0.70 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 25 10:55:05 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 25 Feb 2005 11:55:05 +0100 Subject: [Fedora-packaging] disttag In-Reply-To: <1109287718.13305.238.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> Message-ID: <20050225115505.5840d895@python2> Tom 'spot' Callaway wrote : > Maintainers would not be required to use %{disttag}. However, should > they choose to do so, it should be placed at the end of the release > field, preceeded by a period, e.g. Release: 1.%{disttag}. > > %{disttag} should never be hardcoded in a spec, it will be assigned by > the buildsystem based on the version of the package owning > /etc/redhat-release. > > Feedback, thoughts, and macro improvements welcome. I'm a bit confused... you mean that initial spec files will contain this %{disttag} but that the final one in the source rpm will contain the hardcoded value instead? This will produce quite a lot of confusion for "quick rebuilds" of source packages with hardcoded releases on other distributions... and I don't really understand why we want to use rpm and macros for this whole substitution if mangling of the spec gets done in the end. An easy to way to fix this would be to have "%{?disttag}" appended to the "Release:" line of the spec by the build system, and have the "." returned by the macro (or use a longer "%{?disttag:.%{disttag}}"). That way, when disttag is defined (by a newer redhat-rpm-config for instance) it'll be expanded for the build, but if it isn't, the build will still work with no changes and produce a package with a simple integer release tag. More thoughts? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3.radeon Load : 0.15 0.14 0.31 From pmatilai at welho.com Fri Feb 25 13:26:14 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 25 Feb 2005 15:26:14 +0200 (EET) Subject: [Fedora-packaging] disttag In-Reply-To: <1109290572.13305.249.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> Message-ID: On Thu, 24 Feb 2005, Tom 'spot' Callaway wrote: > On Fri, 2005-02-25 at 00:49 +0100, Dag Wieers wrote: > >> With the high probability of being flamed again, RPMforge settled for: >> >> 0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5 >> >> with the advantage of having an upgrade path between EL and FC. I know >> it's controversial but at least if fulfills an important goal (even though >> Red Hat does not support upgrades between Fedora and Enterprise). > > The very topic is outside of the scope of Fedora Extras, however, no one > is trying to make life harder for anyone upgrading between Fedora and > Enterprise (their life is painful enough). I don't see why we should add cruft to our release tags to help people shoot their own feet either. I'm not going to start flamewar over this - there are worse things in life that RPMforge disttags :) but I simply don't see no value added whatsoever by trying to create an upgrade path for *extras* when one doesn't exist for the actual products. - Panu - From skvidal at phy.duke.edu Fri Feb 25 13:34:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 08:34:11 -0500 Subject: [Fedora-packaging] disttag In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> Message-ID: <1109338451.16521.81.camel@cutter> >I don't see why we should add cruft to our release tags to help people >shoot their own feet either. I'm not going to start flamewar over this - >there are worse things in life that RPMforge disttags :) but I simply >don't see no value added whatsoever by trying to create an upgrade path >for *extras* when one doesn't exist for the actual products. > +1 -sv From pmatilai at welho.com Fri Feb 25 13:40:14 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 25 Feb 2005 15:40:14 +0200 (EET) Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: References: <20050224201808.61ad3389@python2> <20050224193125.GA14348@jadzia.bu.edu> Message-ID: On Thu, 24 Feb 2005, Elliot Lee wrote: > It's sounding like most people are comfortable with a policy of "Use > upstream version in Version:, unless rpm comparisons will get messed up, > in which case you should munge the Release: using the guidelines given". "unless rpm comparisons will get messed up" translates to "if versions have non-numeric data in them" most of the time. Like I said earlier I'm not opposed to allowing alphabets in versions for post-release updates in sane cases like 1.0 -> 1.0a BUT allowing non-numeric stuff in version leaves a wide opening for mistakes, leading to unnecessary epoch inflation. Epochs ARE evil and confusing to users and packagers as well, much more so than munged version-release tags (simply an empirical observation made over the years on various mailing lists). - Panu - From tcallawa at redhat.com Fri Feb 25 13:53:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 25 Feb 2005 07:53:39 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050225115505.5840d895@python2> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> Message-ID: <1109339620.13305.261.camel@localhost.localdomain> On Fri, 2005-02-25 at 11:55 +0100, Matthias Saou wrote: >An easy to way to fix this would be to have "%{?disttag}" appended to the >"Release:" line of the spec by the build system, and have the "." returned >by the macro (or use a longer "%{?disttag:.%{disttag}}"). That way, when >disttag is defined (by a newer redhat-rpm-config for instance) it'll be >expanded for the build, but if it isn't, the build will still work with no >changes and produce a package with a simple integer release tag. This is what I meant, but you said it better than I did. I prefer the %{?disttag:.%{disttag}} syntax for use, if for no other reason than it makes the macro a little cleaner. ~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 Fri Feb 25 13:56:30 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 25 Feb 2005 07:56:30 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> Message-ID: <1109339791.13305.265.camel@localhost.localdomain> On Fri, 2005-02-25 at 15:26 +0200, Panu Matilainen wrote: >I don't see why we should add cruft to our release tags to help people >shoot their own feet either. I'm not going to start flamewar over this - >there are worse things in life that RPMforge disttags :) but I simply >don't see no value added whatsoever by trying to create an upgrade path >for *extras* when one doesn't exist for the actual products. Here's the point: Its not mandatory. If you're not trying to work the "single spec/multiple Fedoras" case, then don't use it. The standard will make that very clear. ~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 Fri Feb 25 14:05:23 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 25 Feb 2005 08:05:23 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050225114227.0d55c226@python2> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> <1109292492.13305.254.camel@localhost.localdomain> <20050225114227.0d55c226@python2> Message-ID: <1109340323.13305.268.camel@localhost.localdomain> On Fri, 2005-02-25 at 11:42 +0100, Matthias Saou wrote: >Tom 'spot' Callaway wrote : > >> %disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep >> Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')} > >Hmm, haven't had enough coffee yet, but is the above just to get the >version of the package that contains the redhat-release file!? If so, what >about this instead : > >%(rpm -qf --qf '%{version}' /etc/redhat-release) > >I _must_ be missing something... You are. We can't use %{version} in the macro, because when its parsed at buildtime, it grabs the %{version} for the package being built, and replaces it before running the command. Hence the ickiness. ~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 pmatilai at welho.com Fri Feb 25 14:35:51 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 25 Feb 2005 16:35:51 +0200 (EET) Subject: [Fedora-packaging] disttag In-Reply-To: <1109339791.13305.265.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> <1109339791.13305.265.camel@localhost.localdomain> Message-ID: On Fri, 25 Feb 2005, Tom 'spot' Callaway wrote: > On Fri, 2005-02-25 at 15:26 +0200, Panu Matilainen wrote: > >> I don't see why we should add cruft to our release tags to help people >> shoot their own feet either. I'm not going to start flamewar over this - >> there are worse things in life that RPMforge disttags :) but I simply >> don't see no value added whatsoever by trying to create an upgrade path >> for *extras* when one doesn't exist for the actual products. > > Here's the point: Its not mandatory. If you're not trying to work the > "single spec/multiple Fedoras" case, then don't use it. > > The standard will make that very clear. In case I wasn't clear: I'm not complaining about disttags at all, they're useful in many cases. What I'm complaining about is the IMHO silly extra stuff in the release tag for providing an upgrade path between products which aren't upgradable in reality. Plain fc3, fc4, el4 etc as disttags are perfectly fine by me. - Panu - From cra at WPI.EDU Fri Feb 25 15:28:20 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Fri, 25 Feb 2005 10:28:20 -0500 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <1109274519.1745.38.camel@bobcat.mine.nu> References: <20050224201808.61ad3389@python2> <20050224193125.GA14348@jadzia.bu.edu> <1109273993.15658.23.camel@opus.phy.duke.edu> <1109274519.1745.38.camel@bobcat.mine.nu> Message-ID: <20050225152820.GC19139@angus.ind.WPI.EDU> On Thu, Feb 24, 2005 at 09:48:39PM +0200, Ville Skytt? wrote: > On Thu, 2005-02-24 at 14:39 -0500, seth vidal wrote: > > > to be fair- yum lists epochs if they exist and are non-zero. > > Why not just make that: "yum lists epochs". > If (none) == 0, show me the 0. Wasn't there a bug in rpm where (none) != 0 ? From skvidal at phy.duke.edu Fri Feb 25 15:30:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 10:30:08 -0500 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <20050225152820.GC19139@angus.ind.WPI.EDU> References: <20050224201808.61ad3389@python2> <20050224193125.GA14348@jadzia.bu.edu> <1109273993.15658.23.camel@opus.phy.duke.edu> <1109274519.1745.38.camel@bobcat.mine.nu> <20050225152820.GC19139@angus.ind.WPI.EDU> Message-ID: <1109345408.10989.9.camel@opus.phy.duke.edu> > Wasn't there a bug in rpm where (none) != 0 ? > long ago, in the bad old days. let us not speak of it again. -sv From cra at WPI.EDU Fri Feb 25 15:31:48 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Fri, 25 Feb 2005 10:31:48 -0500 Subject: [Fedora-packaging] disttag In-Reply-To: <1109287718.13305.238.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> Message-ID: <20050225153148.GD19139@angus.ind.WPI.EDU> On Thu, Feb 24, 2005 at 05:28:38PM -0600, Tom 'spot' Callaway wrote: > rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release` Instead of hard-coding the filename, how about using the Provides: that is in the package? rpm -q --whatprovides --qf "%{version}\n" redhat-release From tcallawa at redhat.com Fri Feb 25 18:01:34 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 25 Feb 2005 12:01:34 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050225153148.GD19139@angus.ind.WPI.EDU> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> Message-ID: <1109354494.13305.270.camel@localhost.localdomain> On Fri, 2005-02-25 at 10:31 -0500, Chuck R. Anderson wrote: >On Thu, Feb 24, 2005 at 05:28:38PM -0600, Tom 'spot' Callaway wrote: >> rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release` > >Instead of hard-coding the filename, how about using the Provides: >that is in the package? > >rpm -q --whatprovides --qf "%{version}\n" redhat-release We can't use "--qf "%{version}\n" in the macro. ~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 dag at wieers.com Fri Feb 25 18:43:00 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 25 Feb 2005 19:43:00 +0100 (CET) Subject: [Fedora-packaging] disttag In-Reply-To: <1109354494.13305.270.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> Message-ID: On Fri, 25 Feb 2005, Tom 'spot' Callaway wrote: > On Fri, 2005-02-25 at 10:31 -0500, Chuck R. Anderson wrote: > >On Thu, Feb 24, 2005 at 05:28:38PM -0600, Tom 'spot' Callaway wrote: > >> rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release` > > > >Instead of hard-coding the filename, how about using the Provides: > >that is in the package? > > > >rpm -q --whatprovides --qf "%{version}\n" redhat-release > > We can't use "--qf "%{version}\n" in the macro. You can use: rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n' Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From ville.skytta at iki.fi Fri Feb 25 19:26:46 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 25 Feb 2005 21:26:46 +0200 Subject: [Fedora-packaging] disttag In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> Message-ID: <1109359606.15854.107.camel@bobcat.mine.nu> On Fri, 2005-02-25 at 19:43 +0100, Dag Wieers wrote: > You can use: > > rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n' ...or just %{VERSION} (in uppercase). From ville.skytta at iki.fi Fri Feb 25 19:29:45 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 25 Feb 2005 21:29:45 +0200 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <1109345408.10989.9.camel@opus.phy.duke.edu> References: <20050224201808.61ad3389@python2> <20050224193125.GA14348@jadzia.bu.edu> <1109273993.15658.23.camel@opus.phy.duke.edu> <1109274519.1745.38.camel@bobcat.mine.nu> <20050225152820.GC19139@angus.ind.WPI.EDU> <1109345408.10989.9.camel@opus.phy.duke.edu> Message-ID: <1109359785.15854.111.camel@bobcat.mine.nu> On Fri, 2005-02-25 at 10:30 -0500, seth vidal wrote: > > Wasn't there a bug in rpm where (none) != 0 ? > > > long ago, in the bad old days. It's still not completely gone. https://bugzilla.redhat.com/143301 > let us not speak of it again. Sorry, couldn't resist :) From skvidal at phy.duke.edu Fri Feb 25 19:35:46 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 25 Feb 2005 14:35:46 -0500 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <1109359785.15854.111.camel@bobcat.mine.nu> References: <20050224201808.61ad3389@python2> <20050224193125.GA14348@jadzia.bu.edu> <1109273993.15658.23.camel@opus.phy.duke.edu> <1109274519.1745.38.camel@bobcat.mine.nu> <20050225152820.GC19139@angus.ind.WPI.EDU> <1109345408.10989.9.camel@opus.phy.duke.edu> <1109359785.15854.111.camel@bobcat.mine.nu> Message-ID: <1109360146.23111.7.camel@cutter> On Fri, 2005-02-25 at 21:29 +0200, Ville Skytt? wrote: >On Fri, 2005-02-25 at 10:30 -0500, seth vidal wrote: >> > Wasn't there a bug in rpm where (none) != 0 ? >> > >> long ago, in the bad old days. > >It's still not completely gone. https://bugzilla.redhat.com/143301 > >> let us not speak of it again. > >Sorry, couldn't resist :) > LALALALA I can't hear you!! LALALALALALALALA -sv From tcallawa at redhat.com Fri Feb 25 21:58:07 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 25 Feb 2005 15:58:07 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <1109359606.15854.107.camel@bobcat.mine.nu> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> Message-ID: <1109368688.7400.14.camel@localhost.localdomain> On Fri, 2005-02-25 at 21:26 +0200, Ville Skytt? wrote: >On Fri, 2005-02-25 at 19:43 +0100, Dag Wieers wrote: > >> You can use: >> >> rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n' > >...or just %{VERSION} (in uppercase). Ok. New macros: # Disttag macros (you really only want to use %{disttag}) # When we get to Fedora Core 6, we'll need to revisit this. %disttaglong %{expand:%%(rpm -qf --qf '%{VERSION}' /etc/redhat-release)} %rheldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/[^0-9.]//g' -e 's/^/el/')} %rhldisttag %{expand:%%(echo %{disttaglong} | cut -d "." -f 1 | sed -e 's/^/rh/')} %fcdisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/fc/')} %disttag %{expand:%%(if echo %{disttaglong} | grep "[^0-9.]" > /dev/null; then \ case "%{rheldisttag}" in \ ( "el2" ) \ echo 0.%{rheldisttag} \ ;; \ ( "el3" ) \ echo 1.%{rheldisttag} \ ;; \ ( "el4" ) \ echo 2.%{rheldisttag} \ ;; \ ( "el5" ) \ echo 3.%{rheldisttag} \ ;; \ esac; \ else \ case "%{disttaglong}" in \ ( "7.0" | "7.1" | "7.2" | "7.3" | "8" | "9" ) \ echo 0.%{rhldisttag} \ ;; \ ( "1" | "2" | "3" ) \ echo 1.%{fcdisttag} \ ;; \ ("4" | "5" | "6" ) \ echo 2.%{fcdisttag} \ ;; \ esac; \ fi;)} Is anyone opposed to adopting the %{disttag} methodology as the documented method for supporting single spec files for multiple Fedora distros? If not, I'll start writing it up. ~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 notting at redhat.com Fri Feb 25 22:19:49 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Feb 2005 17:19:49 -0500 Subject: [Fedora-packaging] disttag In-Reply-To: <1109368688.7400.14.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> Message-ID: <20050225221949.GB26828@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > On Fri, 2005-02-25 at 21:26 +0200, Ville Skytt? wrote: > >On Fri, 2005-02-25 at 19:43 +0100, Dag Wieers wrote: > > > >> You can use: > >> > >> rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n' > > > >...or just %{VERSION} (in uppercase). > > Ok. New macros: So, every package BuildRequires: redhat-release? Frankly, I think it's somewhat gross. Not that I have better solutions off of the top of my head. Bill From tcallawa at redhat.com Fri Feb 25 22:23:29 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 25 Feb 2005 16:23:29 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050225221949.GB26828@nostromo.devel.redhat.com> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> <20050225221949.GB26828@nostromo.devel.redhat.com> Message-ID: <1109370210.7400.32.camel@localhost.localdomain> On Fri, 2005-02-25 at 17:19 -0500, Bill Nottingham wrote: >Tom 'spot' Callaway (tcallawa at redhat.com) said: >> On Fri, 2005-02-25 at 21:26 +0200, Ville Skytt? wrote: >> >On Fri, 2005-02-25 at 19:43 +0100, Dag Wieers wrote: >> > >> >> You can use: >> >> >> >> rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n' >> > >> >...or just %{VERSION} (in uppercase). >> >> Ok. New macros: > >So, every package BuildRequires: redhat-release? > >Frankly, I think it's somewhat gross. Not that I have better >solutions off of the top of my head. No properly installed system should be missing a package which Provides: redhat-release. This has been true for at least the last 5 years. If our buildroots don't have it, then thats a serious failure (its in System Environment/Base). And I don't disagree with your "gross" assessment, but its the least evil solution I could find. ~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 cra at WPI.EDU Fri Feb 25 22:48:27 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Fri, 25 Feb 2005 17:48:27 -0500 Subject: [Fedora-packaging] disttag In-Reply-To: <1109354494.13305.270.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> Message-ID: <20050225224827.GZ28055@angus.ind.WPI.EDU> On Fri, Feb 25, 2005 at 12:01:34PM -0600, Tom 'spot' Callaway wrote: > On Fri, 2005-02-25 at 10:31 -0500, Chuck R. Anderson wrote: > >On Thu, Feb 24, 2005 at 05:28:38PM -0600, Tom 'spot' Callaway wrote: > >> rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release` > > > >Instead of hard-coding the filename, how about using the Provides: > >that is in the package? > > > >rpm -q --whatprovides --qf "%{version}\n" redhat-release > > We can't use "--qf "%{version}\n" in the macro. Problems with %{version} aside, my point was that Jeff Johnson mentioned to me once that the best way to get the distro version package is to get what Provides: redhat-release, not hardcoding either /etc/redhat-release or the package name redhat-release. So: rpm -q --whatprovides redhat-release rather than: rpm -qf /etc/redhat-release From tcallawa at redhat.com Fri Feb 25 22:57:07 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 25 Feb 2005 16:57:07 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050225224827.GZ28055@angus.ind.WPI.EDU> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <20050225224827.GZ28055@angus.ind.WPI.EDU> Message-ID: <1109372227.7400.37.camel@localhost.localdomain> On Fri, 2005-02-25 at 17:48 -0500, Chuck R. Anderson wrote: >Problems with %{version} aside, my point was that Jeff Johnson >mentioned to me once that the best way to get the distro version >package is to get what Provides: redhat-release, not hardcoding either >/etc/redhat-release or the package name redhat-release. So: > >rpm -q --whatprovides redhat-release > >rather than: > >rpm -qf /etc/redhat-release Ehhh... I think this may be nit-picking, but its probably right. Alright. How about THESE macros: # Disttag macros (you really only want to use %{disttag}) # When we get to Fedora Core 6, we'll need to revisit this. %disttaglong %{expand:%%(rpm -q --whatprovides redhat-release --qf '%{VERSION}')} %rheldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/[^0-9.]//g' -e 's/^/el/')} %rhldisttag %{expand:%%(echo %{disttaglong} | cut -d "." -f 1 | sed -e 's/^/rh/')} %fcdisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/fc/')} %disttag %{expand:%%(if echo %{disttaglong} | grep "[^0-9.]" > /dev/null; then \ case "%{rheldisttag}" in \ ( "el2" ) \ echo 0.%{rheldisttag} \ ;; \ ( "el3" ) \ echo 1.%{rheldisttag} \ ;; \ ( "el4" ) \ echo 2.%{rheldisttag} \ ;; \ ( "el5" ) \ echo 3.%{rheldisttag} \ ;; \ esac; \ else \ case "%{disttaglong}" in \ ( "7.0" | "7.1" | "7.2" | "7.3" | "8" | "9" ) \ echo 0.%{rhldisttag} \ ;; \ ( "1" | "2" | "3" ) \ echo 1.%{fcdisttag} \ ;; \ ("4" | "5" | "6" ) \ echo 2.%{fcdisttag} \ ;; \ esac; \ fi;)} ~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 notting at redhat.com Fri Feb 25 23:02:31 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Feb 2005 18:02:31 -0500 Subject: [Fedora-packaging] disttag In-Reply-To: <1109370210.7400.32.camel@localhost.localdomain> References: <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> <20050225221949.GB26828@nostromo.devel.redhat.com> <1109370210.7400.32.camel@localhost.localdomain> Message-ID: <20050225230231.GD26828@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > If our buildroots don't have it, then thats a serious failure (its in > System Environment/Base). Well, you'd still want it to get pulled in via a dep somehow. Right now that would be via initscripts, which may or may not be in the build dependency chain. Bill From tcallawa at redhat.com Fri Feb 25 23:09:16 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 25 Feb 2005 17:09:16 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050225230231.GD26828@nostromo.devel.redhat.com> References: <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> <20050225221949.GB26828@nostromo.devel.redhat.com> <1109370210.7400.32.camel@localhost.localdomain> <20050225230231.GD26828@nostromo.devel.redhat.com> Message-ID: <1109372957.7400.44.camel@localhost.localdomain> On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote: >Tom 'spot' Callaway (tcallawa at redhat.com) said: >> If our buildroots don't have it, then thats a serious failure (its in >> System Environment/Base). > >Well, you'd still want it to get pulled in via a dep somehow. Right >now that would be via initscripts, which may or may not be in >the build dependency chain. So basically, its not safe to assume any of System Environment/Base is installed? Should all packages start having bash, coreutils, grep, etc, etc as BuildRequires: ? ~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 notting at redhat.com Fri Feb 25 23:20:26 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Feb 2005 18:20:26 -0500 Subject: [Fedora-packaging] disttag In-Reply-To: <1109372957.7400.44.camel@localhost.localdomain> References: <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> <20050225221949.GB26828@nostromo.devel.redhat.com> <1109370210.7400.32.camel@localhost.localdomain> <20050225230231.GD26828@nostromo.devel.redhat.com> <1109372957.7400.44.camel@localhost.localdomain> Message-ID: <20050225232026.GE26828@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote: > >Tom 'spot' Callaway (tcallawa at redhat.com) said: > >> If our buildroots don't have it, then thats a serious failure (its in > >> System Environment/Base). > > > >Well, you'd still want it to get pulled in via a dep somehow. Right > >now that would be via initscripts, which may or may not be in > >the build dependency chain. > > So basically, its not safe to assume any of System Environment/Base is > installed? > > Should all packages start having bash, coreutils, grep, etc, etc as > BuildRequires: ? There should be a stock list on the wiki somewhere; you can assume coreutils, gcc, make, etc., and whatever those pull in. Whether or not that means they'd pull in initscripts, I don't know. Bill From tcallawa at redhat.com Fri Feb 25 23:28:54 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 25 Feb 2005 17:28:54 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050225232026.GE26828@nostromo.devel.redhat.com> References: <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> <20050225221949.GB26828@nostromo.devel.redhat.com> <1109370210.7400.32.camel@localhost.localdomain> <20050225230231.GD26828@nostromo.devel.redhat.com> <1109372957.7400.44.camel@localhost.localdomain> <20050225232026.GE26828@nostromo.devel.redhat.com> Message-ID: <1109374134.7400.50.camel@localhost.localdomain> On Fri, 2005-02-25 at 18:20 -0500, Bill Nottingham wrote: >Tom 'spot' Callaway (tcallawa at redhat.com) said: >> On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote: >> >Tom 'spot' Callaway (tcallawa at redhat.com) said: >> >> If our buildroots don't have it, then thats a serious failure (its in >> >> System Environment/Base). >> > >> >Well, you'd still want it to get pulled in via a dep somehow. Right >> >now that would be via initscripts, which may or may not be in >> >the build dependency chain. >> >> So basically, its not safe to assume any of System Environment/Base is >> installed? >> >> Should all packages start having bash, coreutils, grep, etc, etc as >> BuildRequires: ? > >There should be a stock list on the wiki somewhere; you can assume >coreutils, gcc, make, etc., and whatever those pull in. Whether or >not that means they'd pull in initscripts, I don't know. coreutils requires pam, which requires initscripts. Kevin Bacon is in there somewhere too, but it means we don't need BuildRequires: redhat-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 ville.skytta at iki.fi Sat Feb 26 08:43:42 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 26 Feb 2005 10:43:42 +0200 Subject: [Fedora-packaging] disttag In-Reply-To: <20050225230231.GD26828@nostromo.devel.redhat.com> References: <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> <20050225221949.GB26828@nostromo.devel.redhat.com> <1109370210.7400.32.camel@localhost.localdomain> <20050225230231.GD26828@nostromo.devel.redhat.com> Message-ID: <1109407422.15854.128.camel@bobcat.mine.nu> On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote: > Tom 'spot' Callaway (tcallawa at redhat.com) said: > > If our buildroots don't have it, then thats a serious failure (its in > > System Environment/Base). > > Well, you'd still want it to get pulled in via a dep somehow. Right > now that would be via initscripts, which may or may not be in > the build dependency chain. Where are you planning to put these disttag macros anyway? Just document them, or include in some package, eg. redhat-rpm-config? Such a package could carry the necessary dependencies, if any. From Axel.Thimm at ATrpms.net Sat Feb 26 09:53:17 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 26 Feb 2005 10:53:17 +0100 Subject: [Fedora-packaging] Re: disttag In-Reply-To: <20050225221949.GB26828@nostromo.devel.redhat.com> References: <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> <20050225221949.GB26828@nostromo.devel.redhat.com> Message-ID: <20050226095317.GE22428@neu.nirvana> On Fri, Feb 25, 2005 at 05:19:49PM -0500, Bill Nottingham wrote: > Tom 'spot' Callaway (tcallawa at redhat.com) said: > > On Fri, 2005-02-25 at 21:26 +0200, Ville Skytt? wrote: > > >On Fri, 2005-02-25 at 19:43 +0100, Dag Wieers wrote: > > > > > >> You can use: > > >> > > >> rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n' > > > > > >...or just %{VERSION} (in uppercase). > > > > Ok. New macros: > > So, every package BuildRequires: redhat-release? > > Frankly, I think it's somewhat gross. Not that I have better > solutions off of the top of my head. why have the chrooted system do the guesswork, when the information is there at the rpmbuild level? rpmbuild --define 'disttag whatever' ... And if you can convince Jeff to patch up an automated suffix to the rpm tag you could keep the specfile totally clean from disttags, e.g. like they look like today. The idea has been brought to Jeff, but he thought we were asking for a Disttag tag in the rpm header and implemented this instead. In fact the best solution would be to have a releasesuffix macro/header tag which rpm automatically tags onto the releasetag, e.g. rpmbuild -bs --define 'releasesuffix .at' foo.spec produces the distro agnostic foo-1.2.3-4.at.src.rpm rpmbuild --rebuild --define 'releasesuffix rhel4.at' foo-1.2.3-4.at.src.rpm produces foo-1.2.3-4.rhel4.at.i386.rpm As a side effect the releasesuffix macro/header tag can be used both for disttags as well as for repotags, the latter being just a mark of origin. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Feb 26 10:09:40 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 26 Feb 2005 11:09:40 +0100 Subject: [Fedora-packaging] Re: Introduction In-Reply-To: <1109016246.10854.91.camel@localhost.localdomain> References: <1109016246.10854.91.camel@localhost.localdomain> Message-ID: <20050226100940.GF22428@neu.nirvana> On Mon, Feb 21, 2005 at 02:04:06PM -0600, Tom 'spot' Callaway wrote: > I'm the sucker who volunteered to head up RPM Standards and > Practices for Fedora Extras. I'd like to make a few things clear, > before we get to the good stuff: > > Check your egos at the door. If all you feel like doing is > posturing, flaming, or mocking, this is NOT the list to do it in (I > hear fedora-list is nice this time of year). If I think you're being > more of a nuisance than an asset, I will warn you, then kick you off > the list if you continue. I hope it doesn't come to that. Is this list really only for Fedora Extras, formerly fedora.us practices? Can't it be extended to a larger universe? This was the main obstruction that created the hasm two years ago between fedora.us and the rest of the world. It would be nice to attack this issue w/o isolating again any parties. What about Fedora Core itself? It doesn't make sense to have Fedora Core and Extras living side by side having different naming/versioning policies. In fact I would go as far as to say that a sane set of packaging practices should not only be applicable to Fedora, but to RHEL as well (whether RHEL adopts it is another topic, but it should not be cut off from the beginning), and - why not - even outside the Red Hat rpm world. A lot of issues discussed here already have good solutions and defacto standards in 3rd party repos for Fedora Core or other distributions. I'd like to finally see a common effort on this and see the unneccessary barriers break to pieces. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Sat Feb 26 15:23:07 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 26 Feb 2005 09:23:07 -0600 Subject: [Fedora-packaging] Re: Introduction In-Reply-To: <20050226100940.GF22428@neu.nirvana> References: <1109016246.10854.91.camel@localhost.localdomain> <20050226100940.GF22428@neu.nirvana> Message-ID: <1109431387.7400.79.camel@localhost.localdomain> On Sat, 2005-02-26 at 11:09 +0100, Axel Thimm wrote: >Is this list really only for Fedora Extras, formerly fedora.us >practices? Can't it be extended to a larger universe? My little piece of the universe is Fedora Extras. That doesn't mean other people can't use these standards for their pieces of the universe. It also doesn't mean that I'm ignoring everything else, feedback is welcome from everyone. >This was the main obstruction that created the hasm two years ago >between fedora.us and the rest of the world. It would be nice to >attack this issue w/o isolating again any parties. My primary goal is to create a set of packaging standards and guidelines that will encourage more people to package for Fedora Extras. Inevitably, I won't be able to make everyone happy, but I am interested in making the majority happy enough to contribute. >What about Fedora Core itself? It doesn't make sense to have Fedora >Core and Extras living side by side having different naming/versioning >policies. You're right. Which is why I'm glad we have some @redhat.com folks who have control over the Fedora Core packaging standards on this list. My hope is that if the Fedora Extras standards are accepted, used, and successful, it will transfer over to Fedora Core. >In fact I would go as far as to say that a sane set of packaging >practices should not only be applicable to Fedora, but to RHEL as well >(whether RHEL adopts it is another topic, but it should not be cut off >from the beginning), and - why not - even outside the Red Hat rpm >world. I don't see any reason why anyone else shouldn't adopt these guidelines for packaging. We're definitely not saying "ONLY FEDORA EXTRAS MAY PACKAGE PACKAGES LIKE THIS". >A lot of issues discussed here already have good solutions and defacto >standards in 3rd party repos for Fedora Core or other distributions. Great! Please help me out, since I don't know of these other solutions and standards, and point me to them when I start reinventing the wheel. >I'd like to finally see a common effort on this and see the >unneccessary barriers break to pieces. :) I agree. Just keep in mind that I'm NOT out to get anyone, and I'm not trying to pee in anyone's swimming pool, I'm just trying to document simple standards that are easy to follow. :) ~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 Sat Feb 26 15:26:34 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 26 Feb 2005 09:26:34 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <1109407422.15854.128.camel@bobcat.mine.nu> References: <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> <20050225221949.GB26828@nostromo.devel.redhat.com> <1109370210.7400.32.camel@localhost.localdomain> <20050225230231.GD26828@nostromo.devel.redhat.com> <1109407422.15854.128.camel@bobcat.mine.nu> Message-ID: <1109431595.7400.84.camel@localhost.localdomain> On Sat, 2005-02-26 at 10:43 +0200, Ville Skytt? wrote: >On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote: >> Tom 'spot' Callaway (tcallawa at redhat.com) said: >> > If our buildroots don't have it, then thats a serious failure (its in >> > System Environment/Base). >> >> Well, you'd still want it to get pulled in via a dep somehow. Right >> now that would be via initscripts, which may or may not be in >> the build dependency chain. > >Where are you planning to put these disttag macros anyway? Just >document them, or include in some package, eg. redhat-rpm-config? Such >a package could carry the necessary dependencies, if any. They probably should go in a package, like redhat-rpm-config. Elliot, that's your package, would you be interested in adding these disttag macros into redhat-rpm-config's macros file for FC4? If so, I'll whip up a patch for you. ~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 Sat Feb 26 16:13:11 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 26 Feb 2005 10:13:11 -0600 Subject: [Fedora-packaging] Re: disttag In-Reply-To: <20050226095317.GE22428@neu.nirvana> References: <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225153148.GD19139@angus.ind.WPI.EDU> <1109354494.13305.270.camel@localhost.localdomain> <1109359606.15854.107.camel@bobcat.mine.nu> <1109368688.7400.14.camel@localhost.localdomain> <20050225221949.GB26828@nostromo.devel.redhat.com> <20050226095317.GE22428@neu.nirvana> Message-ID: <1109434391.7400.131.camel@localhost.localdomain> On Sat, 2005-02-26 at 10:53 +0100, Axel Thimm wrote: >why have the chrooted system do the guesswork, when the information is >there at the rpmbuild level? > >rpmbuild --define 'disttag whatever' ... Because I don't want to overcomplicate the buildsystem, or overuse the disttag. Let me try and clarify my thoughts here. I think the "%{release}" field should be as simple as possible. The original goal of the "%{release}" field was so that you could track the difference between a package built yesterday, and today's new build. I realize there are some cases in which people tried to overload the "%{release} field. These seem to be the three most common: - Dealing with "pre-release" versions of packages, which screw up the proper ordering of packages, making rpm think that "pre-release" packages are infact newer than the final releases. - Dealing with a single spec file that builds for multiple versions of Fedora Core/RHL/RHEL. - Repository tagging a package. Now, I've looked at these three cases, and I've trying to document the PackageNamingGuidelines to deal with the "pre-release" case (and its still not entirely done, I'm going to move the "post-release" cases back to %{version}) The %{disttag} macros are designed to take the conscious thought out of the build process, so that maintainers in the "single spec" case can use %{?disttag:.%{disttag}} in the "Release:" (and check against %{disttag} in conditionals in the spec) and know that it will work. If you have to pass the value at build time, you're opening the door for failure, and for packagers to pollute the %{release} value. I'm trying to avoid packages named like this: logjam-4.4.1-44.0.3.17.FC4_spotwashere_WuTangClan3.i386.rpm This is what I'm hoping for: In the primary case (one spec per distro): logjam-4.4.1-44.i386.rpm In the pre-release case: logjam-4.4.2-0.1.a.i386.rpm In the multiple-distro/single-spec case: logjam-4.4.1-44.2.fc4.i386.rpm In the multiple-distro/single-spec and pre-release case: logjam-4.4.2-0.1.a.2.fc4.i386.rpm ^^^ That's still ugly, but its the worst possible corner case. The third reason to overload the %{release} field, repository tagging? I don't see the point of doing it. Fedora Extras certainly doesn't need to do it. It makes the package unnecessarily long and ugly, and it confuses the upgrade progress. Is a package with a repotag of "Aargh" newer than a repotag of "BoOoOo". 99% of users don't care at all where their package comes from, as long as it works. This is another reason I want %{disttag} to be defined automatically, without anyone trying to --with a different value in there and cluttering up the release field with noise. >And if you can convince Jeff to patch up an automated suffix to the >rpm tag you could keep the specfile totally clean from disttags, >e.g. like they look like today. This is a noble long term goal, but I'm trying to avoid patching rpm unless absolutely necessary. The %{disttag} macros are backwards compatible to at least Red Hat Linux 7.3 (is anyone really building for older builds?). Ideally, it would be a releasesuffix, very much like arch is today. RPM would know about the proper ordering of distributions for upgrades, be able to detect it from the system automatically, and users could enable/disable the use of the releasesuffix disttag from their own ~/.rpmmacros. But that's an extremely non-trivial process, and I'm not going to dump it on Jeff. >produces foo-1.2.3-4.rhel4.at.i386.rpm Just to reiterate, I don't think the disttag should be used for repo tagging. I consider the "mark of origin" unnecessary clutter. In no way am I trying to belittle anyone who has created a repo, they should be proud of their packages, but they shouldn't have to label them like 0-day warez. If a user has edited their yum or apt config to include it, then let that tool identify the origin of the package at install time. I know for a fact that yum does this. So, let me tell you my selfish utopian goal: I want everyone packaging their open-source code in Fedora Extras. If everyone with an open-source, US-friendly package was storing them in Fedora Extras, we wouldn't even need repository tagging. It would eliminate a LOT of repository mixing pain. Maintainers would still have control over their package, within reasonable standards and practices. Fedora Extras would become a one-stop shop for getting packages that are not in Fedora Core. And I for one, would love to see us have RHEL branches in Extras, but in the short-term, I want it to be easy for someone to maintain their spec file and sources in Fedora Extras, and build their RHEL packages from that for their own RHEL repository. And I'm the unlucky guy who gets to try and make this happen. Doesn't my utopia sound nice? The best part: We can do it. I'm not so dumb to believe that there will never be other repositories besides Fedora Extras, but the more we can centralize, the less duplication of effort occurs. The more we centralize, the less confusing it is to the Fedora end-user. The third party RPM repositories are doing good work, I just want you to do it in Fedora Extras. The first step to this is sane (and simple) standards and practices for packaging. Or put it this way: Tell me why you're not packaging in Fedora Extras today. If its sponsorship concerns, I'll sponsor any 3rd party repository maintainer right now. Just ask me. If its packaging standards and guidelines, tell me where you're unhappy. If its personal issues, lingering burn marks from flame wars in the past, try to get over them. We're all doing this for the same reason: to provide good quality addon packages for Fedora. I didn't really mean to give a sermon like that, but it feels better to have it out. :) ~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 Sat Feb 26 16:24:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 26 Feb 2005 11:24:49 -0500 Subject: [Fedora-packaging] Re: Epoch policy In-Reply-To: References: Message-ID: <1109435089.27384.73.camel@cutter> On Sat, 2005-02-26 at 16:53 +0100, Aurelien Bompard wrote: >Hi all > >In the new PackageNamingGuidelines, there is nothing about epochs. What is >the new Extras policy regarding Epochs ? New packages should be created >without Epochs, but what about Fedora.us imported packages ? Should I drop >Epoch in the next releases ? Should I do it only for the devel branch ? 1. Look on the fedora-packaging list for the discussion 2. my guess is: a. if the fedora.us package had a non-zero epoch it needs to be maintained - just so users have an upgrade path b. if the fedora.us package had an Epoch: 0 drop it and remove %{epoch} from anyplace you have it in ver strings. I'm cc'ing the packaging list to see if that seems right to them. -sv From tcallawa at redhat.com Sat Feb 26 16:19:15 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 26 Feb 2005 10:19:15 -0600 Subject: [Fedora-packaging] Re: Epoch policy In-Reply-To: <1109435089.27384.73.camel@cutter> References: <1109435089.27384.73.camel@cutter> Message-ID: <1109434755.7400.133.camel@localhost.localdomain> On Sat, 2005-02-26 at 11:24 -0500, seth vidal wrote: >1. Look on the fedora-packaging list for the discussion >2. my guess is: > a. if the fedora.us package had a non-zero epoch it needs to be >maintained - just so users have an upgrade path > b. if the fedora.us package had an Epoch: 0 drop it and remove >%{epoch} from anyplace you have it in ver strings. I agree with this. Anyone else have thoughts? ~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 pmatilai at welho.com Sat Feb 26 17:10:55 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Sat, 26 Feb 2005 19:10:55 +0200 (EET) Subject: [Fedora-packaging] Re: Epoch policy In-Reply-To: <1109434755.7400.133.camel@localhost.localdomain> References: <1109435089.27384.73.camel@cutter> <1109434755.7400.133.camel@localhost.localdomain> Message-ID: On Sat, 26 Feb 2005, Tom 'spot' Callaway wrote: > On Sat, 2005-02-26 at 11:24 -0500, seth vidal wrote: > >> 1. Look on the fedora-packaging list for the discussion >> 2. my guess is: >> a. if the fedora.us package had a non-zero epoch it needs to be >> maintained - just so users have an upgrade path >> b. if the fedora.us package had an Epoch: 0 drop it and remove >> %{epoch} from anyplace you have it in ver strings. > > I agree with this. Anyone else have thoughts? Fully agree, kill the stupid zero epochs. I think that's been happening already in extras to some extent but lots of them still exist. - Panu - From bugs.michael at gmx.net Sat Feb 26 17:24:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 18:24:55 +0100 Subject: [Fedora-packaging] Epoch policy In-Reply-To: <1109434755.7400.133.camel@localhost.localdomain> References: <1109435089.27384.73.camel@cutter> <1109434755.7400.133.camel@localhost.localdomain> Message-ID: <20050226182455.52b608e0.bugs.michael@gmx.net> On Sat, 26 Feb 2005 10:19:15 -0600, Tom 'spot' Callaway wrote: > On Sat, 2005-02-26 at 11:24 -0500, seth vidal wrote: > > >1. Look on the fedora-packaging list for the discussion > >2. my guess is: > > a. if the fedora.us package had a non-zero epoch it needs to be > >maintained - just so users have an upgrade path > > b. if the fedora.us package had an Epoch: 0 drop it and remove > >%{epoch} from anyplace you have it in ver strings. > > I agree with this. Anyone else have thoughts? Dropping "Epoch: 0" breaks rpm -F updates. This is in bugzilla somewhere. From bugs.michael at gmx.net Sat Feb 26 17:29:56 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 18:29:56 +0100 Subject: [Fedora-packaging] disttag In-Reply-To: <1109287718.13305.238.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> Message-ID: <20050226182956.400b6878.bugs.michael@gmx.net> On Thu, 24 Feb 2005 17:28:38 -0600, Tom 'spot' Callaway wrote: > Maintainers would not be required to use %{disttag}. However, should > they choose to do so, it should be placed at the end of the release > field, preceeded by a period, e.g. Release: 1.%{disttag}. Not with a period, of course, because if undefined, the release would included the period and become "1." instead of "1". From bugs.michael at gmx.net Sat Feb 26 17:33:09 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 26 Feb 2005 18:33:09 +0100 Subject: [Fedora-packaging] disttag In-Reply-To: <1109340323.13305.268.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> <1109292492.13305.254.camel@localhost.localdomain> <20050225114227.0d55c226@python2> <1109340323.13305.268.camel@localhost.localdomain> Message-ID: <20050226183309.69003522.bugs.michael@gmx.net> On Fri, 25 Feb 2005 08:05:23 -0600, Tom 'spot' Callaway wrote: > On Fri, 2005-02-25 at 11:42 +0100, Matthias Saou wrote: > >Tom 'spot' Callaway wrote : > > > >> %disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep > >> Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')} > > > >Hmm, haven't had enough coffee yet, but is the above just to get the > >version of the package that contains the redhat-release file!? If so, what > >about this instead : > > > >%(rpm -qf --qf '%{version}' /etc/redhat-release) > > > >I _must_ be missing something... > > You are. We can't use %{version} in the macro, because when its parsed > at buildtime, it grabs the %{version} for the package being built, and > replaces it before running the command. Hence the ickiness. %(rpm -qf --qf '%%{version}' /etc/redhat-release) was used successfully before, e.g. in the fedora.us k3b package (see e.g. Fedora Extras CVS FC-1 branch). From tcallawa at redhat.com Sat Feb 26 17:30:47 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 26 Feb 2005 11:30:47 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050226182956.400b6878.bugs.michael@gmx.net> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050226182956.400b6878.bugs.michael@gmx.net> Message-ID: <1109439047.7400.136.camel@localhost.localdomain> On Sat, 2005-02-26 at 18:29 +0100, Michael Schwendt wrote: >On Thu, 24 Feb 2005 17:28:38 -0600, Tom 'spot' Callaway wrote: > >> Maintainers would not be required to use %{disttag}. However, should >> they choose to do so, it should be placed at the end of the release >> field, preceeded by a period, e.g. Release: 1.%{disttag}. > >Not with a period, of course, because if undefined, the release >would included the period and become "1." instead of "1". Yes, that mistake has been caught. The syntax would be: Release: 1%{?disttag:.%{disttag}} ~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 Sat Feb 26 17:32:06 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 26 Feb 2005 11:32:06 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050226183309.69003522.bugs.michael@gmx.net> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <1109287931.13305.241.camel@localhost.localdomain> <1109290572.13305.249.camel@localhost.localdomain> <1109292492.13305.254.camel@localhost.localdomain> <20050225114227.0d55c226@python2> <1109340323.13305.268.camel@localhost.localdomain> <20050226183309.69003522.bugs.michael@gmx.net> Message-ID: <1109439127.7400.138.camel@localhost.localdomain> On Sat, 2005-02-26 at 18:33 +0100, Michael Schwendt wrote: >%(rpm -qf --qf '%%{version}' /etc/redhat-release) Yep. %{VERSION} and %{RPMTAG_VERSION} all work. :) ~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 Sat Feb 26 17:38:10 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 26 Feb 2005 19:38:10 +0200 Subject: [Fedora-packaging] Epoch policy In-Reply-To: <20050226182455.52b608e0.bugs.michael@gmx.net> References: <1109435089.27384.73.camel@cutter> <1109434755.7400.133.camel@localhost.localdomain> <20050226182455.52b608e0.bugs.michael@gmx.net> Message-ID: <1109439490.15854.151.camel@bobcat.mine.nu> On Sat, 2005-02-26 at 18:24 +0100, Michael Schwendt wrote: > On Sat, 26 Feb 2005 10:19:15 -0600, Tom 'spot' Callaway wrote: > > > On Sat, 2005-02-26 at 11:24 -0500, seth vidal wrote: > > > > >1. Look on the fedora-packaging list for the discussion > > >2. my guess is: > > > a. if the fedora.us package had a non-zero epoch it needs to be > > >maintained - just so users have an upgrade path > > > b. if the fedora.us package had an Epoch: 0 drop it and remove > > >%{epoch} from anyplace you have it in ver strings. > > > > I agree with this. Anyone else have thoughts? > > Dropping "Epoch: 0" breaks rpm -F updates. This is in bugzilla > somewhere. https://bugzilla.redhat.com/beta/show_bug.cgi?id=143301 Because of the above, removing "Epoch: 0"'s now is a bad idea. No objections here _after_ the above has been fixed in rpm and the fix shipped in a released distro version. OTOH there are no real world reasons that would require doing it even then. From jpo at di.uminho.pt Sat Feb 26 19:50:07 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 26 Feb 2005 19:50:07 +0000 Subject: [Fedora-packaging] RFC: howto to package LaTeX classes Message-ID: <4220D2EF.4060009@di.uminho.pt> Hi, Are there any recommendations regarding TeTeX packages? In particular I have a few doubts/questions regarding: * license Question: Is the "LaTeX Project Public License" an approved license? Note: The rpmlint emits the following warning regarding the license ... W: tetex-xcolor invalid-license LaTeX Project Public License * name conventions for tetex related macros - texmf base directory - package base directory - package documentation base directory (texdoc related) - texhash program (or mktexlsr) Example: %define _texmf %{_datadir}/texmf %define __texhash %{_bindir}/texhash %define texpkg xcolor %define texpkgdir %{_texmf}/tex/latex/%{texpkg} %define texpkgdoc %{_texmf}/doc/latex/%{texpkg} * installation scripts (texhash vs mktexlsr) Problem: the texhash file is owned by different packages $ rpm -qf /usr/bin/texhash FC1: tetex-2.0.2-8 FC3: tetex-fonts-2.0.2-21.3 Solution: Use the file as a requirement ---------- ... Requires(post): %{__texhash} Requires(postun): %{__texhash} ... %post %{__texhash} %{_texmf} >/dev/null 2>&1 || : %postun %{__texhash} %{_texmf} >/dev/null 2>&1 || : ... ---------- * installation of package documentation in order for it to be found by the texdoc program Problem: - the texdoc program only searches for documentation files under the directory /usr/share/texmf/doc/ - I believe the tetex package documentation should be installed in directories like /usr/share/texmf/doc/latex/"package_name" but /usr/share/texmf/doc is owned by tetex-doc which is a rather big package (50MB+) to be a requirement. Is it ok for tetex-* packages owning this directory? I am packaging the latex Beamer presentation class and its two dependencies (xcolor and pgf). I have looked at several tetex-* packages (fedora us/extras) and almost everyone of them seems to be doing different thing. It would be nice to have a specfile template. Comments/suggestions are welcome, jpo References: * The Beamer presentation class http://latex-beamer.sourceforge.net/ * The Xcolor dependency http://www.ukern.de/tex/xcolor.html * Two of my tetex specfiles http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-xcolor.spec http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-xcolor-2.00-1.src.rpm http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-pgf.spec http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-pgf-0.65-1.src.rpm PS - I forgot to mention that I am not a TeX/LaTeX expert. -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Sat Feb 26 20:07:33 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 26 Feb 2005 22:07:33 +0200 Subject: [Fedora-packaging] RFC: howto to package LaTeX classes In-Reply-To: <4220D2EF.4060009@di.uminho.pt> References: <4220D2EF.4060009@di.uminho.pt> Message-ID: <1109448453.15854.163.camel@bobcat.mine.nu> On Sat, 2005-02-26 at 19:50 +0000, Jos? Pedro Oliveira wrote: > Question: > Is the "LaTeX Project Public License" an approved license? > > Note: > The rpmlint emits the following warning regarding the license > ... > W: tetex-xcolor invalid-license LaTeX Project Public License Feel free to send/bugzilla patches/improvement ideas for the rpmlint config. (No, I don't know a thing about *TeX, nor the license, sorry.) From tcallawa at redhat.com Sat Feb 26 23:58:20 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 26 Feb 2005 17:58:20 -0600 Subject: [Fedora-packaging] RFC: howto to package LaTeX classes In-Reply-To: <4220D2EF.4060009@di.uminho.pt> References: <4220D2EF.4060009@di.uminho.pt> Message-ID: <1109462300.7400.148.camel@localhost.localdomain> On Sat, 2005-02-26 at 19:50 +0000, Jos? Pedro Oliveira wrote: >Hi, > >Are there any recommendations regarding TeTeX packages? > >In particular I have a few doubts/questions regarding: > > * license > > Question: > Is the "LaTeX Project Public License" an approved license? It's not an OSI approved license, but it is listed as a "GPL-Incompatible, Free Software License". I've updated the PackagingGuidelines with regards to licensing. Basically, if its a OSI-approved license, "GPL-Compatible, Free Software License", or "GPL-Incompatible, Free Software License", its ok for Fedora Extras. Thus, the LPPL is ok. ~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 jpo at di.uminho.pt Sun Feb 27 00:29:07 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Sun, 27 Feb 2005 00:29:07 +0000 Subject: [Fedora-packaging] RFC: howto to package LaTeX classes In-Reply-To: <1109462300.7400.148.camel@localhost.localdomain> References: <4220D2EF.4060009@di.uminho.pt> <1109462300.7400.148.camel@localhost.localdomain> Message-ID: <42211453.5060900@di.uminho.pt> Tom 'spot' Callaway wrote: > On Sat, 2005-02-26 at 19:50 +0000, Jos? Pedro Oliveira wrote: > >>Hi, >> >>Are there any recommendations regarding TeTeX packages? >> >>In particular I have a few doubts/questions regarding: >> >> * license >> >> Question: >> Is the "LaTeX Project Public License" an approved license? > > > It's not an OSI approved license, but it is listed as a > "GPL-Incompatible, Free Software License". > > I've updated the PackagingGuidelines with regards to licensing. > Basically, if its a OSI-approved license, "GPL-Compatible, Free Software > License", or "GPL-Incompatible, Free Software License", its ok for > Fedora Extras. > > Thus, the LPPL is ok. > Thanks for the information. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Sun Feb 27 01:29:02 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 26 Feb 2005 19:29:02 -0600 Subject: [Fedora-packaging] Epoch policy In-Reply-To: <20050226182455.52b608e0.bugs.michael@gmx.net> References: <1109435089.27384.73.camel@cutter> <1109434755.7400.133.camel@localhost.localdomain> <20050226182455.52b608e0.bugs.michael@gmx.net> Message-ID: <1109467742.7400.163.camel@localhost.localdomain> On Sat, 2005-02-26 at 18:24 +0100, Michael Schwendt wrote: >On Sat, 26 Feb 2005 10:19:15 -0600, Tom 'spot' Callaway wrote: > >> On Sat, 2005-02-26 at 11:24 -0500, seth vidal wrote: >> >> >1. Look on the fedora-packaging list for the discussion >> >2. my guess is: >> > a. if the fedora.us package had a non-zero epoch it needs to be >> >maintained - just so users have an upgrade path >> > b. if the fedora.us package had an Epoch: 0 drop it and remove >> >%{epoch} from anyplace you have it in ver strings. >> >> I agree with this. Anyone else have thoughts? > >Dropping "Epoch: 0" breaks rpm -F updates. This is in bugzilla >somewhere. Fixed it. Hopefully, this will make it into FC4. For FC3 and earlier, we'll have to document it like this: In Fedora Core 3 and earlier, there was a bug in rpm that caused the "-F" or "freshen" case to fail if you attempted to upgrade from a package that had "Epoch: 0" to a package that had no Epoch: value. Thus, for Extras packages in the Fedora Core 3 branch (or earlier), if the package has any Epoch: value defined (even 0), then all updates in that branch must also have an Epoch: value defined. In the Extras Fedora Core 4 branch, you should not define Epoch: 0, even if earlier revisions of the package did. If earlier revisions of the package had a non-zero Epoch, you should keep Epoch, so that users have an upgrade path. New packages (packages where there is no previous package to upgrade from) should not use Epoch. Does that seem reasonable (pending the fix being included in FC4's 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 gdk at redhat.com Mon Feb 28 14:36:37 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 28 Feb 2005 09:36:37 -0500 (EST) Subject: [Fedora-packaging] Re: Introduction In-Reply-To: <1109431387.7400.79.camel@localhost.localdomain> References: <1109016246.10854.91.camel@localhost.localdomain> <20050226100940.GF22428@neu.nirvana> <1109431387.7400.79.camel@localhost.localdomain> Message-ID: This group is the ideal group to find the *right* solution, and to implement that solution in their domains. Coming up with a successful standard that is used by Fedora Extras, RPMForge, and every other major RPM repository in the world will apply pressure to Fedora Core and RHEL to follow suit. _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Sat, 26 Feb 2005, Tom 'spot' Callaway wrote: > On Sat, 2005-02-26 at 11:09 +0100, Axel Thimm wrote: > > >Is this list really only for Fedora Extras, formerly fedora.us > >practices? Can't it be extended to a larger universe? > > My little piece of the universe is Fedora Extras. That doesn't mean > other people can't use these standards for their pieces of the universe. > It also doesn't mean that I'm ignoring everything else, feedback is > welcome from everyone. > > >This was the main obstruction that created the hasm two years ago > >between fedora.us and the rest of the world. It would be nice to > >attack this issue w/o isolating again any parties. > > My primary goal is to create a set of packaging standards and guidelines > that will encourage more people to package for Fedora Extras. > Inevitably, I won't be able to make everyone happy, but I am interested > in making the majority happy enough to contribute. > > >What about Fedora Core itself? It doesn't make sense to have Fedora > >Core and Extras living side by side having different naming/versioning > >policies. > > You're right. Which is why I'm glad we have some @redhat.com folks who > have control over the Fedora Core packaging standards on this list. My > hope is that if the Fedora Extras standards are accepted, used, and > successful, it will transfer over to Fedora Core. > > >In fact I would go as far as to say that a sane set of packaging > >practices should not only be applicable to Fedora, but to RHEL as well > >(whether RHEL adopts it is another topic, but it should not be cut off > >from the beginning), and - why not - even outside the Red Hat rpm > >world. > > I don't see any reason why anyone else shouldn't adopt these guidelines > for packaging. We're definitely not saying "ONLY FEDORA EXTRAS MAY > PACKAGE PACKAGES LIKE THIS". > > >A lot of issues discussed here already have good solutions and defacto > >standards in 3rd party repos for Fedora Core or other distributions. > > Great! Please help me out, since I don't know of these other solutions > and standards, and point me to them when I start reinventing the wheel. > > >I'd like to finally see a common effort on this and see the > >unneccessary barriers break to pieces. :) > > I agree. Just keep in mind that I'm NOT out to get anyone, and I'm not > trying to pee in anyone's swimming pool, I'm just trying to document > simple standards that are easy to follow. :) > > ~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 > From slawrence at pingtel.com Mon Feb 28 21:51:18 2005 From: slawrence at pingtel.com (Scott Lawrence) Date: Mon, 28 Feb 2005 16:51:18 -0500 Subject: [Fedora-packaging] Template .spec file for conventions? Message-ID: <1109627478.5520.139.camel@sukothai.pingtel.com> It looks as though there's a consensus developed around how packages should be named. Being fairly new to rpm building, I have not understood all the details of the discussions around how best to implement those conventions. Might it be possible for one of you who does understand it to supplement the naming guidelines with a skeleton .spec file that illustrates how to do it, along with whatever is required of the surrounding build system? -- Scott Lawrence Consulting Engineer Pingtel Corp. http://www.pingtel.com/ +1.781.938.5306 x162 From ghenry at suretecsystems.com Mon Feb 28 22:27:47 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Mon, 28 Feb 2005 22:27:47 +0000 Subject: [Fedora-packaging] Template .spec file for conventions? In-Reply-To: <1109627478.5520.139.camel@sukothai.pingtel.com> References: <1109627478.5520.139.camel@sukothai.pingtel.com> Message-ID: <200502282227.52115.ghenry@suretecsystems.com> On Monday 28 Feb 2005 21:51, Scott Lawrence wrote: > It looks as though there's a consensus developed around how packages > should be named. Being fairly new to rpm building, I have not > understood all the details of the discussions around how best to > implement those conventions. Might it be possible for one of you who > does understand it to supplement the naming guidelines with a > skeleton .spec file that illustrates how to do it, along with whatever > is required of the surrounding build system? You need to install fedora-rpmdevtools for the rpmbuild directory see: http://fedoranews.org/tchung/rpmbuild/ And for specfiles: http://www.fedora.us/tempspecs/stable/ General ideas see: http://fedoraproject.org/wiki/PackagingGuidelines And: http://fedoraproject.org/wiki/PackageNamingGuidelines Thanks, G. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: