From chris.stone at gmail.com Sat Jul 1 03:11:31 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 30 Jun 2006 20:11:31 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1151674644.7108.15.camel@localhost.localdomain> <44A52CF4.9000002@city-fan.org> <1151677289.7108.18.camel@localhost.localdomain> <44A535E8.1080608@city-fan.org> Message-ID: On 6/30/06, Christopher Stone wrote: > As it is now, the php-pecl spec files have a group of > Development/Language and the php-pear spec file use a group of > Development/Libraries > > Shouldn't this be reversed? Afterall, the pecl packages are packaged > with a .so file and the pear packages are all .php files. So I am a > little confused on what the groups should be. Okay well I've given this some thought and I think both pecl and pear packages should be grouped under Development/Libraries. pecl packages provide extensions to the languge just like pear packages do, only they are written in C. It might just be a matter of semantics and someone with a better understanding of the Group tag definitions knows better. From rc040203 at freenet.de Sat Jul 1 03:33:28 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 01 Jul 2006 05:33:28 +0200 Subject: [Fedora-packaging] Re: rpms/haddock/devel haddock.spec,1.2,1.3 In-Reply-To: <1151685070.2718.13.camel@localhost> References: <200606300311.k5U3BTYw016261@cvs-int.fedora.redhat.com> <1151670690.15566.76.camel@mccallum.corsepiu.local> <1151672299.6570.291.camel@localhost.localdomain> <1151685070.2718.13.camel@localhost> Message-ID: <1151724808.22230.36.camel@mccallum.corsepiu.local> On Fri, 2006-06-30 at 09:31 -0700, Toshio Kuratomi wrote: > On Fri, 2006-06-30 at 15:58 +0300, Ville Skytt? wrote: > > On Fri, 2006-06-30 at 14:31 +0200, Ralf Corsepius wrote: > > > * To make file deps on tools being used in %pre|post scripts mandatory. > > > > +1 when the tools are really required. An example when they are not is > > eg. the GTK+ icon cache entry at > > http://fedoraproject.org/wiki/ScriptletSnippets > > > What is the reason to use file dependencies? Clarity when comparing > Requires to scriptlets? To protect against programs moving to a > different package? My motivation is to protect package maintainers and installers against * tools moving to different packages. * tools moving to different places. Actually, I would like to see a policy of this kind implemented: * All tools being used in rpm-scriptlets must be using an absolute path. * Each tool being used in rpm-scriptlets must be accompanied by a corresponding Requires(post|pre|preun|postun|..). IMO, this would help avoiding such changes breaking upgrade/update paths and would help avoid users to break their systems. Ralf From paul at city-fan.org Sat Jul 1 08:46:14 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 01 Jul 2006 09:46:14 +0100 Subject: [Fedora-packaging] New Mono Page for new guidelines In-Reply-To: <1151699310.2718.53.camel@localhost> References: <1151699310.2718.53.camel@localhost> Message-ID: <1151743574.20182.37.camel@laurel.intra.city-fan.org> On Fri, 2006-06-30 at 13:28 -0700, Toshio Kuratomi wrote: > I've reworked the Mono page to reflect the new Guidelines we confirmed > yesterday. If people want to take a look, it's here: > http://fedoraproject.org/wiki/PackagingDrafts/Mono > > Changes are color coded: Red removes, green adds, blue is a > justification for people who didn't attend the meeting and will be > removed from the final copy. (I probably should have done this before > the meeting rather than after, sorry.) > > If no one objects, I'll replace the current Packaging/Mono page this > weekend. The guidelines now say "no noarch packages". What about packages such as lat, that are already in Extras as noarch and don't contain any arch-specific AOTs? It does, however, install an mcs-built .dll and .exe in %{_prefix}/lib. Is there anything technically wrong with this other than not lining up with the guidelines? Paul. From panemade at gmail.com Sat Jul 1 08:50:35 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Sat, 1 Jul 2006 14:20:35 +0530 Subject: [Fedora-packaging] how to get direct link of some parts on packaging guidelines wiki page Message-ID: Hi, I have written my own Packaging Notes Guidelines on http://fedoraproject.org/wiki/ParagNemade/PackagingNotes. There i have written some direct links to obtain help on writing specific tags in SPEC file. I want direct link for License section on http://fedoraproject.org/wiki/Packaging/Guidelines. Can i get anchors on that page so that instead of giving this dynamic address of http://fedoraproject.org/wiki/Packaging/Guidelines#head-76294f12c6b481792eb001ba9763d95e2792e825 i can give static address that will remain same after any one edits that page. Thanks & Regards, Parag. From Axel.Thimm at ATrpms.net Sat Jul 1 09:17:21 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 1 Jul 2006 11:17:21 +0200 Subject: [Fedora-packaging] Disttags for FL (was: Upgrade path consistency among all Fedora Projects) In-Reply-To: <44A62B12.2040801@gtw.net> References: <44A62B12.2040801@gtw.net> Message-ID: <20060701091721.GB15707@neu.nirvana> On Sat, Jul 01, 2006 at 02:58:10AM -0500, David D. Eisenstein wrote: > Have a quick question for you, Tom. Is there a methodolgy in place > already for how Core and/or Extras packages are to be versioned in the > "Release:" part of the packages' .spec files? I am thinking that if > there is such, then we in Legacy will need to follow that and revise our > package numbering guidelines > (current: ) > to follow it from now on. If no such methodology is used or mandated, > then does numbering of the "Release:" tag needs to be codified among all > Fedora projects? > > I look forward to your answer, Tom. Thanks! -David > > ps: How may I participate in the Packaging group? > I'll try to answer on the questions raised to Tom: The (now common to both core and extras) Fedora Packaging Guidelines http://www.fedoraproject.org/wiki/Packaging/Guidelines don't yet explicitely mention the usage of (the optional) disttags http://www.fedoraproject.org/wiki/DistTag but they are in common use throughout extras and will hopefully make their way to core soon. But note that the disttags used here for rhlX would generate broken upgrade paths ("rhl" > "fc"). These are very early suggestions and since extras started with FC3 it never became an actual issue, but if FL is seeking for following the packaging guidelines including disttags taking this implementation would be wrong. If there is interest in FL to introduce and use disttags before RH7.,3 and RH9 are EOL'd, RHL7.3 and RH9 would need to get disttags < fcX. Examples stated in the past were "RHL7.3" or "fc0.7.3" (upper case is less than lower case and RHL would be considered like subversions of FC0). I would vote for the first version (even though it looks like fortran/shouting) as fc0.7.3 will probably confuse end users. You can get involved with the packaging group (if you mean the newly created packaging committee) by subscribing to fedora-packaging and visiting the IRC meetings on Thursdays 16:00 UTC. Jesse Keating is also on board so there. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Jul 1 11:34:29 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 1 Jul 2006 13:34:29 +0200 Subject: [Fedora-packaging] fc5.90/fc5.91/... disttags and automated rebuilds (was: Mass rebuild of Extras packages for FC6?) In-Reply-To: <44A64DB2.2080505@leemhuis.info> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> <44A64DB2.2080505@leemhuis.info> Message-ID: <20060701113429.GA20490@neu.nirvana> On Sat, Jul 01, 2006 at 12:25:54PM +0200, Thorsten Leemhuis wrote: > I suppose a lot of people won't like the topic I'll bring up with this > mail but we IMHO should discuss this nevertheless. > > Jesse Keating schrieb: > > I've been requested to rebuild every Core package for a few reasons. > > > > 1) rpm signing w/ sha256sum > > 2) New toolset feature to speed up dynamic lib linking by 50%~ > > 3) get all packages built through new build system (brew) > > Change the last point to > > 3) get all packages build with the new and reduced set of packages > installed in the default mock buildroot All the above three could be automated for packages using %{?dist}, if the disttag would propagate in fedora time as well. E.g. the internal release version of FC6test1 is 5.90, if the disttag was matched to this, we would have automated rebuilds for each test release and for the final release as well w/o anyone having to do anything about it (sparing bugs of course). If rebuilds are needed more often (because gcc was upgraded in between) then disttags could look like 5.90.1 to indicate a rebuild between test1 and test2. Before test1 rawhide had the version 5.89, so we're covered in that area, too. If we're going to mass-rebuilt (and therefore touch each specfile), could we consider using such disttags for rawhide/test releases from now on? E.g. make %{?dist} become 5.90.1 is the mass rebuild is before test2, or if the mass rebuild coincides with test2 go 5.91. It doesn't cover packages not using disttags (so it's perhaps another incentive for these packagers to use them) and due to everything being automated doesn't serve as a way to ping absent packagers. But that was only a side effect of the humanly powered mass-rebuilds, which will be managed differently anyway in the future. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Sat Jul 1 12:44:23 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 1 Jul 2006 08:44:23 -0400 Subject: [Fedora-packaging] Re: Disttags for FL (was: Upgrade path consistency among all Fedora Projects) In-Reply-To: <20060701091721.GB15707@neu.nirvana> References: <44A62B12.2040801@gtw.net> <20060701091721.GB15707@neu.nirvana> Message-ID: <200607010844.27291.jkeating@j2solutions.net> On Saturday 01 July 2006 05:17, Axel Thimm wrote: > If there is interest in FL to introduce and use disttags before RH7.,3 > and RH9 are EOL'd, RHL7.3 and RH9 would need to get disttags < fcX. > Examples stated in the past were "RHL7.3" or "fc0.7.3" (upper case is > less than lower case and RHL would be considered like subversions of > FC0). I would vote for the first version (even though it looks like > fortran/shouting) as fc0.7.3 will probably confuse end users. At this time Fedora Legacy doesn't have an interest in introducing the %{?dist} tag to packages that didn't already have it. This means no RHL packages. In fact, RHL is hopefully going to be phased out of Legacy support in about 6 months. Our current build system does not support dist tags, however when we move to the Fedora infrastructure instead of our own we will gain that ability, and we will use the same dist tag that was appropriate for said releases during the time they were active. FC3 .fc3, FC4 .fc4, etc... -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 Jul 1 15:18:53 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 01 Jul 2006 10:18:53 -0500 Subject: [Fedora-packaging] how to get direct link of some parts on packaging guidelines wiki page In-Reply-To: References: Message-ID: <1151767133.18367.10.camel@localhost.localdomain> On Sat, 2006-07-01 at 14:20 +0530, Parag N(????) wrote: > Hi, > I have written my own Packaging Notes Guidelines on > http://fedoraproject.org/wiki/ParagNemade/PackagingNotes. There i have > written some direct links to obtain help on writing specific tags in > SPEC file. I want direct link for License section on > http://fedoraproject.org/wiki/Packaging/Guidelines. > Can i get anchors on that page so that instead of giving this > dynamic address of > http://fedoraproject.org/wiki/Packaging/Guidelines#head-76294f12c6b481792eb001ba9763d95e2792e825 > i can give static address that will remain same after any one edits that page. There are already anchors for each section on that page. For example: http://fedoraproject.org/wiki/Packaging/Guidelines#LegalLicensing ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From chris.stone at gmail.com Sun Jul 2 06:24:18 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 1 Jul 2006 23:24:18 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1151674644.7108.15.camel@localhost.localdomain> <44A52CF4.9000002@city-fan.org> <1151677289.7108.18.camel@localhost.localdomain> <44A535E8.1080608@city-fan.org> Message-ID: I have simplified my pear spec file slightly: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec I think we should have an almost identical spec file for pecl packages, except we replace pear with pecl. I tried converting Remi's php-pecl-zip spec file in this manner but it does not build properly, there may be some bugs we need to work out first. However I think if the command `pecl install zip-alpha` registers the zip component so it shows up on a `pecl list` command, then the php-pecl-zip rpm should also register this component in the same way. Thoughts/Comments? From chris.stone at gmail.com Sun Jul 2 22:32:32 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 2 Jul 2006 15:32:32 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <20060630095230.GA19767@redhat.com> References: <20060630095230.GA19767@redhat.com> Message-ID: On 6/30/06, Joe Orton wrote: > I don't see why it's necessary for a PEAR package to require > php-pear(PEAR); that is somewhat equivalent to an RPM having "Requires: > rpm"; it should be sufficient and correct for PEAR packages to simply > "Requires: php-pear" AFAICS. I think the php-pear(PEAR) should remain. It refers the the class, and therefore uses the class name, so something like php-pear-Foo-Bar would have a provides php-pear(Foo_Bar) which is the actual name of the class rather than some Fedora package naming standard. See my package: http://tkmame.retrogames.com/fedora-extras/php-pear-Payment-Process.spec Where I have many such pear class requirements. These are listed on the pear download pages, for example: http://pear.php.net/package/Payment_Process/download The whole php-pear(Foo) thing is done to provide a reference to the true class name and to provide better cross compatibility between distributions. > > Why should a PEAR package for foo provide php-foo? Not sure that's a > good idea. I'm not sure this is a good idea either, and I'm not sure of why it's part of the PHP packaging guidelines. > > On "Other Packages": an application written in PHP or such like should > not have a php- prefix at all. A Smarty package should be called > "smarty" (following the "upper-case is evil" rule of packaging). I would agree except that Smarty is not an application, it is a library meant to be used by applications. I think the php-Smarty as a name is fine. From chris.stone at gmail.com Sun Jul 2 23:20:05 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 2 Jul 2006 16:20:05 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> Message-ID: On 7/2/06, Christopher Stone wrote: > On 6/30/06, Joe Orton wrote: > > Why should a PEAR package for foo provide php-foo? Not sure that's a > > good idea. > > I'm not sure this is a good idea either, and I'm not sure of why it's > part of the PHP packaging guidelines. > Okay, I found out why: [17:31] but where there is no name conflict [17:31] each package should Provide: php-FOO = %{version}-%{release} [17:31] this way, we should catch the yum install php-FOO case So this is okay, except that it needs to be added to the wiki page (except where there is no name conflict) for example: php-xmlrpc and php-pear-xmlrpc -- I'm *still* confused on these two ;-) From chris.stone at gmail.com Sun Jul 2 23:23:01 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 2 Jul 2006 16:23:01 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> Message-ID: On 7/2/06, Christopher Stone wrote: > php-xmlrpc and php-pear-xmlrpc -- I'm *still* confused on these two ;-) Actually, I guess the pear version would be php-pear-XML-RPC and Provide php-XML-RPC, so I guess even in this case we are okay. From panemade at gmail.com Mon Jul 3 03:24:59 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Mon, 3 Jul 2006 08:54:59 +0530 Subject: [Fedora-packaging] how to get direct link of some parts on packaging guidelines wiki page In-Reply-To: <1151767133.18367.10.camel@localhost.localdomain> References: <1151767133.18367.10.camel@localhost.localdomain> Message-ID: Hi Tom, On 7/1/06, Tom 'spot' Callaway wrote: > On Sat, 2006-07-01 at 14:20 +0530, Parag N(????) wrote: > > Hi, > > I have written my own Packaging Notes Guidelines on > > http://fedoraproject.org/wiki/ParagNemade/PackagingNotes. There i have > > written some direct links to obtain help on writing specific tags in > > SPEC file. I want direct link for License section on > > http://fedoraproject.org/wiki/Packaging/Guidelines. > > Can i get anchors on that page so that instead of giving this > > dynamic address of > > http://fedoraproject.org/wiki/Packaging/Guidelines#head-76294f12c6b481792eb001ba9763d95e2792e825 > > i can give static address that will remain same after any one edits that page. > > There are already anchors for each section on that page. For example: > http://fedoraproject.org/wiki/Packaging/Guidelines#LegalLicensing Thanks. I was not knowing this thing. Regards, Parag. From toshio at tiki-lounge.com Mon Jul 3 06:27:14 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 02 Jul 2006 23:27:14 -0700 Subject: [Fedora-packaging] New Mono Page for new guidelines In-Reply-To: <1151743574.20182.37.camel@laurel.intra.city-fan.org> References: <1151699310.2718.53.camel@localhost> <1151743574.20182.37.camel@laurel.intra.city-fan.org> Message-ID: <1151908034.3038.26.camel@localhost> On Sat, 2006-07-01 at 09:46 +0100, Paul Howarth wrote: > On Fri, 2006-06-30 at 13:28 -0700, Toshio Kuratomi wrote: > > I've reworked the Mono page to reflect the new Guidelines we confirmed > > yesterday. If people want to take a look, it's here: > > http://fedoraproject.org/wiki/PackagingDrafts/Mono > > > > Changes are color coded: Red removes, green adds, blue is a > > justification for people who didn't attend the meeting and will be > > removed from the final copy. (I probably should have done this before > > the meeting rather than after, sorry.) > > > > If no one objects, I'll replace the current Packaging/Mono page this > > weekend. > > The guidelines now say "no noarch packages". What about packages such as > lat, that are already in Extras as noarch and don't contain any > arch-specific AOTs? > The meeting log mentions that there are probably very few packages that contain pre-built AOTs (as opposed to glue-libraries which plainly go into %{_libdir}). The problem resides in the fact that the system administrator can choose to compile AOTs after installation of the package. Due to the fact that mono will only find AOTs that are in the same directory as the .dlls, the directory that the .dlls are in has to be the right one for an ELF shared object on that platform. This means /usr/lib for x86 and /usr/lib64 for x86_64. > It does, however, install an mcs-built .dll and .exe in %{_prefix}/lib. > It would need to be changed to %{_libdir} and non-noarch. The contents of the lat package may well be arch independent but doing this seems to be the least evil course to pursue WRT mono's limitations. This is also one of the issues that caused Debian to move mono from /usr/share to /usr/lib. > Is there anything technically wrong with this other than not lining up > with the guidelines? Hopefully the first paragraph explained that. If so, I'll try to merge that explanation into the guidelines. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lists at timj.co.uk Mon Jul 3 11:41:35 2006 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 03 Jul 2006 12:41:35 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> Message-ID: <44A9026F.1050903@timj.co.uk> Christopher Stone wrote: > On 7/2/06, Christopher Stone wrote: >> On 6/30/06, Joe Orton wrote: >> > Why should a PEAR package for foo provide php-foo? Not sure that's a >> > good idea. >> >> I'm not sure this is a good idea either, and I'm not sure of why it's >> part of the PHP packaging guidelines. >> > Okay, I found out why: > > [17:31] but where there is no name conflict > [17:31] each package should Provide: php-FOO = %{version}-%{release} > [17:31] this way, we should catch the yum install php-FOO case Not sure if I'm on my own here, but this seems like a lot of namespace clutter for little benefit. What's the problem with "yum install php-pear-FOO"? Tim From tibbs at math.uh.edu Mon Jul 3 13:54:14 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 03 Jul 2006 08:54:14 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <44A9026F.1050903@timj.co.uk> (Tim Jackson's message of "Mon, 03 Jul 2006 12:41:35 +0100") References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> Message-ID: >>>>> "TJ" == Tim Jackson writes: TJ> Not sure if I'm on my own here, but this seems like a lot of TJ> namespace clutter for little benefit. What's the problem with TJ> "yum install php-pear-FOO"? I believe spot's reasoning was that we don't want users to have to know whether what they want is in a PEAR or PECL module. I'm not sure it's worth the inevitable namespace collision. - J< From paul at city-fan.org Mon Jul 3 14:30:51 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 03 Jul 2006 15:30:51 +0100 Subject: [Fedora-packaging] New Mono Page for new guidelines In-Reply-To: <1151908034.3038.26.camel@localhost> References: <1151699310.2718.53.camel@localhost> <1151743574.20182.37.camel@laurel.intra.city-fan.org> <1151908034.3038.26.camel@localhost> Message-ID: <44A92A1B.1050301@city-fan.org> Toshio Kuratomi wrote: > On Sat, 2006-07-01 at 09:46 +0100, Paul Howarth wrote: >> The guidelines now say "no noarch packages". What about packages such as >> lat, that are already in Extras as noarch and don't contain any >> arch-specific AOTs? >> > The meeting log mentions that there are probably very few packages that > contain pre-built AOTs (as opposed to glue-libraries which plainly go > into %{_libdir}). The problem resides in the fact that the system > administrator can choose to compile AOTs after installation of the > package. Due to the fact that mono will only find AOTs that are in the > same directory as the .dlls, the directory that the .dlls are in has to > be the right one for an ELF shared object on that platform. This > means /usr/lib for x86 and /usr/lib64 for x86_64. > >> It does, however, install an mcs-built .dll and .exe in %{_prefix}/lib. >> > It would need to be changed to %{_libdir} and non-noarch. The contents > of the lat package may well be arch independent but doing this seems to > be the least evil course to pursue WRT mono's limitations. This is also > one of the issues that caused Debian to move mono from /usr/share > to /usr/lib. > >> Is there anything technically wrong with this other than not lining up >> with the guidelines? > > Hopefully the first paragraph explained that. If so, I'll try to merge > that explanation into the guidelines. Thanks for the explanation. I think it's very useful for guidelines to include the rationale behind them. It helps people to understand them and is also useful in determining whether an exception to the guidelines should be made, or indeed if the guidelines need updating to cover some case that hadn't been considered before. I've now updated lat to use %{_libdir} instead of %{_prefix}/lib and be arch-specific: http://cvs.fedora.redhat.com/viewcvs/devel/lat/lat.spec?root=extras&rev=1.5&view=markup Paul. From lists at timj.co.uk Mon Jul 3 16:26:19 2006 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 03 Jul 2006 17:26:19 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> Message-ID: <44A9452B.3050200@timj.co.uk> Jason L Tibbitts III wrote: >>>>>> "TJ" == Tim Jackson writes: > > TJ> Not sure if I'm on my own here, but this seems like a lot of > TJ> namespace clutter for little benefit. What's the problem with > TJ> "yum install php-pear-FOO"? > > I believe spot's reasoning was that we don't want > users to have to know whether what they want is in a PEAR or PECL > module. I'm not sure it's worth the inevitable namespace collision. I can see the reasoning (Tom?), but: a) PEAR and PECL are fundamentally two quite different things. If someone is specifically installing a PEAR or PECL package (as opposed to getting one pulled in as a dep of something else, in which case the naming is mostly irrelevant) then presumably they already know what it is and how to use it. If they don't know whether it's a PEAR or a PECL module, they're not likely to have much success using it, not least because PECL extends the language core with (normally procedural) functions that don't need external requires() whereas PEAR modules are PHP classes that normally need explicit requires() when they are used. b) Even ignoring (a), personally I think the namespace clutter and possible collisions mean that it's not really worth it. Tim From tibbs at math.uh.edu Mon Jul 3 19:09:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 03 Jul 2006 14:09:45 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Sun, 2 Jul 2006 16:23:01 -0700") References: <20060630095230.GA19767@redhat.com> Message-ID: I think we need to get moving on this; I'd hope to have something which has at least some chance of passing by the next meeting. For PEAR modules, we currently have this proposal: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec which still suffers from excess macroization (%{__rm} and other such horrors) but otherwise looks pretty good. We still need to decide whether php-pear-X should really provide php-X. At this point I'd vote against. It looks like the :MODULE_COMPAT thing is a non-starter, so PHP packagers will just have to deal with incompatibilities that silently crop up. For PECL modules, I haven't seen much discussion. What needs to happen here? For extensions like php-shout and other packages like php-Smarty, we really don't have any guidelines at all, and we need some. I'm not familiar enough with the issues to even know where to start. Both PECL and plain extensions seem to need a couple of defines; the existing php-pecl-apc package (which somehow was approved recently for Extras) uses these: %define php_extdir %(php-config --extension-dir 2>/dev/null || echo %{_libdir}/php4) %define php_apiver %((echo %{default_apiver}; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) The second could use a bit of explanation, I think. - J< From lists at timj.co.uk Mon Jul 3 21:24:19 2006 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 03 Jul 2006 22:24:19 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> Message-ID: <44A98B03.3010303@timj.co.uk> Jason L Tibbitts III wrote: > For PEAR modules, we currently have this proposal: > > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec To assist things and provide a real-world example I've rebuilt PEAR_Command_Packaging with its own spec file (almost) in line with the above proposal. As the person possibly most interested in this, I very much like Christopher's proposal and give it a +1. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423 http://www.timj.co.uk/linux/specs/php-pear-PEAR-Command-Packaging.spec http://www.timj.co.uk/linux/srpms/php-pear-PEAR-Command-Packaging-0.1.1-1.src.rpm (NB the spec files that the above package *generates* aren't yet in line with the guidelines above; I'm not fiddling with patches for that until we settle on something) > which still suffers from excess macroization (%{__rm} and other such > horrors) but otherwise looks pretty good. Personally I don't care either way about the "excess" macroization; the above package lacks this. > We still need to decide whether php-pear-X should really provide php-X. > At this point I'd vote against. I agree. > It looks like the :MODULE_COMPAT thing is a non-starter, so PHP > packagers will just have to deal with incompatibilities that silently > crop up. NB that PEAR packages have the ability to define explicit PHP version deps/conflicts, which may assist things. Not least because PEAR_Command_Packaging will automatically pick these up and encode them in the specs (assuming the upstream authors use them, of course...) > For PECL modules, I haven't seen much discussion. What needs to > happen here? I think that's a whole lot less clear and ideally we should defer this for a little while, or at least not let it delay the approval of the PEAR packaging spec. For a start, I believe there are upstream (i.e. in PEAR) bugs that prevent the --register-only function working for PECL packages. However, Christopher Stone is investigating this. From my point of view, the PECL specs should ultimately look almost exactly like the PEAR specs, since the process (pear install --packagingroot etc.) should (in theory, though I don't think it currently does) work for PECL too. > %define php_extdir %(php-config --extension-dir 2>/dev/null || echo %{_libdir}/php4) > %define php_apiver %((echo %{default_apiver}; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) > > The second could use a bit of explanation, I think. Not sure whether you're asking for clarification or just mentioning it for the record, but anyway here goes... The point is to tie the package to an ABI version. Previously PECL packages were tied to a specific PHP version which meant they had to be rebuilt every time Core PHP was updated even if the ABI remained constant. The little macro above saves this unnecessary rebuilding by making sure the dep doesn't break if an ABI-compatible update of PHP takes place. Tim From chris.stone at gmail.com Tue Jul 4 00:37:57 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 3 Jul 2006 17:37:57 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <44A98B03.3010303@timj.co.uk> References: <20060630095230.GA19767@redhat.com> <44A98B03.3010303@timj.co.uk> Message-ID: On 7/3/06, Tim Jackson wrote: > Jason L Tibbitts III wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423 > http://www.timj.co.uk/linux/specs/php-pear-PEAR-Command-Packaging.spec > http://www.timj.co.uk/linux/srpms/php-pear-PEAR-Command-Packaging-0.1.1-1.src.rpm I do not like the way patches are handled in this case. I have reworked the spec file here: http://tkmame.retrogames.com/fedora-extras/php-pear-PEAR-Command-Packaging.spec Where the patches are done normally. Perhaps we should use this type of install as a standard? That is, untarring the tarball, making any necessary patches, then installing with the .xml file? An update SRPM with fixed patches is here: http://tkmame.retrogames.com/fedora-extras/php-pear-PEAR-Command-Packaging-0.1.2-2.src.rpm From chris.stone at gmail.com Tue Jul 4 01:06:45 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 3 Jul 2006 18:06:45 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> Message-ID: On 7/3/06, Jason L Tibbitts III wrote: > I think we need to get moving on this; I'd hope to have something > which has at least some chance of passing by the next meeting. > > For PEAR modules, we currently have this proposal: > > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec > > which still suffers from excess macroization (%{__rm} and other such > horrors) but otherwise looks pretty good. We still need to decide > whether php-pear-X should really provide php-X. At this point I'd > vote against. I have updated the template: -removed excess macroization (ugh) -used new (untested) install using xml instead of tar method to allow for proper patching (I will test this out with my pear packages and make sure it works fine) -install .xml file with install command instead of cp command -use full path to pear in %post/un scriptlets (there was some discussion that this should be done? if so, can we have a %{__pear} macro defined so I can use this here? -changed %files to have %{peardir}/Foo instead of Foo_Bar -removed "Provides: php-Foo-Bar" line From lists at timj.co.uk Tue Jul 4 08:58:27 2006 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 04 Jul 2006 09:58:27 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A98B03.3010303@timj.co.uk> Message-ID: <44AA2DB3.2090304@timj.co.uk> Christopher Stone wrote: > On 7/3/06, Tim Jackson wrote: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423 >> http://www.timj.co.uk/linux/specs/php-pear-PEAR-Command-Packaging.spec >> http://www.timj.co.uk/linux/srpms/php-pear-PEAR-Command-Packaging-0.1.1-1.src.rpm > I do not like the way patches are handled in this case. I have > reworked the spec file here: > http://tkmame.retrogames.com/fedora-extras/php-pear-PEAR-Command-Packaging.spec Looks fine to me. I agree that's more readable. > Where the patches are done normally. Perhaps we should use this type > of install as a standard? That is, untarring the tarball, making any > necessary patches, then installing with the .xml file? Good idea. The end result should be exactly the same. Although it does add an extra step for packages that *don't* need patching. (Which hopefully most won't; PEAR_Command_Packaging should be an exception) Tim From rc040203 at freenet.de Tue Jul 4 09:03:32 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 04 Jul 2006 11:03:32 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <44AA2DB3.2090304@timj.co.uk> References: <20060630095230.GA19767@redhat.com> <44A98B03.3010303@timj.co.uk> <44AA2DB3.2090304@timj.co.uk> Message-ID: <1152003812.8787.53.camel@mccallum.corsepiu.local> On Tue, 2006-07-04 at 09:58 +0100, Tim Jackson wrote: > Christopher Stone wrote: > > > On 7/3/06, Tim Jackson wrote: > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423 > >> http://www.timj.co.uk/linux/specs/php-pear-PEAR-Command-Packaging.spec > >> http://www.timj.co.uk/linux/srpms/php-pear-PEAR-Command-Packaging-0.1.1-1.src.rpm > > > I do not like the way patches are handled in this case. I have > > reworked the spec file here: > > http://tkmame.retrogames.com/fedora-extras/php-pear-PEAR-Command-Packaging.spec > > Looks fine to me. I agree that's more readable. I disagree on this: .. Requires(post): php-pear Requires(pre): php-pear .. %post pear install --nodeps --soft --force --register-only %{xmldir}/PEAR_Command_Packaging.xml >/dev/null ||: .. %postun if [ "$1" -eq "0" ]; then pear uninstall --nodeps --ignore-errors --register-only PEAR_Command_Packaging >/dev/null ||: fi Also c.f. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197561 Ralf From lists at timj.co.uk Tue Jul 4 09:43:47 2006 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 04 Jul 2006 10:43:47 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152003812.8787.53.camel@mccallum.corsepiu.local> References: <20060630095230.GA19767@redhat.com> <44A98B03.3010303@timj.co.uk> <44AA2DB3.2090304@timj.co.uk> <1152003812.8787.53.camel@mccallum.corsepiu.local> Message-ID: <44AA3853.1040406@timj.co.uk> Ralf Corsepius wrote: > I disagree on this: > .. > Requires(post): php-pear > Requires(pre): php-pear > .. > %post > pear install --nodeps --soft --force --register-only %{xmldir}/PEAR_Command_Packaging.xml >/dev/null ||: > .. > %postun > if [ "$1" -eq "0" ]; then > pear uninstall --nodeps --ignore-errors --register-only PEAR_Command_Packaging >/dev/null ||: > fi > > Also c.f. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197561 Fair point I think. No problem by me. Tim From jorton at redhat.com Tue Jul 4 10:28:13 2006 From: jorton at redhat.com (Joe Orton) Date: Tue, 4 Jul 2006 11:28:13 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1151677289.7108.18.camel@localhost.localdomain> References: <20060630095230.GA19767@redhat.com> <1151674644.7108.15.camel@localhost.localdomain> <44A52CF4.9000002@city-fan.org> <1151677289.7108.18.camel@localhost.localdomain> Message-ID: <20060704102813.GA30005@redhat.com> On Fri, Jun 30, 2006 at 09:21:29AM -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-06-30 at 14:53 +0100, Paul Howarth wrote: > > Tom 'spot' Callaway wrote: > > > On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote: > > > > > >> On "Other Packages": an application written in PHP or such like should > > >> not have a php- prefix at all. A Smarty package should be called > > >> "smarty" (following the "upper-case is evil" rule of packaging). > > > > > > Indeed, this is correct. The php-* (and php-pecl/pear) namespace are > > > reserved for items that add new functionality/modules to PHP, not for > > > applications written in PHP. > > > > Smarty is not an application in itself; it's a library of PHP code used > > in other applications. As such it adds functionality to PHP... > > Then (in the case of smarty), it does need to be in the php namespace. I > think if its not a pecl/pear, but it adds functionality to PHP, then it > should be php-%{name}. Smarty does not "add functionality to PHP" any more than libxml "adds functionality to C". If Smarty was installed somewhere the default include_path would pick up you could make a case; but it's not. It's just a library of PHP code. joe From jorton at redhat.com Tue Jul 4 10:37:43 2006 From: jorton at redhat.com (Joe Orton) Date: Tue, 4 Jul 2006 11:37:43 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> Message-ID: <20060704103743.GA30570@redhat.com> On Mon, Jul 03, 2006 at 08:54:14AM -0500, Jason L Tibbitts III wrote: > >>>>> "TJ" == Tim Jackson writes: > > TJ> Not sure if I'm on my own here, but this seems like a lot of > TJ> namespace clutter for little benefit. What's the problem with > TJ> "yum install php-pear-FOO"? > > I believe spot's reasoning was that we don't want > users to have to know whether what they want is in a PEAR or PECL > module. I'm not sure it's worth the inevitable namespace collision. I completely agree with Tim. You *have* to know whether the package is a PEAR or PECL extension to be able to use it; we should not attempt to hide this distinction from anybody, it will only lead to confusion and future conflicts. joe From toshio at tiki-lounge.com Tue Jul 4 14:13:44 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 04 Jul 2006 07:13:44 -0700 Subject: [Fedora-packaging] New Mono Page for new guidelines In-Reply-To: <44A92A1B.1050301@city-fan.org> References: <1151699310.2718.53.camel@localhost> <1151743574.20182.37.camel@laurel.intra.city-fan.org> <1151908034.3038.26.camel@localhost> <44A92A1B.1050301@city-fan.org> Message-ID: <1152022424.24961.6.camel@localhost> On Mon, 2006-07-03 at 15:30 +0100, Paul Howarth wrote: > Toshio Kuratomi wrote: > > On Sat, 2006-07-01 at 09:46 +0100, Paul Howarth wrote: > >> The guidelines now say "no noarch packages". What about packages such as > >> lat, that are already in Extras as noarch and don't contain any > >> arch-specific AOTs? > >> > > The meeting log mentions that there are probably very few packages that > > contain pre-built AOTs (as opposed to glue-libraries which plainly go > > into %{_libdir}). The problem resides in the fact that the system > > administrator can choose to compile AOTs after installation of the > > package. Due to the fact that mono will only find AOTs that are in the > > same directory as the .dlls, the directory that the .dlls are in has to > > be the right one for an ELF shared object on that platform. This > > means /usr/lib for x86 and /usr/lib64 for x86_64. > > > >> It does, however, install an mcs-built .dll and .exe in %{_prefix}/lib. > >> > > It would need to be changed to %{_libdir} and non-noarch. The contents > > of the lat package may well be arch independent but doing this seems to > > be the least evil course to pursue WRT mono's limitations. This is also > > one of the issues that caused Debian to move mono from /usr/share > > to /usr/lib. > > > >> Is there anything technically wrong with this other than not lining up > >> with the guidelines? > > > > Hopefully the first paragraph explained that. If so, I'll try to merge > > that explanation into the guidelines. > > Thanks for the explanation. I think it's very useful for guidelines to > include the rationale behind them. It helps people to understand them > and is also useful in determining whether an exception to the guidelines > should be made, or indeed if the guidelines need updating to cover some > case that hadn't been considered before. > I revised the File Locations section with the information about how the system administrator can create AOTs after install. Hopefully it's now clearer why we're making things arch-specific. I'll copy this version over to the formal Packaging/ tree later today unless there are more suggestions. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Tue Jul 4 16:04:34 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 04 Jul 2006 11:04:34 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <20060704103743.GA30570@redhat.com> References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> Message-ID: <1152029074.14439.15.camel@localhost.localdomain> On Tue, 2006-07-04 at 11:37 +0100, Joe Orton wrote: > On Mon, Jul 03, 2006 at 08:54:14AM -0500, Jason L Tibbitts III wrote: > > >>>>> "TJ" == Tim Jackson writes: > > > > TJ> Not sure if I'm on my own here, but this seems like a lot of > > TJ> namespace clutter for little benefit. What's the problem with > > TJ> "yum install php-pear-FOO"? > > > > I believe spot's reasoning was that we don't want > > users to have to know whether what they want is in a PEAR or PECL > > module. I'm not sure it's worth the inevitable namespace collision. > > I completely agree with Tim. You *have* to know whether the package is > a PEAR or PECL extension to be able to use it; we should not attempt to > hide this distinction from anybody, it will only lead to confusion and > future conflicts. Consider that provision dropped, I was never overly attached to it anyways. :) ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Tue Jul 4 16:15:50 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 04 Jul 2006 11:15:50 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152029074.14439.15.camel@localhost.localdomain> (Tom Callaway's message of "Tue, 04 Jul 2006 11:04:34 -0500") References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom Callaway writes: TC> Consider that provision dropped, I was never overly attached to it TC> anyways. :) I've removed it from the draft. Can we agree to excise the :MODULE_COMPAT stuff as well? - J< From tcallawa at redhat.com Tue Jul 4 16:29:56 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 04 Jul 2006 11:29:56 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> Message-ID: <1152030596.16687.2.camel@localhost.localdomain> On Tue, 2006-07-04 at 11:15 -0500, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom Callaway writes: > > TC> Consider that provision dropped, I was never overly attached to it > TC> anyways. :) > > I've removed it from the draft. Can we agree to excise the > :MODULE_COMPAT stuff as well? Sure, especially if the php owner doesn't see the value in adding it. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From chris.stone at gmail.com Tue Jul 4 17:40:48 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 10:40:48 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152030596.16687.2.camel@localhost.localdomain> References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: Can we have some macros defined in the /usr/lib/rpm/macros file? I would like: %__pear /usr/bin/pear %__pecl /usr/bin/pecl and perhaps some pear macros similar to the perl macros: %perl_sitearch %(eval "`%{__perl} -V:installsitearch`"; echo $installsitearch) %pear_phpdir %(eval "`%{__pear} config-get php_dir`"; echo $php_dir) or something similar to this? From tibbs at math.uh.edu Tue Jul 4 18:04:09 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 04 Jul 2006 13:04:09 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152030596.16687.2.camel@localhost.localdomain> (Tom Callaway's message of "Tue, 04 Jul 2006 11:29:56 -0500") References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom Callaway writes: TC> Sure, especially if the php owner doesn't see the value in adding TC> it. OK, it's now gone; in it's place is Requires: php >= current PHP version Perl would use Requires: perl(:MODULE_COMPAT_current-perl-version) here. I suppose we'll need a macro to extract the current PHP version. %define php_version %(php-config --version 2>/dev/null || echo 0) Should we use the full path to php-config here? The Ruby specfile template doesn't. The Ruby template also wraps its macros like %{!?ruby_sitelib: ...}; do we need to do the same? Here are the macros I've seen, renamed to be consistent with what other language templates use (php_*). I also replaced any default values provided with either "undefined" or "0". These macros only have to result in something which is syntactically correct when things aren't yet installed; I'm concerned that providing a meaningful default value would both become outdated (as uses of "php4" will soon be) and might still produce something that looks OK even when a BR is missing. For PEAR modules: %define php_peardir %(pear config-get php_dir 2> /dev/null || echo undefined) %define php_peardatadir %(pear config-get data_dir 2> /dev/null || echo undefined) %define php_pearxmldir %{php_peardir}/.pkgxml %define php_version %(php-config --version 2>/dev/null || echo 0) For PECL modules: %define php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) %define php_extdir %(php-config --extension-dir 2>/dev/null || echo "undefined") %define php_version %(php-config --version 2>/dev/null || echo 0) Modules which are neither PEAR nor PECL will need to use whichever locations and macros are appropriate. Extensions like php-shout will need the PECL defines, for example. I looked at php-Smarty and found that it gets installed essentially as a web application. It drops itself in %_datadir/Smarty. At first glance that seems pretty odd. I guess it's not really a PHP module at all. Here are the subbested %post and %postun scriptlets from the ticket Ralf cited earlier: Requires(%post): /usr/bin/pear Requires(%postun): /usr/bin/pear %post /usr/bin/pear install --nodeps --soft --force --register-only %{php_pearxmldir}/PEAR_Command_Packaging.xml >/dev/null %postun if [ "$1" -eq "0" ]; then /usr/bin/pear uninstall --nodeps --ignore-errors --register-only PEAR_Command_Packaging >/dev/null fi I removed the ||: bits as my understanding is that they are no longer required or wanted. Do PECL modules need any scriptlets? Finally, should we consider providing macros to assist in converting between the various representation of the package name? We have php-pear-module-name, PEAR_Module_name and probably a few others. - J< From tibbs at math.uh.edu Tue Jul 4 18:16:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 04 Jul 2006 13:16:47 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Tue, 4 Jul 2006 10:40:48 -0700") References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> Can we have some macros defined in the /usr/lib/rpm/macros file? I agree that it might be nice, but I don't think it reasonable to wait for Red Hat to push an RPM update before we can get guidelines out. We could consider recommending: %{!?__php: %define __php /usr/bin/php} %{!?__pear: %define __pear /usr/bin/pear} %{!?__pecl: %define __pecl /usr/bin/pecl} Which would work now and would continue to work even if the core RPM package is updated. After we no longer support any releases that don't have the macros defined by default, we could drop those three defines from the guidelines and the templates. - J< From nicolas.mailhot at laposte.net Tue Jul 4 18:28:12 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Jul 2006 20:28:12 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: <1152037694.21876.2.camel@rousalka.dyndns.org> Le mardi 04 juillet 2006 ? 13:16 -0500, Jason L Tibbitts III a ?crit : > >>>>> "CS" == Christopher Stone writes: > > CS> Can we have some macros defined in the /usr/lib/rpm/macros file? > > I agree that it might be nice, but I don't think it reasonable to wait > for Red Hat to push an RPM update before we can get guidelines out. Can't the core php package drop a macros file in /etc/rpm/ ? Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From chris.stone at gmail.com Tue Jul 4 18:45:31 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 11:45:31 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: On 7/4/06, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom Callaway writes: > > TC> Sure, especially if the php owner doesn't see the value in adding > TC> it. > > OK, it's now gone; in it's place is > > Requires: php >= current PHP version > > Perl would use Requires: perl(:MODULE_COMPAT_current-perl-version) > here. > > I suppose we'll need a macro to extract the current PHP version. > > %define php_version %(php-config --version 2>/dev/null || echo 0) > > Should we use the full path to php-config here? The Ruby specfile > template doesn't. The Ruby template also wraps its macros like > %{!?ruby_sitelib: ...}; do we need to do the same? If I understand things correctly, there are basically two types of php packages, those written in C or some other language which create a .so file which gets loaded by the php.ini file, and those that are written in php which only add .php files otherwise known as "class libraries". pecl modules create .so files, pear modules are only .php files, and other modules can be either or. For example, php-Smarty is only .php files and php-mysql adds .so and .ini files. "pear" and "pecl" packages are just like php-Foo packages except that they have been classified into one of these two types and are tared in a way in which they can be installed using the /usr/bin/pear or /usr/bin/pecl commands. Packages which are .php files only such as php-Smarty or php-pear-Foo need only require php >= version they say they require, or if they do not say, then php >= current version (or no version) should be fine. I have some php-pear packages which specifically indicate they need php >= 4.2.0 some that say they need php >= 4.3.0. If these versions are specified by the package, they should be indicated in the spec file (IMO). Packages which make .so files and load them in .ini files should require a php-api version. The api version can be obtained like so: %define apiver %((phpize --version 2>/dev/null || echo 'PHP Api Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*: *//p') Requires: php-api >= %{apiver} packages such as php-mysql or php-pecl-Foo should have this. > For PEAR modules: > > %define php_peardir %(pear config-get php_dir 2> /dev/null || echo undefined) > %define php_peardatadir %(pear config-get data_dir 2> /dev/null || echo undefined) > %define php_pearxmldir %{php_peardir}/.pkgxml > %define php_version %(php-config --version 2>/dev/null || echo 0) > > > For PECL modules: > > %define php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) > %define php_extdir %(php-config --extension-dir 2>/dev/null || echo "undefined") > %define php_version %(php-config --version 2>/dev/null || echo 0) Note pear and pecl modules both need to get path infomation in the same way: %define php_peardir %(pear config-get php_dir 2> /dev/null || echo undefined) %define php_peardir %(pecl config-get php_dir 2> /dev/null || echo undefined) Say calling this macro "php_peardir" is not a good idea, instead a better name would be "php_phpdir", "php_datadir" etc.. I think it was determined that the API macro of: %define apiver %((phpize --version 2>/dev/null || echo 'PHP Api Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*: *//p') was considered "better" for some reason, I will have to find out which bug this was commented on to try and find out why. > I looked at php-Smarty and found that it gets installed essentially as > a web application. It drops itself in %_datadir/Smarty. At first > glance that seems pretty odd. I guess it's not really a PHP module at > all. Smarty is not an application, it is just like any other pear package in that it adds a "class library" which can be used by php developers. If there is something wrong with installing it in %_datadir, where should it go instead? > Here are the subbested %post and %postun scriptlets from the ticket > Ralf cited earlier: > > Requires(%post): /usr/bin/pear > Requires(%postun): /usr/bin/pear How is this different than: Requires(post): php-pear > > %post > /usr/bin/pear install --nodeps --soft --force --register-only %{php_pearxmldir}/PEAR_Command_Packaging.xml >/dev/null > > %postun > if [ "$1" -eq "0" ]; then > /usr/bin/pear uninstall --nodeps --ignore-errors --register-only PEAR_Command_Packaging >/dev/null > fi > > I removed the ||: bits as my understanding is that they are no longer > required or wanted. Why are these no longer wanted? First I am told to put them in, and now I am told not to. Can we get clarification on why and if it is better practice not to, can we update the Scriptlets wiki page to indicate this? > > Do PECL modules need any scriptlets? PECL modules will need the exact same scriptlets only they will use the /usr/bin/pecl command instead of the /usr/bin/pear command. However /usr/bin/pecl is currently broken and a bug needs to be filed for this upstream. > > Finally, should we consider providing macros to assist in converting > between the various representation of the package name? We have > php-pear-module-name, PEAR_Module_name and probably a few others. Sure, is fedora-newrpmspec powerfull enough to do this? I think this is all that is required: Provides: php-pear-Foo-Bar >= %{version}-%{release} Provides: php-pear(Foo_Bar) >= %{version}-%{release} If we want to cater to newbs I really don't think we will ever have any name collisions with: Provides: php-Foo-Bar >= %{version}-%{release} Provides: php-Foo_Bar >= %{version}-%{release} In the rare (and possibly will never happen) case that there is a name collision we can require that these provides be entered manually to avoid such collision. From chris.stone at gmail.com Tue Jul 4 19:40:43 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 12:40:43 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: I would also like to get clarification on Groups, everyone seems to have their own ideas as to what should be "System Environment/Libraries", "Development/Libraries" or "Development/Languages" Should all php-pecl-* packages be grouped as "Development/Languages"? Should all php-pear packages be "Development/Libraries"? This is the status-quo now. When should a package be "System Environment" vs. "Development"? I cannot find a definition on what this means. I went through some perl-* packages and python-* packages and Groups are all over the place, python-kid for example is grouped as an Application. I think some definitions and example packages in the Groups wiki page would be nice to have as a reference. >From what I can tell right now, Group tags are not really considered that important and randomness seems to be the accepted practice. I have not seen any response to my Group tag questions on this mailing list and discussions on IRC lead to different answers by different people. So I have to assume that the Groups as they stand right now currently have no definition? From tibbs at math.uh.edu Tue Jul 4 19:43:31 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 04 Jul 2006 14:43:31 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Tue, 4 Jul 2006 11:45:31 -0700") References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> I have some php-pear packages which specifically indicate they CS> need php >= 4.2.0 some that say they need php >= 4.3.0. If these CS> versions are specified by the package, they should be indicated in CS> the spec file (IMO). I'm not sure I agree; Perl and Python modules will require the version of Perl or Python that was installed when the package was built (via perl(:MODULE_COMPAT_blah) or python-abi); it is certainly simpler to figure it out automatically instead of leaving it to the packager to try and specify something which may be essentially meaningless. But on the other hand, of core updates the PHP package, we don't want modules automatically forcing a core PHP package update. So I guess I'm undecided. CS> Note pear and pecl modules both need to get path infomation in the CS> same way: Doesn't look the same to me; one calls "pear", the other calls "pecl". Are you saying that those two directories will always be identical even though two different programs are called to figure that out? [Smarty] CS> If there is something wrong with installing it in CS> %_datadir, where should it go instead? Well, thankfully every Perl and Python class library doesn't go in %_datadir; we'd have thousands and thousands of directories there. Why not some PHP-specific place? CS> How is this different than: Requires(post): php-pear We don't use Requires(post): glibc when we want to call /sbin/ldconfig. [ || : bits] CS> Why are these no longer wanted? First I am told to put them in, and CS> now I am told not to. I was asked to remove them and told they were no longer necessary for one of my packages, but now I can't find it where that was. (I think it was the denyhosts review, but that ticket seems to be missing from bugzilla completely for whatever reason.) Honestly I don't fully understand the issue so don't take what I wrote as the way things have to be. - J< From paul at city-fan.org Tue Jul 4 19:59:17 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 04 Jul 2006 20:59:17 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: <1152043157.28401.2.camel@laurel.intra.city-fan.org> On Tue, 2006-07-04 at 14:43 -0500, Jason L Tibbitts III wrote: > >>>>> "CS" == Christopher Stone writes: > [ || : bits] > CS> Why are these no longer wanted? First I am told to put them in, and > CS> now I am told not to. > > I was asked to remove them and told they were no longer necessary for > one of my packages, but now I can't find it where that was. (I think > it was the denyhosts review, but that ticket seems to be missing from > bugzilla completely for whatever reason.) > > Honestly I don't fully understand the issue so don't take what I wrote > as the way things have to be. One of the scriptlets in question was: %postun if [ "$1" -eq "0" ]; then /usr/bin/pear uninstall --nodeps --ignore-errors --register-only \ PEAR_Command_Packaging >/dev/null fi I'll speculate that the --ignore-errors option means that pear will never return a non-zero exit status and hence the "|| :" is not needed to ensure that the scriptlet always "succeeds". Paul. From lists at timj.co.uk Tue Jul 4 22:21:19 2006 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 04 Jul 2006 23:21:19 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: <44AAE9DF.2080704@timj.co.uk> Jason L Tibbitts III wrote: >>>>>> "CS" == Christopher Stone writes: > > CS> I have some php-pear packages which specifically indicate they > CS> need php >= 4.2.0 some that say they need php >= 4.3.0. If these > CS> versions are specified by the package, they should be indicated in > CS> the spec file (IMO). > > I'm not sure I agree; Perl and Python modules will require the version > of Perl or Python that was installed when the package was built (via > perl(:MODULE_COMPAT_blah) or python-abi); it is certainly simpler to > figure it out automatically instead of leaving it to the packager to > try and specify something which may be essentially meaningless. But > on the other hand, of core updates the PHP package, we don't want > modules automatically forcing a core PHP package update. So I guess > I'm undecided. If it's any help, the authors of many PEAR/PECL packages specify explicit versions via the package.xml file included with the tarball. In this case I think we should just go with what upstream specify as they're by far the best placed to judge. NB that at least for specs generated via PEAR_Command_Packaging, this stuff will happen automatically; the specified version (if any) in package.xml will be translated into an RPM Requires:. Tim From chris.stone at gmail.com Tue Jul 4 22:35:54 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 15:35:54 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <44AAE9DF.2080704@timj.co.uk> References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <44AAE9DF.2080704@timj.co.uk> Message-ID: BTW, I have updated my pear spec template http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec to %ghost %{peardir}/.* rather than rm'ing them during the install. From chris.stone at gmail.com Tue Jul 4 22:40:43 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 15:40:43 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <44AAE9DF.2080704@timj.co.uk> Message-ID: On 7/4/06, Christopher Stone wrote: > BTW, I have updated my pear spec template > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec to > %ghost %{peardir}/.* rather than rm'ing them during the install. %exclude might be better here, I think %ghost might try to remove them on uninstall, but I'm not sure why pear puts them there to begin with? Either way, I think those files should be in either %exclude or %ghost rather than rm'd during the install process. From lists at timj.co.uk Tue Jul 4 22:45:37 2006 From: lists at timj.co.uk (Tim Jackson) Date: Tue, 04 Jul 2006 23:45:37 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <44AAE9DF.2080704@timj.co.uk> Message-ID: <44AAEF91.3070102@timj.co.uk> Christopher Stone wrote: > On 7/4/06, Christopher Stone wrote: >> BTW, I have updated my pear spec template >> http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec to >> %ghost %{peardir}/.* rather than rm'ing them during the install. > > %exclude might be better here, I think %ghost might try to remove them > on uninstall, but I'm not sure why pear puts them there to begin with? Because when we do stuff in RPM build roots, PEAR has nowhere to write its package data (e.g. list of installed packages) so it sets up all those files. They are not needed in any way. Arguably the --packagingroot option should omit the generation of these files full stop. Might be worth discussing upstream. > Either way, I think those files should be in either %exclude or > %ghost rather than rm'd during the install process. I'm not sure what difference it makes whether they are rm'd or excluded. They certainly don't want to be %ghost. Tim From chris.stone at gmail.com Tue Jul 4 22:56:45 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 15:56:45 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152043157.28401.2.camel@laurel.intra.city-fan.org> References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <1152043157.28401.2.camel@laurel.intra.city-fan.org> Message-ID: On 7/4/06, Paul Howarth wrote: > On Tue, 2006-07-04 at 14:43 -0500, Jason L Tibbitts III wrote: > > >>>>> "CS" == Christopher Stone writes: > > [ || : bits] > > CS> Why are these no longer wanted? First I am told to put them in, and > > CS> now I am told not to. > > > > I was asked to remove them and told they were no longer necessary for > > one of my packages, but now I can't find it where that was. (I think > > it was the denyhosts review, but that ticket seems to be missing from > > bugzilla completely for whatever reason.) > > > > Honestly I don't fully understand the issue so don't take what I wrote > > as the way things have to be. > > One of the scriptlets in question was: > > %postun > if [ "$1" -eq "0" ]; then > /usr/bin/pear uninstall --nodeps --ignore-errors --register-only \ > PEAR_Command_Packaging >/dev/null > fi > > I'll speculate that the --ignore-errors option means that pear will > never return a non-zero exit status and hence the "|| :" is not needed > to ensure that the scriptlet always "succeeds". I supposed there is always a chance a buggy pear breaks the --ignore-errors option, if someone has a hosed system and php segfaults, will this also not be an issue, not sure if a segfault or something constitutes an error being returned? I kind of feel safer keeping it there for insurance, but if there is a consensus to remove it, that is fine with me. From chris.stone at gmail.com Tue Jul 4 23:00:13 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 16:00:13 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <44AAEF91.3070102@timj.co.uk> References: <20060630095230.GA19767@redhat.com> <1152030596.16687.2.camel@localhost.localdomain> <44AAE9DF.2080704@timj.co.uk> <44AAEF91.3070102@timj.co.uk> Message-ID: On 7/4/06, Tim Jackson wrote: > Christopher Stone wrote: > > On 7/4/06, Christopher Stone wrote: > >> BTW, I have updated my pear spec template > >> http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec to > >> %ghost %{peardir}/.* rather than rm'ing them during the install. > > > > %exclude might be better here, I think %ghost might try to remove them > > on uninstall, but I'm not sure why pear puts them there to begin with? > > Because when we do stuff in RPM build roots, PEAR has nowhere to write > its package data (e.g. list of installed packages) so it sets up all > those files. They are not needed in any way. > > Arguably the --packagingroot option should omit the generation of these > files full stop. Might be worth discussing upstream. Yes, please, we should not have to deal with this in every single pear spec file. > > > Either way, I think those files should be in either %exclude or > > %ghost rather than rm'd during the install process. > > I'm not sure what difference it makes whether they are rm'd or excluded. > They certainly don't want to be %ghost. I'll change the spec to %exclude and then we can just remove that once upstream fixes pear/pecl commands from generating those files. From chris.stone at gmail.com Tue Jul 4 23:25:05 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 16:25:05 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <44AAEF91.3070102@timj.co.uk> References: <20060630095230.GA19767@redhat.com> <1152030596.16687.2.camel@localhost.localdomain> <44AAE9DF.2080704@timj.co.uk> <44AAEF91.3070102@timj.co.uk> Message-ID: On 7/4/06, Tim Jackson wrote: > Arguably the --packagingroot option should omit the generation of these > files full stop. Might be worth discussing upstream. One could also argue that installing the package.xml file into a standard PHP defined location could also be done with --packagingroot to allow for installers such as rpm to properly register and unregister the packages. This would allow us to remove more "cruft" from the spec files. From chris.stone at gmail.com Wed Jul 5 00:04:39 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 17:04:39 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: On 7/4/06, Jason L Tibbitts III wrote: > >>>>> "CS" == Christopher Stone writes: > CS> Note pear and pecl modules both need to get path infomation in the > CS> same way: > > Doesn't look the same to me; one calls "pear", the other calls > "pecl". Are you saying that those two directories will always be > identical even though two different programs are called to figure that > out? I meant they get the information in the same way, yes. Basically the only difference is one uses the pear command and one uses the pecl command. > [Smarty] > CS> If there is something wrong with installing it in > CS> %_datadir, where should it go instead? > > Well, thankfully every Perl and Python class library doesn't go in > %_datadir; we'd have thousands and thousands of directories there. > Why not some PHP-specific place? /usr/share/php/Smarty is definately smarter ;-) > > CS> How is this different than: Requires(post): php-pear > > We don't use Requires(post): glibc when we want to call > /sbin/ldconfig. > I have updated the template spec file here: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec I am assuming that the php-pear package drops in the %{__pear} and %{__pecl} macros as suggested by Nicolas. > [ || : bits] > CS> Why are these no longer wanted? First I am told to put them in, and > CS> now I am told not to. > > I was asked to remove them and told they were no longer necessary for > one of my packages, but now I can't find it where that was. (I think > it was the denyhosts review, but that ticket seems to be missing from > bugzilla completely for whatever reason.) > > Honestly I don't fully understand the issue so don't take what I wrote > as the way things have to be. I have left these in for now, rather be safe than sorry. From chris.stone at gmail.com Wed Jul 5 00:14:59 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 17:14:59 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: On 7/4/06, Christopher Stone wrote: > I am assuming that the php-pear package drops in the %{__pear} and > %{__pecl} macros as suggested by Nicolas. Actually if the php-pear package does this, the php-pear package should also define all these macros: %{!?__pear: %define __pear /usr/bin/pear} %{!?__pecl: %define __pecl /usr/bin/pecl} %define pear_phpdir %(%{__pear} config-get php_dir 2> /dev/null || echo undefined) %define pear_docdir %(%{__pear} config-get doc_dir 2> /dev/null || echo undefined) %define pear_testdir %(%{__pear} config-get test_dir 2> /dev/null || echo undefined) %define pear_testdir %(%{__pear} config-get data_dir 2> /dev/null || echo undefined) %define pear_xmldir %{pear_phpdir}/.pkgxml %define pecl_phpdir %(%{__pecl} config-get php_dir 2> /dev/null || echo undefined) %define pecl_docdir %(%{__pecl} config-get doc_dir 2> /dev/null || echo undefined) %define pecl_testdir %(%{__pecl} config-get test_dir 2> /dev/null || echo undefined) %define pecl_testdir %(%{__pecl} config-get data_dir 2> /dev/null || echo undefined) %define pecl_xmldir %{pecl_phpdir}/.pkgxml From chris.stone at gmail.com Wed Jul 5 00:22:30 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 4 Jul 2006 17:22:30 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: On 7/4/06, Christopher Stone wrote: > %define pear_testdir %(%{__pear} config-get test_dir 2> /dev/null || > echo undefined) > %define pear_testdir %(%{__pear} config-get data_dir 2> /dev/null || > echo undefined) Just noticed that the 2nd one should be data_dir. I have updated my spec file: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec So that it no longer defines these macros (spec file is starting to look pretty simple now) I can put the macros back, but updating the php-pear package should be easy if that is a possibility. From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 5 06:19:06 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Jul 2006 08:19:06 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Jason L. Tibbitts, III's message of "Tue, 04 Jul 2006 13:16:47 -0500") References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: <87irmc4lr9.fsf@kosh.bigo.ensc.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: > I agree that it might be nice, but I don't think it reasonable to wait > for Red Hat to push an RPM update before we can get guidelines out. > We could consider recommending: > > %{!?__php: %define __php /usr/bin/php} > %{!?__pear: %define __pear /usr/bin/pear} > %{!?__pecl: %define __pecl /usr/bin/pecl} Please use '%global' but not '%define' for such macros which might be added to official guidelines. %define in such expressions is broken : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147238 Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 5 08:47:55 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Jul 2006 10:47:55 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Tue, 4 Jul 2006 11:45:31 -0700") References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: <87u05wtp38.fsf@fc5.bigo.ensc.de> chris.stone at gmail.com ("Christopher Stone") writes: > Packages which are .php files only such as php-Smarty or php-pear-Foo > need only require php >= version they say they require, or if they do > not say, then php >= current version (or no version) should be fine. > I have some php-pear packages which specifically indicate they need > php >= 4.2.0 some that say they need php >= 4.3.0. Such Requires: do not make sense nowadays. The ability to require a special program version was removed some time ago from rpm. Now, you can require a special package version only and every PHP in the supported Fedora Extras branches fulfills the requirements. Since packaging guidelines are tending to minimize the explicitly written (Build)Requires:, such unneeded versions should be removed too. Enrico From ville.skytta at iki.fi Wed Jul 5 17:11:37 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 05 Jul 2006 20:11:37 +0300 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1152030596.16687.2.camel@localhost.localdomain> <44AAE9DF.2080704@timj.co.uk> <44AAEF91.3070102@timj.co.uk> Message-ID: <1152119497.2728.112.camel@localhost.localdomain> On Tue, 2006-07-04 at 16:00 -0700, Christopher Stone wrote: > On 7/4/06, Tim Jackson wrote: > > > > I'm not sure what difference it makes whether they are rm'd or excluded. > > They certainly don't want to be %ghost. > > I'll change the spec to %exclude and then we can just remove that once > upstream fixes pear/pecl commands from generating those files. Using "rm -f" in %install is more flexible than %exclude because it doesn't actually require those files to be present; it would work both now and in the future thus possibly avoiding some specfile forks between distro versions, and would avoid the issue (well, probably a non-issue in this particular case) with %exclude and rpm size calculations: https://bugzilla.redhat.com/89661 From tibbs at math.uh.edu Wed Jul 5 17:31:51 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 05 Jul 2006 12:31:51 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87u05wtp38.fsf@fc5.bigo.ensc.de> (Enrico Scholz's message of "Wed, 05 Jul 2006 10:47:55 +0200") References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> Such Requires: do not make sense nowadays. The ability to require ES> a special program version was removed some time ago from rpm. Unfortunately I can't quite parse what Enrico has written here; it looks like that statement indicates that versioned requirements don't work in RPM, which I don't think is the case. Enrico, could you (or anyone else who understands the issue) elaborate a bit? - J< From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 5 18:09:22 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Jul 2006 20:09:22 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Jason L. Tibbitts, III's message of "Wed, 05 Jul 2006 12:31:51 -0500") References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> Message-ID: <87u05vx6st.fsf@kosh.bigo.ensc.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: > ES> Such Requires: do not make sense nowadays. The ability to require > ES> a special program version was removed some time ago from rpm. > > Unfortunately I can't quite parse what Enrico has written here; it > looks like that statement indicates that versioned requirements don't > work in RPM, which I don't think is the case. > > Enrico, could you (or anyone else who understands the issue) elaborate > a bit? Some years ago, you could write | Requires: foo > 2.1 which would be fulfilled by foo=0:2.1 but not by foo=42:1.0. Then, rpm was changed to interprete the statement above as | Requires: foo > 0:2.1 So, program version 1.0 packaged with an epoch of '42' would be allowed. Therefore, versioned requirements make sense in a special environment only where you exactly know possible EVR values. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From chris.stone at gmail.com Wed Jul 5 18:19:04 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 11:19:04 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87u05vx6st.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> Message-ID: On 7/5/06, Enrico Scholz wrote: > tibbs at math.uh.edu (Jason L Tibbitts III) writes: > > > ES> Such Requires: do not make sense nowadays. The ability to require > > ES> a special program version was removed some time ago from rpm. > > > > Unfortunately I can't quite parse what Enrico has written here; it > > looks like that statement indicates that versioned requirements don't > > work in RPM, which I don't think is the case. > > > > Enrico, could you (or anyone else who understands the issue) elaborate > > a bit? > > Some years ago, you could write > > | Requires: foo > 2.1 > > which would be fulfilled by foo=0:2.1 but not by foo=42:1.0. > > > Then, rpm was changed to interprete the statement above as > > | Requires: foo > 0:2.1 > > So, program version 1.0 packaged with an epoch of '42' would be allowed. > > Therefore, versioned requirements make sense in a special environment > only where you exactly know possible EVR values. Okay, now I'm _really_ confused. So you are saying rpm can handle epochs properly now? That's great, so why should we remove version requirements from our spec files now that rpm properly handles epochs? From rdieter at math.unl.edu Wed Jul 5 18:22:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Jul 2006 13:22:49 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> Message-ID: <44AC0379.9050305@math.unl.edu> Christopher Stone wrote: > rpm can handle epochs properly now? Yes. > That's great, so why should we remove version > requirements from our spec files now that rpm properly handles epochs? IMO, you shouldn't. -- Rex From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 5 18:39:39 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Jul 2006 20:39:39 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Wed, 5 Jul 2006 11:19:04 -0700") References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> Message-ID: <87psgjx5ec.fsf@kosh.bigo.ensc.de> chris.stone at gmail.com ("Christopher Stone") writes: >> > ES> Such Requires: do not make sense nowadays. The ability to require >> > ES> a special program version was removed some time ago from rpm. >> > >> > Unfortunately I can't quite parse what Enrico has written here; it >> > looks like that statement indicates that versioned requirements don't >> > work in RPM, which I don't think is the case. >> > >> > Enrico, could you (or anyone else who understands the issue) elaborate >> > a bit? >> ... > Okay, now I'm _really_ confused. So you are saying rpm can handle > epochs properly now? No > That's great, so why should we remove version requirements from our > spec files now that rpm properly handles epochs? Ok; a more realistic example: you have an application for Fedora Extras which requires bind, version 9.3 or later. What would you write? a) Requires: bind >= 9.3? b) Requires: bind >= 24:9.3? When your answer is a): this requirement would be fulfilled by FE3 with its bind 9.2.1 too, so this answer would be wrong. When your answer is b): what would you gain with it? Epochs are a per-environment thing and not bound to program versions. E.g. SuSE or Mandriva might have bind-1:9.4 packages. Because the Fedora Extras packages are for a specific environment (FE4, FE5, devel) only, you can be sure that the needed program versions are available there and the explicit version is not needed. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From chris.stone at gmail.com Wed Jul 5 18:53:40 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 11:53:40 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87psgjx5ec.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> Message-ID: On 7/5/06, Enrico Scholz wrote: > Ok; a more realistic example: you have an application for Fedora > Extras which requires bind, version 9.3 or later. What would you > write? > > a) Requires: bind >= 9.3? > b) Requires: bind >= 24:9.3? > > When your answer is a): this requirement would be fulfilled by FE3 with > its bind 9.2.1 too, so this answer would be wrong. > > When your answer is b): what would you gain with it? Epochs are a > per-environment thing and not bound to program versions. E.g. SuSE or > Mandriva might have bind-1:9.4 packages. Because the Fedora Extras > packages are for a specific environment (FE4, FE5, devel) only, you > can be sure that the needed program versions are available there and > the explicit version is not needed. The answer is a. If it doesn't work on FE3 then I would be surprised, and it should be fixed by the legacy team for FE3. Why would you ever use b? I think you might be confused on the versioning, you do realize that a version of 9:3 is different than a version of 9.3 correct? From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 5 19:04:19 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Jul 2006 21:04:19 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Wed, 5 Jul 2006 11:53:40 -0700") References: <20060630095230.GA19767@redhat.com> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> Message-ID: <87irmbx498.fsf@kosh.bigo.ensc.de> chris.stone at gmail.com ("Christopher Stone") writes: > On 7/5/06, Enrico Scholz wrote: >> Ok; a more realistic example: you have an application for Fedora >> Extras which requires bind, version 9.3 or later. What would you >> write? >> >> a) Requires: bind >= 9.3? >> >> When your answer is a): this requirement would be fulfilled by FE3 with >> its bind 9.2.1 too, so this answer would be wrong. > ... > The answer is a. If it doesn't work on FE3 then I would be surprised, > and it should be fixed by the legacy team for FE3. This application can not work in FE3 because it requires bind, version 9.3 but FE3 has 9.2.4 only (the 9.2.1 above was wrong; sorry). With current rpm you can express package (but not version) dependencies only. Therefore, the Requires: above would be fulfilled in FE3 because it has bind-20:9.2.4 which is newer than bind-9.3 (which will be interpreted as bind-0:9.3 nowadays). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From chris.stone at gmail.com Wed Jul 5 19:10:46 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 12:10:46 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87irmbx498.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <87irmbx498.fsf@kosh.bigo.ensc.de> Message-ID: On 7/5/06, Enrico Scholz wrote: > With current rpm you can express package (but not version) dependencies > only. Therefore, the Requires: above would be fulfilled in FE3 because it > has bind-20:9.2.4 which is newer than bind-9.3 (which will be interpreted > as bind-0:9.3 nowadays). This must be a special case because packages are not meant to go from a higher epoch to a lower one. We should not change every single spec file just because one package does things incorrectly so we can support a deprecated distro. From paul at city-fan.org Wed Jul 5 19:11:16 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 05 Jul 2006 20:11:16 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> Message-ID: <1152126677.4164.4.camel@laurel.intra.city-fan.org> On Wed, 2006-07-05 at 11:53 -0700, Christopher Stone wrote: > On 7/5/06, Enrico Scholz wrote: > > Ok; a more realistic example: you have an application for Fedora > > Extras which requires bind, version 9.3 or later. What would you > > write? > > > > a) Requires: bind >= 9.3? > > b) Requires: bind >= 24:9.3? > > > > When your answer is a): this requirement would be fulfilled by FE3 with > > its bind 9.2.1 too, so this answer would be wrong. > > > > When your answer is b): what would you gain with it? Epochs are a > > per-environment thing and not bound to program versions. E.g. SuSE or > > Mandriva might have bind-1:9.4 packages. Because the Fedora Extras > > packages are for a specific environment (FE4, FE5, devel) only, you > > can be sure that the needed program versions are available there and > > the explicit version is not needed. > > The answer is a. If it doesn't work on FE3 then I would be surprised, > and it should be fixed by the legacy team for FE3. Supposing the latest FC3 bind package is 20:9.2.4 (I'll trust Enrico on that). To the best of my knowledge there is no security or serious bug in that version and therefore nothing for the Legacy team to concern themselves with. As far as rpm is concerned, version 20:9.2.4 is newer than version 9.3 (i.e. 0:9.3) and hence would satisfy a dependency of: Requires: bind >= 9.3 However, the pacakge using this would not build/work because it actually requires version 9.3 or later, which version 9.2.4 is not. > Why would you ever use b? To make sure that the problem just described did not happen. > I think you might be confused on the > versioning, you do realize that a version of 9:3 is different than a > version of 9.3 correct? Who said anything about 9:3? Paul. From paul at city-fan.org Wed Jul 5 19:19:14 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 05 Jul 2006 20:19:14 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <87irmbx498.fsf@kosh.bigo.ensc.de> Message-ID: <1152127155.4164.7.camel@laurel.intra.city-fan.org> On Wed, 2006-07-05 at 12:10 -0700, Christopher Stone wrote: > On 7/5/06, Enrico Scholz wrote: > > With current rpm you can express package (but not version) dependencies > > only. Therefore, the Requires: above would be fulfilled in FE3 because it > > has bind-20:9.2.4 which is newer than bind-9.3 (which will be interpreted > > as bind-0:9.3 nowadays). > > This must be a special case because packages are not meant to go from > a higher epoch to a lower one. We should not change every single spec > file just because one package does things incorrectly so we can > support a deprecated distro. The only thing done incorrectly was having the: Requires: bind >= 9.3 which, as Enrico said, was meaningless due to bind's use of epochs. The bind package itself has used epochs in the correct ascending order and has not done things incorrectly (other than use epochs at all, one might say). Paul. From chris.stone at gmail.com Wed Jul 5 19:28:05 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 12:28:05 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152127155.4164.7.camel@laurel.intra.city-fan.org> References: <20060630095230.GA19767@redhat.com> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <87irmbx498.fsf@kosh.bigo.ensc.de> <1152127155.4164.7.camel@laurel.intra.city-fan.org> Message-ID: On 7/5/06, Paul Howarth wrote: > On Wed, 2006-07-05 at 12:10 -0700, Christopher Stone wrote: > > On 7/5/06, Enrico Scholz wrote: > > > With current rpm you can express package (but not version) dependencies > > > only. Therefore, the Requires: above would be fulfilled in FE3 because it > > > has bind-20:9.2.4 which is newer than bind-9.3 (which will be interpreted > > > as bind-0:9.3 nowadays). > > > > This must be a special case because packages are not meant to go from > > a higher epoch to a lower one. We should not change every single spec > > file just because one package does things incorrectly so we can > > support a deprecated distro. > > The only thing done incorrectly was having the: > > Requires: bind >= 9.3 > > which, as Enrico said, was meaningless due to bind's use of epochs. > > The bind package itself has used epochs in the correct ascending order > and has not done things incorrectly (other than use epochs at all, one > might say). oops I'm sorry, bind uses an epoch of 30 for FE5 these days, Enrico said it used an epoch of 0 today (or that is how I intrepreted his message). So I am not really sure with how bind versioning numbers work and why it's epoch is increased so much, but for a Fedora package you should specify the epoch with bind to ensure the proper version. If you want to make your spec file work with other distros you would have to do something like: %if 0%{?suse_version} Requires: bind >= 0:9.3 (or whatever epoch suse uses) %else Requires: bind >= 30:9.3 %endif From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 5 19:43:41 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Jul 2006 21:43:41 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Wed, 5 Jul 2006 12:28:05 -0700") References: <20060630095230.GA19767@redhat.com> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <87irmbx498.fsf@kosh.bigo.ensc.de> <1152127155.4164.7.camel@laurel.intra.city-fan.org> Message-ID: <87ejwzx2fm.fsf@kosh.bigo.ensc.de> chris.stone at gmail.com ("Christopher Stone") writes: > oops I'm sorry, bind uses an epoch of 30 for FE5 these days, Enrico > said it used an epoch of 0 today (or that is how I intrepreted his > message). Complete posting/subthread was about the | Requires: bind >= 9.3 I never said that the bind-30:9.3.2-20 package from FC5 would be interpreted as an epoch 0. 'Today' means current rpm; previous rpm version tried to add an implicit epoch when an epoch'ed and a non-epoch'ed package were compared. With previous rpm versions, the 'Requires:' above would be _read_ as | Requires: bind >= [30:]9.3 when _compared_ with bind-30:9.3.2-20 or as | Requires: bind >= [20:]9.2.4 when _compared_ with bind-20:9.2.4-2. But this implementation was buggy and stored the implicit epoch in the rpm database when package was updated (afair) which was causing lot of problems. Algorithm was replaced by a missing-epoch == epoch-0 assumption. > Requires: bind >= 30:9.3 ok; now we are back at >>>>>> b) Requires: bind >= 24:9.3? >>>>>> ... >>>>>> When your answer is b): what would you gain with it?... Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Jul 5 19:47:20 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 05 Jul 2006 22:47:20 +0300 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87psgjx5ec.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> Message-ID: <1152128840.2728.177.camel@localhost.localdomain> On Wed, 2006-07-05 at 20:39 +0200, Enrico Scholz wrote: > Because the Fedora Extras > packages are for a specific environment (FE4, FE5, devel) only, you > can be sure that the needed program versions are available there and > the explicit version is not needed. And because the intended environment is known, we'd know what Epochs to use. The way I look at it, versioned dependencies still have some nice to have uses, in no particular order (and not implying that support for these cases should be mandated): - They serve as a favour to those who try to rebuild and then use such packages on earlier distro versions than what they're shipped for or maintained in FE. For example, although I stick with FC5 at the moment, I have cherry picked and rebuilt a few things locally from Rawhide and FE devel, which is helpful when maintaining and testing my packages in devel. Another example would be people who are stuck with an old FC version but would like to locally rebuild something which is available only in newer FE branches. - Ditto to those who do that on sufficiently compatible (as in derivative/"sister" distros) such as RHEL and friends, Aurora etc. - Package versions in FC do get upgraded during the lifetime of a version, and some package may require a version of something that was not sufficiently new in the baseline FC install media but is only available in updates for that version. Although in practice the window may be small and there may be other problems with doing it, omitting the version can bite people who upgrade from an earlier distro version to the baseline of the newer one (eg. using install media) instead of going straight to baseline+updates. From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 5 20:09:53 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Jul 2006 22:09:53 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152128840.2728.177.camel@localhost.localdomain> (Ville Skytt's message of "Wed, 05 Jul 2006 22:47:20 +0300") References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> Message-ID: <87ac7nx17y.fsf@kosh.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> Because the Fedora Extras packages are for a specific environment >> (FE4, FE5, devel) only, you can be sure that the needed program >> versions are available there and the explicit version is not needed. > > And because the intended environment is known, we'd know what Epochs to > use. The way I look at it, versioned dependencies still have some nice > to have uses, in no particular order (and not implying that support for > these cases should be mandated): * there are already complains about redundant dependencies when | BuildRequires: A-devel B-devel is used and an A-devel -> B-devel chain exists (most of your arguments apply to this situation too). Why should redundant information like | Requires: C >= EVR handled in another way? * I do not say that versioned dependency shall be forbidden; they just do not make sense and I am against a rule like | I have some php-pear packages which specifically indicate they need | php >= 4.2.0 some that say they need php >= 4.3.0. If these versions | are specified by the package, they should be indicated in the spec | file (IMO). which was requested in the first posting replied by me. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Jul 5 21:15:26 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 06 Jul 2006 00:15:26 +0300 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87ac7nx17y.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> Message-ID: <1152134126.2728.216.camel@localhost.localdomain> On Wed, 2006-07-05 at 22:09 +0200, Enrico Scholz wrote: > * there are already complains about redundant dependencies when > | BuildRequires: A-devel B-devel > is used and an A-devel -> B-devel chain exists Getting a bit off topic, but if they're *really* redundant, there's nothing wrong with such complaints. However, in some cases, the complaints are not much more than fragile and more or less misinformed attempts to optimize/minimize things written specfiles. When both A-devel and B-devel are directly and independently used, there's nothing wrong with explicitly requiring both, no matter if a dep chain exists between them or not. However, if a direct dependency on B-devel is inflicted some way by A-devel and the thing to be built wouldn't "naturally" need B-devel otherwise, it can be argued that an explicit dependency on B-devel is subject to bitrot and would be better left out if BR: A-devel is there and A-devel pulls in B-devel. > Why should redundant information like > | Requires: C >= EVR Mileages vary whether the version is redundant or not. The worst thing that can happen is that it becomes outdated and thus useless if the packager doesn't bother to track it. But when kept up to date, it will help in cases such as those from my previous mail. > * I do not say that versioned dependency shall be forbidden; they just > do not make sense and I am against a rule like > > | I have some php-pear packages which specifically indicate they need > | php >= 4.2.0 some that say they need php >= 4.3.0. If these versions > | are specified by the package, they should be indicated in the spec > | file (IMO). I tend to agree with the original poster. From tibbs at math.uh.edu Wed Jul 5 21:24:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 05 Jul 2006 16:24:47 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87ac7nx17y.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Wed, 05 Jul 2006 22:09:53 +0200") References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> * I do not say that versioned dependency shall be forbidden; they ES> just do not make sense and I am against a rule like This makes no sense to me. So if Red Hat bumps the FC5 PHP from 5.1.4 to 5.1.5 to fix some bug and a package requires that fixed version, what is it supposed to require? How else do you express a dependency on a a particular version other than through a versioned dependency? - J< From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 5 21:25:57 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Jul 2006 23:25:57 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152134126.2728.216.camel@localhost.localdomain> (Ville Skytt's message of "Thu, 06 Jul 2006 00:15:26 +0300") References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152134126.2728.216.camel@localhost.localdomain> Message-ID: <873bdfwxp6.fsf@kosh.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> Why should redundant information like >> | Requires: C >= EVR > > Mileages vary whether the version is redundant or not. No; when you submit a package for FE with | Requires: php >= 4.2.0 then the '>= 4.2.0' is redundant because every FE has a php >= 4.2.0 and | Requires: php suffices there. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tibbs at math.uh.edu Wed Jul 5 21:33:14 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 05 Jul 2006 16:33:14 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <873bdfwxp6.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Wed, 05 Jul 2006 23:25:57 +0200") References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152134126.2728.216.camel@localhost.localdomain> <873bdfwxp6.fsf@kosh.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> then the '>= 4.2.0' is redundant because every FE has a php >= ES> 4.2.0 and Now that I can understand, but I don't think it's reasonable for package submitters and reviewers to know the full version history of package in Core and Extras. We have to do this on occasion with Perl package dependencies because you will have to filter out the unversioned dependency RPM will find if you want to include a versioned one, and it's always a pain. I think it reasonable to say that the version is optional if it would always be satisfied in any of the targeted Fedora releases. - J< From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 5 21:41:29 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Jul 2006 23:41:29 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Jason L. Tibbitts, III's message of "Wed, 05 Jul 2006 16:24:47 -0500") References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> Message-ID: <87y7v7vieu.fsf@kosh.bigo.ensc.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: > ES> * I do not say that versioned dependency shall be forbidden; they > ES> just do not make sense and I am against a rule like > | If these versions are specified by the package, they should be > | indicated in the spec file (IMO). > > This makes no sense to me. So if Red Hat bumps the FC5 PHP from 5.1.4 > to 5.1.5 to fix some bug and a package requires that fixed version, > what is it supposed to require? In this case you you will have to use a versioned dependency but this is different from "specified by the package". E.g. when php-5.1.4-1 has a bug which will be fixed by a patch (which fixes only this issue without a full version upgrade) you have to write | Requires: php >= 5.1.4-2 and can not follow README which says that 5.1.5 will be required. The version in the Requires: depends on the environment but not on the requirement told by the (upstream) package. In the discussed case, the version in "php >= 4.2.0" is redundant in FE environments and except for 3rd party repository-support there is no reason to use it resp. to enforce it. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Jul 5 22:31:07 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 06 Jul 2006 00:31:07 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87ac7nx17y.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> Message-ID: <1152138667.5277.50.camel@rousalka.dyndns.org> Le mercredi 05 juillet 2006 ? 22:09 +0200, Enrico Scholz a ?crit : > ville.skytta at iki.fi (Ville Skytt?) writes: > > >> Because the Fedora Extras packages are for a specific environment > >> (FE4, FE5, devel) only, you can be sure that the needed program > >> versions are available there and the explicit version is not needed. This is totally wrong. When you package for FCx, and one of your deps got a major version bump in FCx updates, what do you target ? FCx as it was released of FCx after all updates are applied ? How do you tell the package manager when your package is safe to use ? (this is actually worse for 3rd party repositories which target 5-years-long RHEL) Also note that since the project allows parallel updates in all FE releases (instead of freezing everything but devel),depending on the yum invocation order people will have vastly different package versions on their systems (within a single FE release). Not dangerous for people who do daily broadband pulls. But deadly for systems only used every few/weeks, and synced every few months (think computer at your grandma or vacation house, small server only updated when there is a problem, etc) Unversionned deps, when you know at which version boundary your package breaks, is just playing with fire. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 6 05:41:23 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 06 Jul 2006 07:41:23 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152138667.5277.50.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Thu, 06 Jul 2006 00:31:07 +0200") References: <20060630095230.GA19767@redhat.com> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> Message-ID: <87u05vuw70.fsf@kosh.bigo.ensc.de> nicolas.mailhot at laposte.net (Nicolas Mailhot) writes: >> >> Because the Fedora Extras packages are for a specific environment >> >> (FE4, FE5, devel) only, you can be sure that the needed program >> >> versions are available there and the explicit version is not >> >> needed. > > This is totally wrong. > > When you package for FCx, and one of your deps got a major version bump > in FCx updates, major version bumps are impossible for most packages because it would destroy API compatibility. When you really *need* a certain *package* version, then you can add a versioned dependeny. But this version should not be related to something written in a README but to the current environment. Versioned dependencies should be checked after some time (1 year for FE) whether it become redundant in the meantime and be removed if so. > Unversionned deps, when you know at which version boundary your package > breaks, is just playing with fire. It is stupid and in most times redundant to add blindly a versioned dependency just because a README tells that a certain version is required. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From chris.stone at gmail.com Thu Jul 6 06:15:13 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 23:15:13 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87u05vuw70.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> Message-ID: On 7/5/06, Enrico Scholz wrote: > It is stupid and in most times redundant to add blindly a versioned > dependency just because a README tells that a certain version is > required. pear packages adhere to very strict standards and versioning requirements is part of that. All pear packages are very specific about versioning requirements. There is even a built in option in the pear command to list out these requirements which will probably be used by the php-pear-PEAR-Command-Packaging package. Please do not ask me to lower the quality standards that pear packages expect by not providing this information in my spec files. From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 6 06:50:01 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 06 Jul 2006 08:50:01 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Wed, 5 Jul 2006 23:15:13 -0700") References: <20060630095230.GA19767@redhat.com> <87u05wtp38.fsf@fc5.bigo.ensc.de> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> Message-ID: <87psgjut0m.fsf@kosh.bigo.ensc.de> chris.stone at gmail.com ("Christopher Stone") writes: >> It is stupid and in most times redundant to add blindly a versioned >> dependency just because a README tells that a certain version is >> required. > > pear packages adhere to very strict standards and versioning > requirements is part of that. All pear packages are very specific > about versioning requirements. Again: rpm does not allow to require a certain program (PHP) version; you can require a certain package version only. And btw; packaging guidelines are handling this case already: | First, if the lowest possible requirement is so old that nobody has a | version older than that installed on any target distribution release, | there's no need to include the version in the dependency at all. | ... | As a rule of thumb, if the version is not required, don't add it just | for fun. [http://fedoraproject.org/wiki/Packaging/Guidelines] > Please do not ask me to lower the quality standards that pear packages > expect by not providing this information in my spec files. You are not lowering quality standards when unneeded and non-working things like "Requires: php >= 4.2" will be omitted. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From chris.stone at gmail.com Thu Jul 6 06:58:23 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 23:58:23 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87psgjut0m.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> Message-ID: On 7/5/06, Enrico Scholz wrote: > chris.stone at gmail.com ("Christopher Stone") writes: > > >> It is stupid and in most times redundant to add blindly a versioned > >> dependency just because a README tells that a certain version is > >> required. > > > > pear packages adhere to very strict standards and versioning > > requirements is part of that. All pear packages are very specific > > about versioning requirements. > > Again: rpm does not allow to require a certain program (PHP) version; > you can require a certain package version only. > > And btw; packaging guidelines are handling this case already: > > | First, if the lowest possible requirement is so old that nobody has a > | version older than that installed on any target distribution release, > | there's no need to include the version in the dependency at all. > | ... > | As a rule of thumb, if the version is not required, don't add it just > | for fun. > [http://fedoraproject.org/wiki/Packaging/Guidelines] > > > > Please do not ask me to lower the quality standards that pear packages > > expect by not providing this information in my spec files. > > You are not lowering quality standards when unneeded and non-working > things like "Requires: php >= 4.2" will be omitted. Unneeded? by whom? Fedora's rpm? other package maintainers for other distributions? Some poor sap who built his OS from scratch who is trying to determine what he needs installed for your package? Somone who only wants to upgrade your package and not their whole system? Oh I forgot, version dependencies dont work on Fedora (LOL). We are not adding this information because it's fun, and we are not adding requirements for packages that are so old nobody will have them installed. Can we please close this silly discussion or does anyone here actually agree with Enrico? From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 6 07:21:56 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 06 Jul 2006 09:21:56 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Wed, 5 Jul 2006 23:58:23 -0700") References: <20060630095230.GA19767@redhat.com> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> Message-ID: <87fyhf6vvv.fsf@fc5.bigo.ensc.de> chris.stone at gmail.com ("Christopher Stone") writes: >> You are not lowering quality standards when unneeded and non-working >> things like "Requires: php >= 4.2" will be omitted. > > Unneeded? by whom? This list contains a 'To: fedora-packaging at redhat.com' so I would say Fedora Extras. > Fedora's rpm? yes > other package maintainers for other distributions? dunno; they are not handled by this list. Enrico From chris.stone at gmail.com Thu Jul 6 07:31:46 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 00:31:46 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87fyhf6vvv.fsf@fc5.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <87fyhf6vvv.fsf@fc5.bigo.ensc.de> Message-ID: On 7/6/06, Enrico Scholz wrote: > chris.stone at gmail.com ("Christopher Stone") writes: > > >> You are not lowering quality standards when unneeded and non-working > >> things like "Requires: php >= 4.2" will be omitted. > > > > Unneeded? by whom? > > This list contains a 'To: fedora-packaging at redhat.com' so I would say > Fedora Extras. > > > Fedora's rpm? > > yes > > > > other package maintainers for other distributions? > > dunno; they are not handled by this list. So we are to just assume everyone will be running a stock Fedora system then? In my opinion I think it is better to provide the information if it is accurate and available as it is with pear packages. I don't have the powerz to decide these things but if we must take a vote on this issue then I will go with whatever the packaging comitte decides. From chris.stone at gmail.com Thu Jul 6 08:07:19 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 01:07:19 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <87fyhf6vvv.fsf@fc5.bigo.ensc.de> Message-ID: PHP Packaging Guidelines summary: I have updated my template spec file: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec -Readded the rm dot files and removed the %exclude -Removed the default group since this is unclear/undecided at best so I guess it is up to the packager to decide -Removed the "PEAR:" from the summary line (I don't think we should require all pear packages to put "PEAR:" in the summary) if anyone disagrees I can add it back because im not too partial either way. Questions: Is using Requires(post): %{__pear} okay, or do i have to explicitly say /usr/bin/pear? What still needs to be resolved: -Version dependencies on other pear packages, and php core packages, should it be required as a "must" item, "should" item, or not mentioned and/or discouraged? -The php-pear spec file needs to be modified to drop in appropriate macros for pear and pecl (can a new release of php-pear with this added be done quickly?) -Update the php spec file to drop in macros for php_api and /usr/bin/php (also can this be done quickly?) -Decide how many different Provides variations we want to provide. -Provide a /usr/share/php/ directory which is owned by the php package or something for packages like php-Smarty. Upstream issues: - generating dot files and installing xml files should probably be done automagically by the pear/pecl commands when using --packagingroot. These are not critical to our passing guidelines. - the pecl command doesn't work with --packagingroot or --register-only, we need to identify bugs and report them to upstream to be fixed. This is critical to the pecl guidelines if we want them to use the (almost) identical spec as the pear packages. There are other ways we can build pecl packages so we have to decide if we want to package pecl packages differently for now until upstream fixes these bugs. I *think* this is all the remaining open issues, please let me know if I have missed something. I think with a little effort from the php and php-pear maintainers, and some quick final decisions from the packaging comittee, we can get guidelines ready for atleast the php-* and php-pear-* packages and have a php-pear template in use. php-pecl-* packages still need a default template which depends on upstream bug fix issues. From rc040203 at freenet.de Thu Jul 6 08:15:28 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 06 Jul 2006 10:15:28 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <87fyhf6vvv.fsf@fc5.bigo.ensc.de> Message-ID: <1152173728.5770.39.camel@mccallum.corsepiu.local> On Thu, 2006-07-06 at 01:07 -0700, Christopher Stone wrote: > PHP Packaging Guidelines summary: > > I have updated my template spec file: > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec > > -Readded the rm dot files and removed the %exclude > -Removed the default group since this is unclear/undecided at best so > I guess it is up to the packager to decide > -Removed the "PEAR:" from the summary line (I don't think we should > require all pear packages to put "PEAR:" in the summary) if anyone > disagrees I can add it back because im not too partial either way. > > Questions: > Is using Requires(post): %{__pear} okay, or do i have to explicitly > say /usr/bin/pear? IMO: If %{__pear} is _guaranteed_ to be provided and if it expands to a binary containing an absolute path, yes, this would be fine. One of these conditions can not be assured, then no, %{__pear} would not be OK. Ralf From chris.stone at gmail.com Thu Jul 6 09:07:13 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 02:07:13 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152173728.5770.39.camel@mccallum.corsepiu.local> References: <20060630095230.GA19767@redhat.com> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <87fyhf6vvv.fsf@fc5.bigo.ensc.de> <1152173728.5770.39.camel@mccallum.corsepiu.local> Message-ID: On 7/6/06, Ralf Corsepius wrote: > On Thu, 2006-07-06 at 01:07 -0700, Christopher Stone wrote: > > Questions: > > Is using Requires(post): %{__pear} okay, or do i have to explicitly > > say /usr/bin/pear? > IMO: > > If %{__pear} is _guaranteed_ to be provided and if it expands to a > binary containing an absolute path, yes, this would be fine. > > One of these conditions can not be assured, then no, %{__pear} would not > be OK. So are you saying the %{__pear} macro must be provided by rpm in order for me to safely use this macro in the Requires line? If the macro is provided by php-pear by adding an /etc/rpm/macros.pear file, will this be okay when building with mock? From toshio at tiki-lounge.com Thu Jul 6 15:13:36 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 06 Jul 2006 08:13:36 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <87u05vx6st.fsf@kosh.bigo.ensc.de> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> Message-ID: <1152198817.24961.194.camel@localhost> On Wed, 2006-07-05 at 23:58 -0700, Christopher Stone wrote: > On 7/5/06, Enrico Scholz wrote: > > Again: rpm does not allow to require a certain program (PHP) version; > > you can require a certain package version only. > > > > And btw; packaging guidelines are handling this case already: > > > > | First, if the lowest possible requirement is so old that nobody has a > > | version older than that installed on any target distribution release, > > | there's no need to include the version in the dependency at all. > > | ... > > | As a rule of thumb, if the version is not required, don't add it just > > | for fun. > > [http://fedoraproject.org/wiki/Packaging/Guidelines] > > > > > > > Please do not ask me to lower the quality standards that pear packages > > > expect by not providing this information in my spec files. > > > > You are not lowering quality standards when unneeded and non-working > > things like "Requires: php >= 4.2" will be omitted. > > Unneeded? by whom? Fedora's rpm? other package maintainers for other > distributions? Some poor sap who built his OS from scratch who is > trying to determine what he needs installed for your package? Somone > who only wants to upgrade your package and not their whole system? > > Oh I forgot, version dependencies dont work on Fedora (LOL). > No. Version dependencies don't work as you're expecting in current rpm. > We are not adding this information because it's fun, and we are not > adding requirements for packages that are so old nobody will have them > installed. > You are adding requirements for package versions which are not relevant for Fedora, which is what the guidelines are saying should be avoided. > Can we please close this silly discussion or does anyone here actually > agree with Enrico? Enrico has the following points: 1) rpm's handling of Epochs means that versioned dependencies reference package versions, not upstream versions. Because of this, including the version in the rpm when it is unnecessary for all the distributions we are supporting is misleading and potentially hurts packagers on other distributions. 2) Using a versioned dependency pulled verbatim from a README file ignores the patches applied by the Fedora maintainer to the base package. If the README says "Requires php >= 5.0.1 because of a bug in earlier versions" but the Fedora maintainer has backported fixes to these bugs for the 5.0-4 package, then using a naive versioned dependency of Requires: php >= 5.0.1 is wrong. 3) The packaging guidelines already state when it is appropriate to include versioned dependencies and this is not one of them. This means we're deciding whether to make an exception for php/pear packages rather than making new policy. The point you seem to be making is that PEAR packages include a lot of information about the versions of upstream releases that are required. You'd like to include this in the spec file to help other packagers use this outside of Fedora. Currently, I'd be disinclined to make an exception for php/pear packages. That could change depending on how compelling the answers to the following two questions are: Since PEAR packages provide this dependency information, why should we include it in the spec file? Enrico's points 1 & 2 mean that adding version information unnecessarily can mislead foreign packagers rather than help them. Why do you think those points don't apply to PEAR packages? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Thu Jul 6 20:02:48 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 6 Jul 2006 22:02:48 +0200 Subject: [Fedora-packaging] PackagingDrafts/DisttagsForRawHide (was: fc5.90/fc5.91/... disttags and automated rebuilds (was: Mass rebuild of Extras packages for FC6?)) In-Reply-To: <20060701113429.GA20490@neu.nirvana> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> <44A64DB2.2080505@leemhuis.info> <20060701113429.GA20490@neu.nirvana> Message-ID: <20060706200248.GE4210@neu.nirvana> Hi, I summarized the pros and cons of using disttags in rawhide matching to rawhide's internal version in here: http://www.fedoraproject.org/wiki/PackagingDrafts/DisttagsForRawHide I've added Jesse's and Jason's reservations, too. On Sat, Jul 01, 2006 at 01:34:29PM +0200, Axel Thimm wrote: > On Sat, Jul 01, 2006 at 12:25:54PM +0200, Thorsten Leemhuis wrote: > > I suppose a lot of people won't like the topic I'll bring up with this > > mail but we IMHO should discuss this nevertheless. > > > > Jesse Keating schrieb: > > > I've been requested to rebuild every Core package for a few reasons. > > > > > > 1) rpm signing w/ sha256sum > > > 2) New toolset feature to speed up dynamic lib linking by 50%~ > > > 3) get all packages built through new build system (brew) > > > > Change the last point to > > > > 3) get all packages build with the new and reduced set of packages > > installed in the default mock buildroot > > All the above three could be automated for packages using %{?dist}, if > the disttag would propagate in fedora time as well. E.g. the internal > release version of FC6test1 is 5.90, if the disttag was matched to > this, we would have automated rebuilds for each test release and for > the final release as well w/o anyone having to do anything about it > (sparing bugs of course). > > If rebuilds are needed more often (because gcc was upgraded in > between) then disttags could look like 5.90.1 to indicate a rebuild > between test1 and test2. Before test1 rawhide had the version 5.89, so > we're covered in that area, too. > > If we're going to mass-rebuilt (and therefore touch each specfile), > could we consider using such disttags for rawhide/test releases from > now on? E.g. make %{?dist} become 5.90.1 is the mass rebuild is > before test2, or if the mass rebuild coincides with test2 go 5.91. > > It doesn't cover packages not using disttags (so it's perhaps another > incentive for these packagers to use them) and due to everything being > automated doesn't serve as a way to ping absent packagers. But that > was only a side effect of the humanly powered mass-rebuilds, which > will be managed differently anyway in the future. -- 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 chris.stone at gmail.com Thu Jul 6 20:42:21 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 13:42:21 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152198817.24961.194.camel@localhost> References: <20060630095230.GA19767@redhat.com> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> Message-ID: On 7/6/06, Toshio Kuratomi wrote: > On Wed, 2006-07-05 at 23:58 -0700, Christopher Stone wrote: > > On 7/5/06, Enrico Scholz wrote: > > > Again: rpm does not allow to require a certain program (PHP) version; > > > you can require a certain package version only. > > > > > > And btw; packaging guidelines are handling this case already: > > > > > > | First, if the lowest possible requirement is so old that nobody has a > > > | version older than that installed on any target distribution release, > > > | there's no need to include the version in the dependency at all. > > > | ... > > > | As a rule of thumb, if the version is not required, don't add it just > > > | for fun. > > > [http://fedoraproject.org/wiki/Packaging/Guidelines] > > > > > > > > > > Please do not ask me to lower the quality standards that pear packages > > > > expect by not providing this information in my spec files. > > > > > > You are not lowering quality standards when unneeded and non-working > > > things like "Requires: php >= 4.2" will be omitted. > > > > Unneeded? by whom? Fedora's rpm? other package maintainers for other > > distributions? Some poor sap who built his OS from scratch who is > > trying to determine what he needs installed for your package? Somone > > who only wants to upgrade your package and not their whole system? > > > > Oh I forgot, version dependencies dont work on Fedora (LOL). > > > No. Version dependencies don't work as you're expecting in current rpm. > > > We are not adding this information because it's fun, and we are not > > adding requirements for packages that are so old nobody will have them > > installed. > > > You are adding requirements for package versions which are not relevant > for Fedora, which is what the guidelines are saying should be avoided. How is it not relevant? If I use FC4 and a pear pacakge I want is on FC5, should not installing the FC5 package do some version checking or are we to assume that every fedora user is using only packages from their distro release? > > > Can we please close this silly discussion or does anyone here actually > > agree with Enrico? > > Enrico has the following points: > 1) rpm's handling of Epochs means that versioned dependencies reference > package versions, not upstream versions. Because of this, including the > version in the rpm when it is unnecessary for all the distributions we > are supporting is misleading and potentially hurts packagers on other > distributions. Yes, but there are no php-pear packages that use epochs and very likely that none ever will. Yes, there is a 0.0000000001% chance that some php-pear package might one day use an epoch. The argument that version numbers potentially hurt other packagers on other distributions is ludicris. The version numbers on pear packages refer to the upstream versions in 100% of all cases. Claming that epochs are going to screw things up for everyone is just silly, it's not going to happen. > > 2) Using a versioned dependency pulled verbatim from a README file > ignores the patches applied by the Fedora maintainer to the base > package. If the README says "Requires php >= 5.0.1 because of a bug in > earlier versions" but the Fedora maintainer has backported fixes to > these bugs for the 5.0-4 package, then using a naive versioned > dependency of Requires: php >= 5.0.1 is wrong. Well duh, if you are stupid enough to make a patch to php and not include the patched version in your requires because the README says otherwise, then you are too much of an idiot to be packaging for Fedora to begin with. Again the "points" being brought up seem more like "grasping at straws" or "way off topic/off base". > > 3) The packaging guidelines already state when it is appropriate to > include versioned dependencies and this is not one of them. This means > we're deciding whether to make an exception for php/pear packages rather > than making new policy. No. The packaging guidelines indicate when you should NOT use version numbers specifically saying not to use them if the package they refer to is older than redhat 6.2 which is pretty old. Oh and not to add the just for fun. Unless there is some other text you are referring to? We are not deciding to make an excption to any rules. > > The point you seem to be making is that PEAR packages include a lot of > information about the versions of upstream releases that are required. > You'd like to include this in the spec file to help other packagers use > this outside of Fedora. Or other packagers inside Fedora who do not necessarily have a pristine standard setup, for example someone with FC5 installed with a few cherry picked FC6 rpms updated. > > Currently, I'd be disinclined to make an exception for php/pear > packages. That could change depending on how compelling the answers to > the following two questions are: WHAT EXCEPTION?! Please indicate the exact text you are referring to about this so called "exception". > > Since PEAR packages provide this dependency information, why should we > include it in the spec file? Why not? You havn't convinced me yet that we are going against any guidelines here. Why should we include dist tags? Why should we include version numbers in changelogs? Why should we add comments in our spec file? etc etc. (I dont expect you to answer these questions, I just trying to make a point). Hell let's just give up any hope of making a good package and change all Guidelines to read "Just do the minimal amount that is necessary to make your package work with the version of Fedora which you use". > > Enrico's points 1 & 2 mean that adding version information unnecessarily > can mislead foreign packagers rather than help them. Why do you think > those points don't apply to PEAR packages? Because the argument is based off a false premise. He uses the argument that since rpm has epoch capabilities, then all version numbers in all spec files are totally meaningless because epochs are not used by upstream packages. Therefore since the bind package uses epochs we should never use version number requirements in any other packages especially packages that will most likely never have any need for the use of the epoch field. QED. From chris.stone at gmail.com Thu Jul 6 21:20:03 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 14:20:03 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> Message-ID: On 7/6/06, Christopher Stone wrote: > Yes, but there are no php-pear packages that use epochs and very > likely that none ever will. Yes, there is a 0.0000000001% chance > that some php-pear package might one day use an epoch. Oh and before anyone chimes in saying the php-pear package itself uses an epoch, I should make the point that we don't use this epoch for php-pear. We require php-pear(PEAR) which does not have an epoch in its version number. So even in this case we do not use epochs. From toshio at tiki-lounge.com Thu Jul 6 21:50:12 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 06 Jul 2006 14:50:12 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> Message-ID: <1152222613.24961.259.camel@localhost> On Thu, 2006-07-06 at 13:42 -0700, Christopher Stone wrote: > On 7/6/06, Toshio Kuratomi wrote: > > You are adding requirements for package versions which are not relevant > > for Fedora, which is what the guidelines are saying should be avoided. > > How is it not relevant? If I use FC4 and a pear pacakge I want is on > FC5, should not installing the FC5 package do some version checking or > are we to assume that every fedora user is using only packages from > their distro release? > The message that this all stems from is here: https://www.redhat.com/archives/fedora-packaging/2006-July/msg00050.html the quotation by you is that you are requiring php >= 4.2.0 in some packages; php >= 4.3.0 in others. php 4.3.3 was already present in Fedora Core 1 so the package version is deeply irrelevant for Fedora. > > > > 3) The packaging guidelines already state when it is appropriate to > > include versioned dependencies and this is not one of them. This means > > we're deciding whether to make an exception for php/pear packages rather > > than making new policy. > > No. The packaging guidelines indicate when you should NOT use version > numbers specifically saying not to use them if the package they refer > to is older than redhat 6.2 which is pretty old. Oh and not to add > the just for fun. > > Unless there is some other text you are referring to? We are not > deciding to make an excption to any rules. > I'm sorry, your interpretation of the guideline is wrong. You're confusing the example with the rule: First, if the lowest possible requirement is so old that nobody has a version older than that installed on any target distribution release, there's no need to include the version in the dependency at all. In that case we know the available software is new enough. For example, the version in gtk+-devel 1.2 dependency above is unnecessary for all Red Hat Linux distributions since (at least) release 6.2. The rule is whether the lowest version requirement is satisfied by the packages on Fedora's target distributions. It may be open to interpretation whether "target distribution release" means non-EOL distributions (in which case FC4+ currently) or distributions the packager is actively building for but in either case, php >= 4.2.0 being irrelevant even for FC1 means it is too old. Thanks for your well-reasoned rebuttals to Enrico's points. I'll continue to read them until I have an opinion on whether putting unnecessary versions into the package spec is justified. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Thu Jul 6 22:11:44 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 15:11:44 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152222613.24961.259.camel@localhost> References: <20060630095230.GA19767@redhat.com> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <1152222613.24961.259.camel@localhost> Message-ID: On 7/6/06, Toshio Kuratomi wrote: > On Thu, 2006-07-06 at 13:42 -0700, Christopher Stone wrote: > The message that this all stems from is here: > https://www.redhat.com/archives/fedora-packaging/2006-July/msg00050.html > the quotation by you is that you are requiring php >= 4.2.0 in some > packages; php >= 4.3.0 in others. php 4.3.3 was already present in > Fedora Core 1 so the package version is deeply irrelevant for Fedora. ... > The rule is whether the lowest version requirement is satisfied by the > packages on Fedora's target distributions. It may be open to > interpretation whether "target distribution release" means non-EOL > distributions (in which case FC4+ currently) or distributions the > packager is actively building for but in either case, php >= 4.2.0 being > irrelevant even for FC1 means it is too old. I have no problem with just Requiring php instead of php 4.2 because 4.2 is ancient. Note that even my default spec file: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec Does not have any version number listed for php. But I do not see any harm in actually providing this information, it would seem especially important for packages that require php 5 or even php 6 when it comes out. But a really important point I want to make and clarify: It is not the php version that really concerns me. It is the version requirements of other pear packages which is my main concern. For example, take a look at my spec file for Payment_Process: http://tkmame.retrogames.com/fedora-extras/php-pear-Payment-Process.spec This package requires 5 other pear packages with specific version requirements that have been listed by the package. Now my questions are: 1) Should I not list the version numbers for these packages just because these packages never existed in Fedora? 2) Is there any harm in listing the version number requirements? 3) Is there any benefit to not having the version number requirements? Thanks for keeping an open mind. From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 6 22:22:41 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 07 Jul 2006 00:22:41 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Thu, 6 Jul 2006 13:42:21 -0700") References: <20060630095230.GA19767@redhat.com> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> Message-ID: <87r70yidam.fsf@kosh.bigo.ensc.de> chris.stone at gmail.com ("Christopher Stone") writes: > How is it not relevant? If I use FC4 and a pear pacakge I want is on > FC5, should not installing the FC5 package do some version checking or > are we to assume that every fedora user is using only packages from > their distro release? I do not understand you here; on the one side, you want to use versioned dependencies which work in a defined environment only, and now you are speaking about packages from unknown sources? >> Enrico has the following points: >> 1) rpm's handling of Epochs means that versioned dependencies reference >> package versions, not upstream versions. Because of this, including the >> version in the rpm when it is unnecessary for all the distributions we >> are supporting is misleading and potentially hurts packagers on other >> distributions. > > Yes, but there are no php-pear packages that use epochs and very > likely that none ever will. Yes, there is a 0.0000000001% chance > that some php-pear package might one day use an epoch. > > The argument that version numbers potentially hurt other packagers on > other distributions is ludicris. Again: versioned dependencies like "php >= 4.2" are redundant and do not achieve the wanted effect of requiring a program version (which is not supported by rpm). Existing packaging guidelines suggest already to remove such unneeded constraints. >> 3) The packaging guidelines already state when it is appropriate to >> include versioned dependencies and this is not one of them. This means >> we're deciding whether to make an exception for php/pear packages rather >> than making new policy. > > No. The packaging guidelines indicate when you should NOT use version > numbers specifically saying not to use them if the package they refer > to is older than redhat 6.2 which is pretty old. They are very exact in this regard: First, if the lowest possible requirement is so old that nobody has a version older than that installed on any target distribution release, The "target distribution releases" are FE4, FE5 and devel. > Oh and not to add the just for fun. Dependencies like "php >= 4.2" are just for fun. > Why should we include dist tags? Because of upgrade paths > Why should we include version numbers in changelogs? It is useful for people to see the version number in --changelog output and compare it e.g. with the previous version listed in /var/log/yum.log. It would make a difference when these numbers would be omitted. But there would be absolutely no difference whether you install a package with 'Requires: php >= 4.2' or plain 'Requires: php' on supported targets. > Why should we add comments in our spec file? Is this really enforced? Or just an implication of the packaging rule which requires that spec files shall be readable for the reviewer? > etc etc. (I dont expect you to answer these questions, I just trying > to make a point). sorry; you missed this goal... > Hell let's just give up any hope of making a good package and change > all Guidelines to read "Just do the minimal amount that is necessary > to make your package work with the version of Fedora which you use". Again: you want to add versioned requires just because some README says that a certain program version is required. But this can not be achieved with rpm which allows to specify package versions only. >> Enrico's points 1 & 2 mean that adding version information unnecessarily >> can mislead foreign packagers rather than help them. Why do you think >> those points don't apply to PEAR packages? > > Because the argument is based off a false premise. He uses the > argument that since rpm has epoch capabilities, then all version > numbers in all spec files are totally meaningless because epochs are > not used by upstream packages. > Therefore since the bind package uses epochs 'bind' was used because you did not understood versioned dependencies and I wanted to give an example of possible problems. A perhaps yet more related example would be php-pear with its epoch of '1'. > we should never use version number requirements in any other packages > especially packages that will most likely never have any need for the > use of the epoch field. Epochs are an existing feature of rpm and you have to live with it. I am heavily against establishing guidelines which enforce versioned dependencies in the hope that future package do not use epochs. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From chris.stone at gmail.com Thu Jul 6 22:43:33 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 15:43:33 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87r70yidam.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <87r70yidam.fsf@kosh.bigo.ensc.de> Message-ID: On 7/6/06, Enrico Scholz wrote: > chris.stone at gmail.com ("Christopher Stone") writes: > > > How is it not relevant? If I use FC4 and a pear pacakge I want is on > > FC5, should not installing the FC5 package do some version checking or > > are we to assume that every fedora user is using only packages from > > their distro release? > > I do not understand you here; on the one side, you want to use versioned > dependencies which work in a defined environment only, and now you are > speaking about packages from unknown sources? > > > >> Enrico has the following points: > >> 1) rpm's handling of Epochs means that versioned dependencies reference > >> package versions, not upstream versions. Because of this, including the > >> version in the rpm when it is unnecessary for all the distributions we > >> are supporting is misleading and potentially hurts packagers on other > >> distributions. > > > > Yes, but there are no php-pear packages that use epochs and very > > likely that none ever will. Yes, there is a 0.0000000001% chance > > that some php-pear package might one day use an epoch. > > > > The argument that version numbers potentially hurt other packagers on > > other distributions is ludicris. > > Again: versioned dependencies like "php >= 4.2" are redundant and do not > achieve the wanted effect of requiring a program version (which is not > supported by rpm). > > Existing packaging guidelines suggest already to remove such unneeded > constraints. php 4.2 is a bad example because it is so ancient. Let's assume I am packaging a pear package for -devel which requires php-6.0 (assume for sake of argument that php6 comes with devel). If i just say Requires: php, then someone from FC-5 who wants to use my pear package does not know that he needs php6 and can install the package without any problems incorrectly. If I say Requires: php >= 6.0 then someone from FC-5 who wants to install my devel package now knows that he also has to install php-6 from -devel as well for the package to function properly. > > > >> 3) The packaging guidelines already state when it is appropriate to > >> include versioned dependencies and this is not one of them. This means > >> we're deciding whether to make an exception for php/pear packages rather > >> than making new policy. > > > > No. The packaging guidelines indicate when you should NOT use version > > numbers specifically saying not to use them if the package they refer > > to is older than redhat 6.2 which is pretty old. > > They are very exact in this regard: > > First, if the lowest possible requirement is so old that nobody has a > version older than that installed on any target distribution release, > > The "target distribution releases" are FE4, FE5 and devel. Then why do the guidelines use redhat6.2 as an example? If this is the case the guidelines should be updated. But this still does not take into consideration the example I outlined above. > > > > Oh and not to add the just for fun. > > Dependencies like "php >= 4.2" are just for fun. Again bad example, see the example scenerio I outlined above. > > etc etc. (I dont expect you to answer these questions, I just trying > > to make a point). > > sorry; you missed this goal... The point I was trying to make is that although the version numbers may not technically be required if we assume everyone is using packages from FC5 and FC5 only, it does not take into consideration people who want to upgrade specific packages without upgrading their entire system. These extra things we do in the spec file are helpful. Adding version numbers to changelogs is not required, but it is helpful, comments are not required but they are helpful, etc... > > > > Hell let's just give up any hope of making a good package and change > > all Guidelines to read "Just do the minimal amount that is necessary > > to make your package work with the version of Fedora which you use". > > Again: you want to add versioned requires just because some README says > that a certain program version is required. But this can not be achieved > with rpm which allows to specify package versions only. pear packages have a line in the spec file of the form: Provides: php-pear(Foo) = %{version}-%{release} This provides the upstream software version, not the package version. This is what we use on our requires line. So for example we do not have: Requires: php-pear >= .. we have: Requires: php-pear(PEAR) >= ... > > > > >> Enrico's points 1 & 2 mean that adding version information unnecessarily > >> can mislead foreign packagers rather than help them. Why do you think > >> those points don't apply to PEAR packages? > > > > Because the argument is based off a false premise. He uses the > > argument that since rpm has epoch capabilities, then all version > > numbers in all spec files are totally meaningless because epochs are > > not used by upstream packages. > > > Therefore since the bind package uses epochs > > 'bind' was used because you did not understood versioned dependencies > and I wanted to give an example of possible problems. A perhaps yet more > related example would be php-pear with its epoch of '1'. Again, we do not use php-pear, we use php-pear(PEAR) which provides the upstream software version release, not the package release. > > > > we should never use version number requirements in any other packages > > especially packages that will most likely never have any need for the > > use of the epoch field. > > Epochs are an existing feature of rpm and you have to live with it. I > am heavily against establishing guidelines which enforce versioned > dependencies in the hope that future package do not use epochs. We don't and never will use epochs, even the php-pear package which has an epoch in the package version does not use the epoch in the php-pear(PEAR) version specification. From chris.stone at gmail.com Thu Jul 6 23:26:57 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 16:26:57 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <87r70yidam.fsf@kosh.bigo.ensc.de> Message-ID: I have updated my pear spec template: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec Changed: Provides: php-pear(Foo_Bar) = %{version}-%{release} To: Provides: php-pear(Foo_Bar) = %{version} Since %{release} is not part of the upstream software version which this Provides line is meant to provide. From toshio at tiki-lounge.com Fri Jul 7 01:10:50 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 06 Jul 2006 18:10:50 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <1152222613.24961.259.camel@localhost> Message-ID: <1152234651.24961.305.camel@localhost> On Thu, 2006-07-06 at 15:11 -0700, Christopher Stone wrote: > On 7/6/06, Toshio Kuratomi wrote: > > On Thu, 2006-07-06 at 13:42 -0700, Christopher Stone wrote: > > The message that this all stems from is here: > > https://www.redhat.com/archives/fedora-packaging/2006-July/msg00050.html > > the quotation by you is that you are requiring php >= 4.2.0 in some > > packages; php >= 4.3.0 in others. php 4.3.3 was already present in > > Fedora Core 1 so the package version is deeply irrelevant for Fedora. > ... > > The rule is whether the lowest version requirement is satisfied by the > > packages on Fedora's target distributions. It may be open to > > interpretation whether "target distribution release" means non-EOL > > distributions (in which case FC4+ currently) or distributions the > > packager is actively building for but in either case, php >= 4.2.0 being > > irrelevant even for FC1 means it is too old. > > I have no problem with just Requiring php instead of php 4.2 because > 4.2 is ancient. Note that even my default spec file: > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec > Does not have any version number listed for php. But I do not see any > harm in actually providing this information, it would seem especially > important for packages that require php 5 or even php 6 when it comes > out. > This is a different ball of wax in the beginning but becomes the same later on. Let's say FC6 is the first FC to provide php-6.0.1 and your package requires php-6.0.0. Then you can list Requires: php >= 6.0.0 in your spec file. Now, a year and a half goes by and FC6 goes EOL. Now the supported platforms are FC7, FC8, and devel. All of these platforms have php >= 6.0.0. So the version information is no longer needed. I don't know if you'll get a bug report asking to remove the versioning (probably no one will notice for quite a while) but new packages should not specify the Requires: php >= 6.0.0 at that point. > But a really important point I want to make and clarify: > It is not the php version that really concerns me. It is the version > requirements of other pear packages which is my main concern. > > For example, take a look at my spec file for Payment_Process: > http://tkmame.retrogames.com/fedora-extras/php-pear-Payment-Process.spec > > This package requires 5 other pear packages with specific version > requirements that have been listed by the package. > > Now my questions are: > 1) Should I not list the version numbers for these packages just > because these packages never existed in Fedora? The current guidelines would say, do not list the version as no Fedora release ships an unsatisfactory version. If I wanted to backport the package to FC4, the first step would be to backport the required packages from the FE where they exists, as well, so this doesn't seem like a huge problem. > 2) Is there any harm in listing the version number requirements? > 3) Is there any benefit to not having the version number requirements? > This is the crux of the matter. I still use FC3 on one machine and I use a mixed FC4/FC5 box on another. I can see the benefit of knowing what packages can be rebuilt for these computers and which can not. Enrico's posts show how the information can be problematic when mixing distros (Fedora's php-PEAR may not use an epoch while SuSE's may.) I think we should remove this case from our consideration because we are packaging for the benefit of Fedora, not users of other distros. His posts also show how intradistro dependencies have to account for patches and bugfixes that make a package not-quite the next version. If you're using virtual Provides that represent the upstream package everywhere, how are you going to account for this? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Fri Jul 7 01:35:43 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 18:35:43 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1152234651.24961.305.camel@localhost> References: <20060630095230.GA19767@redhat.com> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <1152222613.24961.259.camel@localhost> <1152234651.24961.305.camel@localhost> Message-ID: On 7/6/06, Toshio Kuratomi wrote: > On Thu, 2006-07-06 at 15:11 -0700, Christopher Stone wrote: > > On 7/6/06, Toshio Kuratomi wrote: > > > On Thu, 2006-07-06 at 13:42 -0700, Christopher Stone wrote: > > > The message that this all stems from is here: > > > https://www.redhat.com/archives/fedora-packaging/2006-July/msg00050.html > > > the quotation by you is that you are requiring php >= 4.2.0 in some > > > packages; php >= 4.3.0 in others. php 4.3.3 was already present in > > > Fedora Core 1 so the package version is deeply irrelevant for Fedora. > > ... > > > The rule is whether the lowest version requirement is satisfied by the > > > packages on Fedora's target distributions. It may be open to > > > interpretation whether "target distribution release" means non-EOL > > > distributions (in which case FC4+ currently) or distributions the > > > packager is actively building for but in either case, php >= 4.2.0 being > > > irrelevant even for FC1 means it is too old. > > > > I have no problem with just Requiring php instead of php 4.2 because > > 4.2 is ancient. Note that even my default spec file: > > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec > > Does not have any version number listed for php. But I do not see any > > harm in actually providing this information, it would seem especially > > important for packages that require php 5 or even php 6 when it comes > > out. > > > This is a different ball of wax in the beginning but becomes the same > later on. Let's say FC6 is the first FC to provide php-6.0.1 and your > package requires php-6.0.0. Then you can list Requires: php >= 6.0.0 in > your spec file. > > Now, a year and a half goes by and FC6 goes EOL. Now the supported > platforms are FC7, FC8, and devel. All of these platforms have php >= > 6.0.0. So the version information is no longer needed. I don't know if > you'll get a bug report asking to remove the versioning (probably no one > will notice for quite a while) but new packages should not specify the > Requires: php >= 6.0.0 at that point. I agree 100%. The guidelines should state something like, if it requires a php version < 18 months old, then the version should be specified. Or something like this. > ... > His posts also show how intradistro dependencies have to account for > patches and bugfixes that make a package not-quite the next version. If > you're using virtual Provides that represent the upstream package > everywhere, how are you going to account for this? Yes, there may be a case where you have to patch a pear package, and some other pear package must depend on this patch being in place. In a case like this I would think you would use: Requires: php-pear-Foo >= x.x-y Instead of the usual: Requires: php-pear(Foo) >= x.x From chris.stone at gmail.com Fri Jul 7 03:27:46 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 20:27:46 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <1152222613.24961.259.camel@localhost> <1152234651.24961.305.camel@localhost> Message-ID: Updated pear spectemplate: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec -Changed Requries(post) to use /usr/bin/pear instead of %{__pear} since %{__pear} might have to be defined by rpm package instead of php-pear package for this to work properly. -Reformatted spec file to look like other spec files - Changed %{buildroot} to $RPM_BUILD_ROOT - Spacify/Adjust indentations -Fixed an %{__rm} to just an rm From chris.stone at gmail.com Fri Jul 7 04:29:12 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 6 Jul 2006 21:29:12 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear Message-ID: I have created a patch for fedora-newrpmspec: http://tkmame.retrogames.com/fedora-extras/fedora-newrpmspec.patch This works with the current spectemplate-pear file located here: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec Can you packaging guys please review this patch to make sure everything looks okay? Thanks! From tibbs at math.uh.edu Fri Jul 7 14:14:06 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 07 Jul 2006 09:14:06 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Thu, 6 Jul 2006 18:35:43 -0700") References: <20060630095230.GA19767@redhat.com> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <1152222613.24961.259.camel@localhost> <1152234651.24961.305.camel@localhost> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> I agree 100%. The guidelines should state something like, if it CS> requires a php version < 18 months old, then the version should be CS> specified. Or something like this. How about: Use of the version is optional if it is satisfied by the originally shipping version in all targeted Fedora releases. (Perhaps s/optional/discouraged/.) Currently, that's php 5.0.4 for FC4 and 5.1.2 for FC5. (FC3 was 4.3.9. That should be kept in mind as the infrastructure project might request an FC3 branch of something they'd like to use.) - J< From chris.stone at gmail.com Fri Jul 7 21:34:20 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 7 Jul 2006 14:34:20 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <1152222613.24961.259.camel@localhost> <1152234651.24961.305.camel@localhost> Message-ID: On 7/7/06, Jason L Tibbitts III wrote: > >>>>> "CS" == Christopher Stone writes: > > CS> I agree 100%. The guidelines should state something like, if it > CS> requires a php version < 18 months old, then the version should be > CS> specified. Or something like this. > > How about: > > Use of the version is optional if it is satisfied by the originally > shipping version in all targeted Fedora releases. (Perhaps > s/optional/discouraged/.) > > Currently, that's php 5.0.4 for FC4 and 5.1.2 for FC5. (FC3 was > 4.3.9. That should be kept in mind as the infrastructure project > might request an FC3 branch of something they'd like to use.) I dont see any reason why this should be discouraged, and I think it should actaully be encouraged. But optional is fine. From dlutter at redhat.com Fri Jul 7 22:34:41 2006 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 07 Jul 2006 15:34:41 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: References: Message-ID: <1152311681.11594.1.camel@localhost.localdomain> On Thu, 2006-07-06 at 21:29 -0700, Christopher Stone wrote: > I have created a patch for fedora-newrpmspec: > http://tkmame.retrogames.com/fedora-extras/fedora-newrpmspec.patch > > This works with the current spectemplate-pear file located here: > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec > > Can you packaging guys please review this patch to make sure > everything looks okay? It's best if you file a bug against fedora-rpmdevtools - that way, it won't get lost in the shuffle. David From chris.stone at gmail.com Fri Jul 7 22:54:55 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 7 Jul 2006 15:54:55 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: <1152311681.11594.1.camel@localhost.localdomain> References: <1152311681.11594.1.camel@localhost.localdomain> Message-ID: On 7/7/06, David Lutterkort wrote: > On Thu, 2006-07-06 at 21:29 -0700, Christopher Stone wrote: > > I have created a patch for fedora-newrpmspec: > > http://tkmame.retrogames.com/fedora-extras/fedora-newrpmspec.patch > > > > This works with the current spectemplate-pear file located here: > > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec > > > > Can you packaging guys please review this patch to make sure > > everything looks okay? > > It's best if you file a bug against fedora-rpmdevtools - that way, it > won't get lost in the shuffle. Well we currently depend on php-pear to drop in some macros, I would have to file a bug against that first. But I think a packaging member should file the bug for php-pear and place it at high priority (should only take 15 minutes to patch up) because if I file the php-pear bug, it will never get fixed. I can make a sample macros.pear file if needed. From bugs.michael at gmx.net Fri Jul 7 23:11:40 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 8 Jul 2006 01:11:40 +0200 Subject: [Fedora-packaging] compat packages: worst-case scenario - conflicts Message-ID: <20060708011140.77cf50eb.bugs.michael@gmx.net> JFYI, so more people become aware of one pitfall related to compat-* packages: https://bugzilla.redhat.com/188370 https://bugzilla.redhat.com/197025 From chris.stone at gmail.com Fri Jul 7 23:09:59 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 7 Jul 2006 16:09:59 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: References: <1152311681.11594.1.camel@localhost.localdomain> Message-ID: On 7/7/06, Christopher Stone wrote: > I can make a sample macros.pear file if needed. I have put up a sample macros.pear file here: http://tkmame.retrogames.com/fedora-extras/macros.pear Tibbs: do these macros look okay? I can file a bug against php-pear to add this if it looks okay with you, or perhaps you can make any adjustments necessary and file the bug. Let me know. Thanks. From tibbs at math.uh.edu Fri Jul 7 23:58:58 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 07 Jul 2006 18:58:58 -0500 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: (Christopher Stone's message of "Fri, 7 Jul 2006 16:09:59 -0700") References: <1152311681.11594.1.camel@localhost.localdomain> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> Tibbs: do these macros look okay? It took me a while to figure out why pecl-related stuff would be in those macros, but now I see that both /usr/bin/pear and /usr/bin/pecl are in the php-pear package. Everything there looks quite good to me. I just hope that we don't stall out having to wait for an update to the core php-pear package. However, there is a php-pear package in updates/testing at the moment; perhaps we can get this snuck in. - J< From tibbs at math.uh.edu Sat Jul 8 00:03:36 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 07 Jul 2006 19:03:36 -0500 Subject: [Fedora-packaging] compat packages: worst-case scenario - conflicts In-Reply-To: <20060708011140.77cf50eb.bugs.michael@gmx.net> (Michael Schwendt's message of "Sat, 8 Jul 2006 01:11:40 +0200") References: <20060708011140.77cf50eb.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> JFYI, so more people become aware of one pitfall related to MS> compat-* packages: So far the proposed uses of compat- packages in extras that I've seen have been for providing libraries only. Perhaps we could consider standardizing that usage only and consider other uses as they come up. - J< From chris.stone at gmail.com Sat Jul 8 03:37:09 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 7 Jul 2006 20:37:09 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: References: <1152311681.11594.1.camel@localhost.localdomain> Message-ID: On 7/7/06, Jason L Tibbitts III wrote: > >>>>> "CS" == Christopher Stone writes: > > CS> Tibbs: do these macros look okay? > > It took me a while to figure out why pecl-related stuff would be in > those macros, but now I see that both /usr/bin/pear and /usr/bin/pecl > are in the php-pear package. > > Everything there looks quite good to me. I just hope that we don't > stall out having to wait for an update to the core php-pear package. > However, there is a php-pear package in updates/testing at the moment; > perhaps we can get this snuck in. That test release was for my bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196802 Which fixes stuff like: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/x86_64/php-pear-DB-1.7.6-6.src.rpm/result/build.log I was thinking the same thing that these two could be pushed together. Hopefully Joe is watching this mailing list and knows what we are up to. :) From tibbs at math.uh.edu Sat Jul 8 04:18:57 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 07 Jul 2006 23:18:57 -0500 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: (Jason L. Tibbitts, III's message of "Fri, 07 Jul 2006 18:58:58 -0500") References: <1152311681.11594.1.camel@localhost.localdomain> Message-ID: >>>>> "JLT" == Jason L Tibbitts, writes: JLT> Everything there looks quite good to me. Crap, did some of those need to be %global instead of %define? All of them? I don't completely understand the underlying issue. - J< From chris.stone at gmail.com Sat Jul 8 04:23:04 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 7 Jul 2006 21:23:04 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: References: <1152311681.11594.1.camel@localhost.localdomain> Message-ID: On 7/7/06, Jason L Tibbitts III wrote: > >>>>> "JLT" == Jason L Tibbitts, writes: > > JLT> Everything there looks quite good to me. > > Crap, did some of those need to be %global instead of %define? All of > them? I don't completely understand the underlying issue. I think that was if we used the form: %{!?__php: %define __php /usr/bin/php} Which we don't do in this case. The issue in question is layed out here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147238 From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 8 09:26:05 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 08 Jul 2006 11:26:05 +0200 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: (Christopher Stone's message of "Thu, 6 Jul 2006 15:43:33 -0700") References: <20060630095230.GA19767@redhat.com> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <87r70yidam.fsf@kosh.bigo.ensc.de> Message-ID: <87veq8jvma.fsf@kosh.bigo.ensc.de> chris.stone at gmail.com ("Christopher Stone") writes: > pear packages have a line in the spec file of the form: > Provides: php-pear(Foo) = %{version}-%{release} > > This provides the upstream software version, not the package version. > This is what we use on our requires line. So for example we do not > have: > Requires: php-pear >= .. we have: > Requires: php-pear(PEAR) >= ... Such virtual provides are ok but you should keep in mind, that there is no ordering during installation; e.g. it is undefined whether | %package -n module | Provides: php-pear(MODULE) = 1.0 or | %package -n module-ng | Provides: php-pear(MODULE) = 2.0 will be installed by | Requires: php-pear(MODULE) >= 1.0 (because of the shortest-package-name-wins rule, 'module' will be the candidate for 'rpm') When you enforce such declarations for php-pear packages; should not every (non-pear) package have similar Provides:? Or, what would make php-pear an exception here? Have php-pear modules such an unstable API that missing version information would cause problems with a significant amount of packages? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Jul 8 11:38:31 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 8 Jul 2006 13:38:31 +0200 Subject: [Fedora-packaging] compat packages: worst-case scenario - conflicts In-Reply-To: References: <20060708011140.77cf50eb.bugs.michael@gmx.net> Message-ID: <20060708133831.585114c9.bugs.michael@gmx.net> On Fri, 07 Jul 2006 19:03:36 -0500, Jason L Tibbitts III wrote: > MS> JFYI, so more people become aware of one pitfall related to > MS> compat-* packages: > > So far the proposed uses of compat- packages in extras that I've seen > have been for providing libraries only. Perhaps we could consider > standardizing that usage only and consider other uses as they come up. In case you haven't noticed, the two bug reports I've pointed to are about compat- library packages. Their i18n message object files conflict, and it would be wrong to delete them and only ship the libs. It's just another problem which can be fixed, but which makes creating such compat- or libfooMAJVER- packages less easy. From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 8 14:29:31 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 08 Jul 2006 16:29:31 +0200 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: (Christopher Stone's message of "Fri, 7 Jul 2006 16:09:59 -0700") References: <1152311681.11594.1.camel@localhost.localdomain> Message-ID: <87fyhcjhkk.fsf@kosh.bigo.ensc.de> chris.stone at gmail.com ("Christopher Stone") writes: > I have put up a sample macros.pear file here: > http://tkmame.retrogames.com/fedora-extras/macros.pear How do you want to use these macros? Place them into /etc/rpm/? If so, you must remove the '%define ' and write only '%'. E.g. | %__pear %{_bindir}/pear instead of | %define __pear %{_bindir}/pear Then, current practice seems to be, to use a leading underscore for directory names (e.g. '%_libdir', '%_bindir'). Hence I would prefer | %_pecl_phpdir instead of | %pecl_phpdir Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat Jul 8 14:38:31 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 08 Jul 2006 16:38:31 +0200 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: <87fyhcjhkk.fsf@kosh.bigo.ensc.de> References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> Message-ID: <1152369513.11890.35.camel@rousalka.dyndns.org> Le samedi 08 juillet 2006 ? 16:29 +0200, Enrico Scholz a ?crit : > Then, current practice seems to be, to use a leading underscore for > directory names (e.g. '%_libdir', '%_bindir'). Hence I would prefer The current practice is to use a leading underscore before system macro names to avoid collisions with in-spec definitions I think So %pecl_phpdir can probably become _pecldir or _php-pecldir -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tibbs at math.uh.edu Sat Jul 8 15:27:34 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 08 Jul 2006 10:27:34 -0500 Subject: [Fedora-packaging] compat packages: worst-case scenario - conflicts In-Reply-To: <20060708133831.585114c9.bugs.michael@gmx.net> (Michael Schwendt's message of "Sat, 8 Jul 2006 13:38:31 +0200") References: <20060708011140.77cf50eb.bugs.michael@gmx.net> <20060708133831.585114c9.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> In case you haven't noticed, the two bug reports I've pointed to MS> are about compat- library packages. Library packages with other stuff, yes. My point was that there may be useful instances where there are libraries and nothing else. - J< From tibbs at math.uh.edu Sat Jul 8 16:30:34 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 08 Jul 2006 11:30:34 -0500 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: <87fyhcjhkk.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Sat, 08 Jul 2006 16:29:31 +0200") References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> Then, current practice seems to be, to use a leading underscore ES> for directory names (e.g. '%_libdir', '%_bindir'). A counterexample, which is what we are copying, from /usr/lib/rpm/macros: %perl_sitearch %(eval "`%{__perl} -V:installsitearch`"; echo $installsitearch) %perl_sitelib %(eval "`%{__perl} -V:installsitelib`"; echo $installsitelib) %perl_vendorarch %(eval "`%{__perl} -V:installvendorarch`"; echo $installvendorarch) %perl_vendorlib %(eval "`%{__perl} -V:installvendorlib`"; echo $installvendorlib) %perl_archlib %(eval "`%{__perl} -V:installarchlib`"; echo $installarchlib) %perl_privlib %(eval "`%{__perl} -V:installprivlib`"; echo $installprivlib) - J< From Axel.Thimm at ATrpms.net Sat Jul 8 17:04:35 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 8 Jul 2006 19:04:35 +0200 Subject: [Fedora-packaging] Re: compat packages: worst-case scenario - conflicts In-Reply-To: <20060708133831.585114c9.bugs.michael@gmx.net> References: <20060708011140.77cf50eb.bugs.michael@gmx.net> <20060708133831.585114c9.bugs.michael@gmx.net> Message-ID: <20060708170435.GC12952@neu.nirvana> On Sat, Jul 08, 2006 at 01:38:31PM +0200, Michael Schwendt wrote: > On Fri, 07 Jul 2006 19:03:36 -0500, Jason L Tibbitts III wrote: > > > MS> JFYI, so more people become aware of one pitfall related to > > MS> compat-* packages: > > > > So far the proposed uses of compat- packages in extras that I've seen > > have been for providing libraries only. Perhaps we could consider > > standardizing that usage only and consider other uses as they come up. > > In case you haven't noticed, the two bug reports I've pointed to are about > compat- library packages. Their i18n message object files conflict, and it > would be wrong to delete them and only ship the libs. It's just another > problem which can be fixed, but which makes creating such compat- or > libfooMAJVER- packages less easy. Indeed, this is very ugly. Michael, what do you have in mind with fixing conflicting locale files in this scenario? -- 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 tibbs at math.uh.edu Sat Jul 8 17:14:39 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 08 Jul 2006 12:14:39 -0500 Subject: [Fedora-packaging] Uneditable wiki pages Message-ID: So these two pages became uneditable when the permissions were locked down: http://fedoraproject.org/wiki/Packaging/UserRegistry http://fedoraproject.org/wiki/Packaging/UserCreation Is it necessary that they stay uneditable? Perhaps UserCreation should move to the drafts hierarchy, but the registry is supposed to be open to all packagers. - J< From chris.stone at gmail.com Sat Jul 8 19:07:27 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 8 Jul 2006 12:07:27 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> Message-ID: On 7/8/06, Jason L Tibbitts III wrote: > >>>>> "ES" == Enrico Scholz writes: > > ES> Then, current practice seems to be, to use a leading underscore > ES> for directory names (e.g. '%_libdir', '%_bindir'). > > A counterexample, which is what we are copying, from /usr/lib/rpm/macros: > > %perl_sitearch %(eval "`%{__perl} -V:installsitearch`"; echo $installsitearch) > %perl_sitelib %(eval "`%{__perl} -V:installsitelib`"; echo $installsitelib) > %perl_vendorarch %(eval "`%{__perl} -V:installvendorarch`"; echo $installvendorarch) > %perl_vendorlib %(eval "`%{__perl} -V:installvendorlib`"; echo $installvendorlib) > %perl_archlib %(eval "`%{__perl} -V:installarchlib`"; echo $installarchlib) > %perl_privlib %(eval "`%{__perl} -V:installprivlib`"; echo $installprivlib) Okay, I have updated the macros file here: http://tkmame.retrogames.com/fedora-extras/macros.pear Let me know if this looks okay. Thanks. From mattdm at mattdm.org Sat Jul 8 19:08:45 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 8 Jul 2006 15:08:45 -0400 Subject: [Fedora-packaging] compat packages: worst-case scenario - conflicts In-Reply-To: <20060708133831.585114c9.bugs.michael@gmx.net> References: <20060708011140.77cf50eb.bugs.michael@gmx.net> <20060708133831.585114c9.bugs.michael@gmx.net> Message-ID: <20060708190845.GA4708@jadzia.bu.edu> On Sat, Jul 08, 2006 at 01:38:31PM +0200, Michael Schwendt wrote: > In case you haven't noticed, the two bug reports I've pointed to are about > compat- library packages. Their i18n message object files conflict, and it > would be wrong to delete them and only ship the libs. It's just another > problem which can be fixed, but which makes creating such compat- or > libfooMAJVER- packages less easy. In this specific case, the compat packages only seem required by Audacity (which goes to wxGTK in the new 1.3b version -- see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186819) and NomadSync (which looks like the upstream developer has no further interest in). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From chris.stone at gmail.com Sat Jul 8 19:14:07 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 8 Jul 2006 12:14:07 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87veq8jvma.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <87r70yidam.fsf@kosh.bigo.ensc.de> <87veq8jvma.fsf@kosh.bigo.ensc.de> Message-ID: On 7/8/06, Enrico Scholz wrote: > chris.stone at gmail.com ("Christopher Stone") writes: > > > pear packages have a line in the spec file of the form: > > Provides: php-pear(Foo) = %{version}-%{release} > > > > This provides the upstream software version, not the package version. > > This is what we use on our requires line. So for example we do not > > have: > > Requires: php-pear >= .. we have: > > Requires: php-pear(PEAR) >= ... > > Such virtual provides are ok but you should keep in mind, that there is > no ordering during installation; e.g. it is undefined whether > > | %package -n module > | Provides: php-pear(MODULE) = 1.0 > > or > > | %package -n module-ng > | Provides: php-pear(MODULE) = 2.0 > > will be installed by > > | Requires: php-pear(MODULE) >= 1.0 > > (because of the shortest-package-name-wins rule, 'module' will be the > candidate for 'rpm') This should never happen, there are some cases where you may want a stable and an alpha version in which case you would Provide php-pear(MODULE-alpha). See: http://tkmame.retrogames.com/fedora-extras/php-pear-PHPUnit2.spec http://tkmame.retrogames.com/fedora-extras/php-pear-PHPUnit2-alpha.spec I think something like this should be mentioned in the guidelines. In other cases the pear module name itself changes, for example: PHPUnit (php4) and PHPUnit2 (php5) > When you enforce such declarations for php-pear packages; should not > every (non-pear) package have similar Provides:? Or, what would make > php-pear an exception here? Have php-pear modules such an unstable API > that missing version information would cause problems with a significant > amount of packages? Yes, the pear libraries are still relatively new, and many many pear modules are under active development. There are quite a few which are widely used and still not even out of alpha development stage yet. From ville.skytta at iki.fi Sun Jul 9 17:44:34 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 09 Jul 2006 20:44:34 +0300 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <87r70yidam.fsf@kosh.bigo.ensc.de> References: <20060630095230.GA19767@redhat.com> <87psgjx5ec.fsf@kosh.bigo.ensc.de> <1152128840.2728.177.camel@localhost.localdomain> <87ac7nx17y.fsf@kosh.bigo.ensc.de> <1152138667.5277.50.camel@rousalka.dyndns.org> <87u05vuw70.fsf@kosh.bigo.ensc.de> <87psgjut0m.fsf@kosh.bigo.ensc.de> <1152198817.24961.194.camel@localhost> <87r70yidam.fsf@kosh.bigo.ensc.de> Message-ID: <1152467074.2728.408.camel@localhost.localdomain> On Fri, 2006-07-07 at 00:22 +0200, Enrico Scholz wrote: > Again: versioned dependencies like "php >= 4.2" are redundant and do not > achieve the wanted effect of requiring a program version (which is not > supported by rpm). Sure it is. Just add the program version you want, eg. something like "Provides: foo(upstream) = $upstream_version" (no Epoch, most likely no Release) to packages and start using it. Or maybe even change rpmbuild to do it automatically so that for every N = E:V-R package, "Provides: N(upstream) = V" is inserted if this is something people would find generally useful. > Dependencies like "php >= 4.2" are just for fun. Again, depends. In this case those would be useful for folks working with Fedora and RHEL 2.1 (which continues to be supported still for almost 3 years and has php 4.1.2). From ville.skytta at iki.fi Sun Jul 9 21:59:39 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 10 Jul 2006 00:59:39 +0300 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> Message-ID: <1152482379.2728.457.camel@localhost.localdomain> On Sat, 2006-07-08 at 12:07 -0700, Christopher Stone wrote: > On 7/8/06, Jason L Tibbitts III wrote: > > > %perl_sitearch %(eval "`%{__perl} -V:installsitearch`"; echo $installsitearch) > > %perl_sitelib %(eval "`%{__perl} -V:installsitelib`"; echo $installsitelib) > > %perl_vendorarch %(eval "`%{__perl} -V:installvendorarch`"; echo $installvendorarch) > > %perl_vendorlib %(eval "`%{__perl} -V:installvendorlib`"; echo $installvendorlib) > > %perl_archlib %(eval "`%{__perl} -V:installarchlib`"; echo $installarchlib) > > %perl_privlib %(eval "`%{__perl} -V:installprivlib`"; echo $installprivlib) > > Okay, I have updated the macros file here: > > http://tkmame.retrogames.com/fedora-extras/macros.pear > > Let me know if this looks okay. We have leading-underscoreless %perl_* in rpm, %python_* in spec templates and upstream rpm, and %ruby_* in the forthcoming ruby spec template and ruby packaging guidelines; any reason for pear/pecl to be different? From chris.stone at gmail.com Sun Jul 9 22:33:13 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 9 Jul 2006 15:33:13 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: <1152482379.2728.457.camel@localhost.localdomain> References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> <1152482379.2728.457.camel@localhost.localdomain> Message-ID: On 7/9/06, Ville Skytt? wrote: > On Sat, 2006-07-08 at 12:07 -0700, Christopher Stone wrote: > > On 7/8/06, Jason L Tibbitts III wrote: > > > > > %perl_sitearch %(eval "`%{__perl} -V:installsitearch`"; echo $installsitearch) > > > %perl_sitelib %(eval "`%{__perl} -V:installsitelib`"; echo $installsitelib) > > > %perl_vendorarch %(eval "`%{__perl} -V:installvendorarch`"; echo $installvendorarch) > > > %perl_vendorlib %(eval "`%{__perl} -V:installvendorlib`"; echo $installvendorlib) > > > %perl_archlib %(eval "`%{__perl} -V:installarchlib`"; echo $installarchlib) > > > %perl_privlib %(eval "`%{__perl} -V:installprivlib`"; echo $installprivlib) > > > > Okay, I have updated the macros file here: > > > > http://tkmame.retrogames.com/fedora-extras/macros.pear > > > > Let me know if this looks okay. > > We have leading-underscoreless %perl_* in rpm, %python_* in spec > templates and upstream rpm, and %ruby_* in the forthcoming ruby spec > template and ruby packaging guidelines; any reason for pear/pecl to be > different? I put the underscores in because Enrico said the opposite: ES> Then, current practice seems to be, to use a leading underscore for ES> directory names (e.g. '%_libdir', '%_bindir'). Hence I would prefer ES> ES> | %_pecl_phpdir ES> ES> instead of ES> ES> | %pecl_phpdir So I guess I will remove the underscores to be in line with the other language directory definitions. From jorton at redhat.com Mon Jul 10 09:50:26 2006 From: jorton at redhat.com (Joe Orton) Date: Mon, 10 Jul 2006 10:50:26 +0100 Subject: [Fedora-packaging] Re: compat packages: worst-case scenario - conflicts In-Reply-To: <20060708170435.GC12952@neu.nirvana> References: <20060708011140.77cf50eb.bugs.michael@gmx.net> <20060708133831.585114c9.bugs.michael@gmx.net> <20060708170435.GC12952@neu.nirvana> Message-ID: <20060710095026.GA13590@redhat.com> On Sat, Jul 08, 2006 at 07:04:35PM +0200, Axel Thimm wrote: > On Sat, Jul 08, 2006 at 01:38:31PM +0200, Michael Schwendt wrote: > > On Fri, 07 Jul 2006 19:03:36 -0500, Jason L Tibbitts III wrote: > > > > > MS> JFYI, so more people become aware of one pitfall related to > > > MS> compat-* packages: > > > > > > So far the proposed uses of compat- packages in extras that I've seen > > > have been for providing libraries only. Perhaps we could consider > > > standardizing that usage only and consider other uses as they come up. > > > > In case you haven't noticed, the two bug reports I've pointed to are about > > compat- library packages. Their i18n message object files conflict, and it > > would be wrong to delete them and only ship the libs. It's just another > > problem which can be fixed, but which makes creating such compat- or > > libfooMAJVER- packages less easy. > > Indeed, this is very ugly. Michael, what do you have in mind with > fixing conflicting locale files in this scenario? You can rename the locale files and patch the sources to pass a different domain name to bindtextdomain() quite easily. joe From jorton at redhat.com Mon Jul 10 09:58:44 2006 From: jorton at redhat.com (Joe Orton) Date: Mon, 10 Jul 2006 10:58:44 +0100 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> <1152482379.2728.457.camel@localhost.localdomain> Message-ID: <20060710095844.GA14442@redhat.com> On Sun, Jul 09, 2006 at 03:33:13PM -0700, Christopher Stone wrote: > So I guess I will remove the underscores to be in line with the other > language directory definitions. I've submitted a new php-pear to FC-5 testing which includes this latest macros.pear; can you test this out? Thanks a lot for your work here. joe From jkeating at redhat.com Mon Jul 10 17:01:39 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 10 Jul 2006 13:01:39 -0400 Subject: [Fedora-packaging] To noarch or arch for arch specific script packages? Message-ID: <200607101301.43818.jkeating@redhat.com> There exists packages that are written in say python, but are used for arch specific task. Consider python scripts that deal with grub (i386/x86_64), or other such things. Do we want to continue considering these 'noarch' packages, or do we want to mark them as arch specific? They'll already have the ExclusiveArch: i386 x86_64 or ExcludeArch in the spec. The reason I bring this up as it has tickled a possible bug in Brew, Red Hat's build software. Currently brew will look at BuildArch and ExclusiveArch / ExcludeArch, and the configured arches for a build target to decide where to build the package at. In one package case, it has BuildArch: noarch, and ExclusiveArch: i386 x86_64. Combining the two, brew is complaining that Architecture is not included 'noarch'. A (ugly) work around was to add 'noarch' to the ExclusiveArch list, or use ExcludeArch and list a bunch of arches this package wouldn't work for, but this can break distribution composes that query ExclusiveArch to figure out what packages should be included in which arches for composes or produce very ugly spec files with a ton of arches listed under ExcludeArch. An ExclusiveArch of noarch would mean that the package gets included on EVERY arch when we compose the distribution. There are two camps here, one is that "If your package only WORKS on a particular arch, it should be BuildArch'd there as to be tagged as such". The other camp is "If your package is comprised of noarch files (scripts), it must be marked as such." (and really a third workaround camp that is "You should use ExcludeArch rather than ExclusiveArch.) The build software team is on the fence about this, especially as it echos to packaging guidelines and we'd like to see some discussion out in the community regarding this issue, and hopefully some policy that we can follow. The way I see it, if your package is comprised of non-compiled arch independent content, it MUST be noarch. We can make our build system honor BuildArch: noarch and ExclusiveArch: i386 x86_64. This would be somewhat inline with doing BuildArch: noarch, ExcludeArch: foo bar baz baal, because ExcludeArch would still have 'noarch' in the list. I just don't want to see either A) having to list out every single possible arch this package may be built for, or B) screwing over folks like Aurora by only ExcludeArching the arches our build system would attempt, forcing folks like Aurora to edit spec files to do their rebuilds. A side question is, what does plague do in this scenario? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Jul 10 19:02:10 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 10 Jul 2006 22:02:10 +0300 Subject: [Fedora-packaging] To noarch or arch for arch specific script packages? In-Reply-To: <200607101301.43818.jkeating@redhat.com> References: <200607101301.43818.jkeating@redhat.com> Message-ID: <1152558130.2728.484.camel@localhost.localdomain> On Mon, 2006-07-10 at 13:01 -0400, Jesse Keating wrote: > The way I see it, if your package is comprised of non-compiled arch > independent content, it MUST be noarch. +1. Nitpick: "non-compiled" is misleading; compiled content can be arch independent (eg. *.pyc, *.pyo) and non-compiled content can be arch dependent (eg. due to install dirs or hardwired references to let's say /usr/lib64/...), so "arch independent" should suffice. > A side question is, what does plague do in this scenario? Someone more familiar with plague's internals should answer that, but I suppose it just builds the noarch package as usual [0]. For Extras the push scripts handle the noarch + ExclusiveArch/ExcludeArch combos so that the packages end up where wanted only. One example is mhonarc which is noarch, but due to (un)availability of some of its dependencies for the moment (#182514) is also marked ExcludeArch: x86_64, and is thus not available in the x86_64 repos. This setup makes sense to me. [0] FE noarch packages tend to end up being built in the ppc builders; I don't know what would happen with noarch + ExcludeArch: ppc. From jkeating at redhat.com Tue Jul 11 14:30:32 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Jul 2006 10:30:32 -0400 Subject: [Fedora-packaging] Single package directory ownership Message-ID: <200607111030.33173.jkeating@redhat.com> I'm running into a situation with this rule. The xorg package set. There is xorg-x11-server-Xorg, and a lot of xorg-x11-drv-foo packages. The drv packages drop files in /usr/lib/xorg/modules and /usr/lib/xorg/modules/drivers (lib64 for obvious places). However, xorg-x11-server-Xorg also puts files there. Normally we'd say that xorg-x11-server-Xorg must own those directories and not the drivers. BUT xorg-x11-server-Xorg requires drivers, drivers require Xorg, insert dep loop here. The X folks think that when RPM is faced with this, it will make an arbitrary decision at where to do the transaction, and there could be a case where xorg-x11-server-Xorg is removed before a drv package, and unless all the drv packages own the modules and drivers dirs, those directories could get left behind. Does this qualify as an exception to the single ownership rule? I've cc'd Mike and Ajax from the X team as they are not on this list. Please include them in CCs for the discussion (reply-all on smart clients). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Tue Jul 11 14:47:31 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 11 Jul 2006 15:47:31 +0100 Subject: [Fedora-packaging] Single package directory ownership In-Reply-To: <200607111030.33173.jkeating@redhat.com> References: <200607111030.33173.jkeating@redhat.com> Message-ID: <44B3BA03.1050703@city-fan.org> Jesse Keating wrote: > I'm running into a situation with this rule. > > The xorg package set. There is xorg-x11-server-Xorg, and a lot of > xorg-x11-drv-foo packages. The drv packages drop files > in /usr/lib/xorg/modules and /usr/lib/xorg/modules/drivers (lib64 for > obvious places). However, xorg-x11-server-Xorg also puts files there. > Normally we'd say that xorg-x11-server-Xorg must own those directories and > not the drivers. BUT xorg-x11-server-Xorg requires drivers, drivers require > Xorg, insert dep loop here. > > The X folks think that when RPM is faced with this, it will make an arbitrary > decision at where to do the transaction, and there could be a case where > xorg-x11-server-Xorg is removed before a drv package, and unless all the drv > packages own the modules and drivers dirs, those directories could get left > behind. > > Does this qualify as an exception to the single ownership rule? I've cc'd > Mike and Ajax from the X team as they are not on this list. Please include > them in CCs for the discussion (reply-all on smart clients). Why not introduce an xorg-x11-filesystem package that owns the directories and everything else can depend on? Paul. From tcallawa at redhat.com Tue Jul 11 14:48:43 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 11 Jul 2006 09:48:43 -0500 Subject: [Fedora-packaging] Single package directory ownership In-Reply-To: <200607111030.33173.jkeating@redhat.com> References: <200607111030.33173.jkeating@redhat.com> Message-ID: <1152629323.12430.198.camel@localhost.localdomain> On Tue, 2006-07-11 at 10:30 -0400, Jesse Keating wrote: > I'm running into a situation with this rule. > > The xorg package set. There is xorg-x11-server-Xorg, and a lot of > xorg-x11-drv-foo packages. The drv packages drop files > in /usr/lib/xorg/modules and /usr/lib/xorg/modules/drivers (lib64 for > obvious places). However, xorg-x11-server-Xorg also puts files there. > Normally we'd say that xorg-x11-server-Xorg must own those directories and > not the drivers. BUT xorg-x11-server-Xorg requires drivers, drivers require > Xorg, insert dep loop here. I'm no expert on Xorg, but I'm not sure why the Xorg server requires any drivers. While this is certainly the most common use case, is this really a hard requires? This looks to be a nasty dependency loop. > The X folks think that when RPM is faced with this, it will make an arbitrary > decision at where to do the transaction, and there could be a case where > xorg-x11-server-Xorg is removed before a drv package, and unless all the drv > packages own the modules and drivers dirs, those directories could get left > behind. Every single driver package requires xorg-x11-server-Xorg. RPM should never remove it before all the driver packages are gone. Even still, erase ordering is not properly implemented in any shipping version of RPM. This rule is designed to aid such code if it is ever written. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Tue Jul 11 15:00:48 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 11 Jul 2006 10:00:48 -0500 Subject: [Fedora-packaging] Single package directory ownership In-Reply-To: <200607111030.33173.jkeating@redhat.com> (Jesse Keating's message of "Tue, 11 Jul 2006 10:30:32 -0400") References: <200607111030.33173.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Does this qualify as an exception to the single ownership rule? Common sense trumps that rule rather often; basically you should never own something that deep core packages like filesystem own and you really shouldn't own something that is owned by packages you depend on. But Perl packages often end up owning the same directories when they're at the same place in the hierarchy but don't depend on each other. For X, though, we do have the xorg-x11-filesystem package. I'm wondering if we shouldn't treat it like the filesystem package, and have it own /usr/lib/xorg/modules and stuff under it. (Because of a package I'm reviewing, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174021, I wonder if /usr/share/X11/app-defaults shouldn't also be owned by the xorg-x11-filesystem package.) Then again it's quite possible I'm misunderstanding the purpose of that package. - J< From tibbs at math.uh.edu Tue Jul 11 15:02:43 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 11 Jul 2006 10:02:43 -0500 Subject: [Fedora-packaging] Single package directory ownership In-Reply-To: <44B3BA03.1050703@city-fan.org> (Paul Howarth's message of "Tue, 11 Jul 2006 15:47:31 +0100") References: <200607111030.33173.jkeating@redhat.com> <44B3BA03.1050703@city-fan.org> Message-ID: >>>>> "PH" == Paul Howarth writes: PH> Why not introduce an xorg-x11-filesystem package that owns the PH> directories and everything else can depend on? > rpm -ql xorg-x11-filesystem /usr/bin/xorg-x11-filesystem-upgrade /usr/include/X11 /usr/lib/X11 - J< From paul at city-fan.org Tue Jul 11 15:07:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 11 Jul 2006 16:07:22 +0100 Subject: [Fedora-packaging] Single package directory ownership In-Reply-To: References: <200607111030.33173.jkeating@redhat.com> <44B3BA03.1050703@city-fan.org> Message-ID: <44B3BEAA.2020006@city-fan.org> Jason L Tibbitts III wrote: >>>>>> "PH" == Paul Howarth writes: > > PH> Why not introduce an xorg-x11-filesystem package that owns the > PH> directories and everything else can depend on? > >> rpm -ql xorg-x11-filesystem > /usr/bin/xorg-x11-filesystem-upgrade > /usr/include/X11 > /usr/lib/X11 Great, we're halfway there already :-) Paul. From mharris at redhat.com Tue Jul 11 15:33:45 2006 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 11 Jul 2006 11:33:45 -0400 Subject: [Fedora-packaging] Single package directory ownership In-Reply-To: <1152629323.12430.198.camel@localhost.localdomain> References: <200607111030.33173.jkeating@redhat.com> <1152629323.12430.198.camel@localhost.localdomain> Message-ID: <44B3C4D9.6000703@redhat.com> Tom 'spot' Callaway wrote: > On Tue, 2006-07-11 at 10:30 -0400, Jesse Keating wrote: >> I'm running into a situation with this rule. >> >> The xorg package set. There is xorg-x11-server-Xorg, and a lot of >> xorg-x11-drv-foo packages. The drv packages drop files >> in /usr/lib/xorg/modules and /usr/lib/xorg/modules/drivers (lib64 for >> obvious places). However, xorg-x11-server-Xorg also puts files there. >> Normally we'd say that xorg-x11-server-Xorg must own those directories and >> not the drivers. BUT xorg-x11-server-Xorg requires drivers, drivers require >> Xorg, insert dep loop here. > > I'm no expert on Xorg, but I'm not sure why the Xorg server requires any > drivers. While this is certainly the most common use case, is this > really a hard requires? This looks to be a nasty dependency loop. Yep. The drivers require the server, at least in order to be useful for something. Technically the drivers do not use the server of course though. One could argue that the drivers do not /require/ the server, but that they just don't do anything useful if it is not around. The anaconda team requested that the X server rpm have some hard dependencies on certain specific drivers, to ensure that at least basic mouse/keyboard works even if all drivers are not installed. I don't remember the specifics of it, but jeremy could provide details. >> The X folks think that when RPM is faced with this, it will make an arbitrary >> decision at where to do the transaction, and there could be a case where >> xorg-x11-server-Xorg is removed before a drv package, and unless all the drv >> packages own the modules and drivers dirs, those directories could get left >> behind. > > Every single driver package requires xorg-x11-server-Xorg. RPM should > never remove it before all the driver packages are gone. > > Even still, erase ordering is not properly implemented in any shipping > version of RPM. This rule is designed to aid such code if it is ever > written. If you uninstall all of X entirely in one rpm transaction, I think rpm just uninstalls them in whatever order they're specified, or some other random order. This could result in the X server rpm which owns the dirs being removed before the driver packages which put files in them. Based on this understanding (which may or may not be correct, I haven't tested as of late), you could end up with the directory left behind after uninstallation of all of X. Not that that's a major issue, but it is a bit sloppy. If someone feels strong enough about the modules dir ownership being a problem though, it's easy to change the packages to comply with any Fedora packaging policies. Doesn't matter to me either way. -- Mike A. Harris, Systems Engineer, X11 Development team, Red Hat Canada, Ltd. From bugs.michael at gmx.net Wed Jul 12 10:14:38 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 12 Jul 2006 12:14:38 +0200 Subject: [Fedora-packaging] To noarch or arch for arch specific script packages? In-Reply-To: <200607101301.43818.jkeating@redhat.com> References: <200607101301.43818.jkeating@redhat.com> Message-ID: <20060712121438.ba6941e1.bugs.michael@gmx.net> On Mon, 10 Jul 2006 13:01:39 -0400, Jesse Keating wrote: > There exists packages that are written in say python, but are used for arch > specific task. Consider python scripts that deal with grub (i386/x86_64), or > other such things. Do we want to continue considering these 'noarch' > packages, or do we want to mark them as arch specific? They'll already have > the ExclusiveArch: i386 x86_64 or ExcludeArch in the spec. > > The reason I bring this up as it has tickled a possible bug in Brew, Red Hat's > build software. Currently brew will look at BuildArch and ExclusiveArch / > ExcludeArch, and the configured arches for a build target to decide where to > build the package at. In one package case, it has BuildArch: noarch, and > ExclusiveArch: i386 x86_64. Combining the two, brew is complaining that > Architecture is not included 'noarch'. This is a big mess, IMO. We've had it recently with freenx/nx, where a noarch package depends on an arch-specific package, which is not available for some archs. Since we copy noarch packages to all archs, this has lead to a broken dep. The enhanced push script evaluates ExcludeArch, but not ExclusiveArch, of the src.rpm and thereby complements the buildsys. "BuildArch: noarch" means it does not matter on which architecture the package may be built. And it enforces a ".noarch" marker in the package file name, which means that the package is for no particular arch. It can be installed without restrictions. All three tags, BuildArch, ExclusiveArch and ExcludeArch are build-time input. ExclusiveArch and ExcludeArch information is lost after rpmbuild. It does not enter the .noarch.rpm headers and remains only in the src.rpm. If the package is "ExclusiveArch: i386 x86_64", you cannot even build it as "noarch" on a different arch like ppc. It is like saying "the package contents are arch-independent but only for i386 and x86_64, since we tried that and know it doesn't work on ppc, ppc64, sparc and any other arch". What the heck? Then it is not noarch! Instead of combining BuildArch noarch and ExclusiveArch, just drop BuildArch noarch and create arch-specific packages. Especially if there is a dependency on other arch-specific packages. Else it would be abuse of tags. The only vaguely valid case is combining BuildArch noarch and ExcludeArch, which is like saying "by nature, the package contents are arch-independent, but we know that there is a problem on the N excluded archs". From jkeating at redhat.com Wed Jul 12 12:02:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 08:02:46 -0400 Subject: [Fedora-packaging] To noarch or arch for arch specific script packages? In-Reply-To: <20060712121438.ba6941e1.bugs.michael@gmx.net> References: <200607101301.43818.jkeating@redhat.com> <20060712121438.ba6941e1.bugs.michael@gmx.net> Message-ID: <200607120802.46993.jkeating@redhat.com> On Wednesday 12 July 2006 06:14, Michael Schwendt wrote: > Else it would be abuse of tags. The only vaguely valid case is combining > BuildArch noarch and ExcludeArch, which is like saying "by nature, the > package contents are arch-independent, but we know that there is a problem > on the N excluded archs". How far do you take this though? ExcludeArch: ppc ppc64 s390 s390x alpha sparc sparc64 ia64 arm ..... It starts to get silly when you have to guess at the arches that somebody may attempt to install your package for. Why would 'ExcludeArch' be ok, but 'ExclusiveArch' not be? ExclusiveArch says "I know it _only_ works here, nowhere else." where as ExcludeArch would be "These are the arches out in the world I know of, and I know it doesn't work there." I agree that we are overloading the tag. But if we're going to ban one method, we should ban them all and make it a hard rule that if your noarch code only works on specific arches, make it an arch specific package. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Wed Jul 12 12:28:54 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 12 Jul 2006 14:28:54 +0200 Subject: [Fedora-packaging] To noarch or arch for arch specific script packages? In-Reply-To: <200607120802.46993.jkeating@redhat.com> References: <200607101301.43818.jkeating@redhat.com> <20060712121438.ba6941e1.bugs.michael@gmx.net> <200607120802.46993.jkeating@redhat.com> Message-ID: <20060712142854.a41097d4.bugs.michael@gmx.net> On Wed, 12 Jul 2006 08:02:46 -0400, Jesse Keating wrote: > On Wednesday 12 July 2006 06:14, Michael Schwendt wrote: > > Else it would be abuse of tags. The only vaguely valid case is combining > > BuildArch noarch and ExcludeArch, which is like saying "by nature, the > > package contents are arch-independent, but we know that there is a problem > > on the N excluded archs". > > How far do you take this though? > > ExcludeArch: ppc ppc64 s390 s390x alpha sparc sparc64 ia64 arm ..... > > It starts to get silly when you have to guess at the arches that somebody may > attempt to install your package for. No, it is silly to not make the package arch-specific in that case. Your package excludes almost a dozen archs => it is not arch-independent! > Why would 'ExcludeArch' be ok, > but 'ExclusiveArch' not be? I tried to explain this in my previous reply. ExcludeArch => we know about problems with the explicitly excluded archs, we assume the package is okay for all other archs > ExclusiveArch says "I know it _only_ works here, > nowhere else." Then it is NOT noarch. > where as ExcludeArch would be "These are the arches out in the > world I know of, and I know it doesn't work there." Once more, ExcludeArch and ExclusiveArch are NOT information that can be found in the .noarch package. > I agree that we are overloading the tag. But if we're going to ban one > method, we should ban them all and make it a hard rule that if your noarch > code only works on specific arches, make it an arch specific package. Exactly. From smooge at gmail.com Wed Jul 12 16:32:12 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 12 Jul 2006 10:32:12 -0600 Subject: [Fedora-packaging] To noarch or arch for arch specific script packages? In-Reply-To: <200607120802.46993.jkeating@redhat.com> References: <200607101301.43818.jkeating@redhat.com> <20060712121438.ba6941e1.bugs.michael@gmx.net> <200607120802.46993.jkeating@redhat.com> Message-ID: <80d7e4090607120932u13a146c0y44174a2938530c18@mail.gmail.com> On 7/12/06, Jesse Keating wrote: > On Wednesday 12 July 2006 06:14, Michael Schwendt wrote: > > Else it would be abuse of tags. The only vaguely valid case is combining > > BuildArch noarch and ExcludeArch, which is like saying "by nature, the > > package contents are arch-independent, but we know that there is a problem > > on the N excluded archs". > > How far do you take this though? > > ExcludeArch: ppc ppc64 s390 s390x alpha sparc sparc64 ia64 arm ..... > If you have over 3 excluded architectures, you are arch specific. It is an arbitrary rule.. but sounds good to me. -- Stephen J Smoogen. CSIRT/Linux System Administrator From opensource at till.name Wed Jul 12 20:28:01 2006 From: opensource at till.name (Till Maas) Date: Wed, 12 Jul 2006 22:28:01 +0200 Subject: [Fedora-packaging] installation of info files Message-ID: <200607122228.01842.opensource@till.name> Hiyas, the guidelines do not mention how to install .info files the right way. At the moment there seem to be several scriptlets used to install them in %post and %preun. I want to suggest to define a rpm-macro that handles info files in the right way which also would reduce redundant lines of code in spec-files. Something like "%info" in the files section would be most useful in my oppionion, like it already exists for documentation (%doc). What are your oppionions about this? Regards, Till From chris.stone at gmail.com Wed Jul 12 20:36:27 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 12 Jul 2006 13:36:27 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: <20060710095844.GA14442@redhat.com> References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> <1152482379.2728.457.camel@localhost.localdomain> <20060710095844.GA14442@redhat.com> Message-ID: On 7/10/06, Joe Orton wrote: > On Sun, Jul 09, 2006 at 03:33:13PM -0700, Christopher Stone wrote: > > So I guess I will remove the underscores to be in line with the other > > language directory definitions. > > I've submitted a new php-pear to FC-5 testing which includes this latest > macros.pear; can you test this out? Thanks a lot for your work here. I rebuilt all my pear packages with the new php-pear and its macros and everything worked great. From toshio at tiki-lounge.com Wed Jul 12 23:14:21 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 12 Jul 2006 16:14:21 -0700 Subject: [Fedora-packaging] Packaging Committee Information Message-ID: <1152746061.5959.13.camel@localhost> I've started a page for packaging committee with the date and time of the meetings and other information. If you want to find out about the packaging committee go ahead and read it. If you're on the Packaging Committee and want to hack it, go ahead. If you don't have permission to edit the page but want something added or modified, send mail to fedora-packaging or hop onto #fedora-packaging on IRC. http://www.fedoraproject.org/wiki/Packaging/Committee -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Wed Jul 12 23:35:03 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 12 Jul 2006 18:35:03 -0500 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: (Christopher Stone's message of "Wed, 12 Jul 2006 13:36:27 -0700") References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> <1152482379.2728.457.camel@localhost.localdomain> <20060710095844.GA14442@redhat.com> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> I rebuilt all my pear packages with the new php-pear and its CS> macros and everything worked great. Good. So where are we at? We have nice macros which should be in FC5 soon. Which leaves: * FC4. Will these macros make it there, or do we just not target that release? * Guidelines. They need to be altered to take into account the existence of these new macros. * Modules neither PEAR nor PECL. We still need guidelines for this class of packages, if for no other reason than it would let me finish reviewing php-shout. * Specfile templates. We either need a template or fedora-newrpmspec should call into the specfile generator module. - J< From chris.stone at gmail.com Wed Jul 12 23:45:23 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 12 Jul 2006 16:45:23 -0700 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: References: <87fyhcjhkk.fsf@kosh.bigo.ensc.de> <1152482379.2728.457.camel@localhost.localdomain> <20060710095844.GA14442@redhat.com> Message-ID: On 7/12/06, Jason L Tibbitts III wrote: > >>>>> "CS" == Christopher Stone writes: > > CS> I rebuilt all my pear packages with the new php-pear and its > CS> macros and everything worked great. > > Good. So where are we at? We have nice macros which should be in FC5 > soon. Which leaves: > ... > * Specfile templates. We either need a template or fedora-newrpmspec > should call into the specfile generator module. I have created a bug for the php-pear-* template: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198706 From rc040203 at freenet.de Thu Jul 13 10:51:09 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 13 Jul 2006 12:51:09 +0200 Subject: [Fedora-packaging] installation of info files In-Reply-To: <200607122228.01842.opensource@till.name> References: <200607122228.01842.opensource@till.name> Message-ID: <1152787869.4569.131.camel@mccallum.corsepiu.local> On Wed, 2006-07-12 at 22:28 +0200, Till Maas wrote: > Hiyas, > > the guidelines do not mention how to install .info files the right way. At the > moment there seem to be several scriptlets used to install them in %post > and %preun. I want to suggest to define a rpm-macro that handles info files > in the right way which also would reduce redundant lines of code in > spec-files. Something like "%info" in the files section would be most useful > in my oppionion, like it already exists for documentation (%doc). > > What are your oppionions about this? Introducing such macros is a double sided sword: * On one hand, they to some extend ease writing specs. * On the other hand: - Once such macros have been introduced, it's very difficult to get rid of them, should one want to abandon such macros. In many cases, you will have to continue to provide them for a very long (many years) transitional time period. Rpm itself is full of semi-functional/once thought to be useful macros, nowadays almost nobody uses. - Vendor-specific macros are a major obstacle to spec file portability. This isn't of much importance within a distribution, but is of importance for 3rd parties who want to provide add-on/drop-in rpms. SuSE and Mandrake users probably are aware about the (often unresolvable) problems such macros introduce, because these distros tend use them extensively. => IMO, in general such macros should be avoided as far as possible. In an ideal world all macros should either be provided by vendor independent packages, or as part of by rpm itself. Ralf From ville.skytta at iki.fi Thu Jul 13 18:45:36 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 13 Jul 2006 21:45:36 +0300 Subject: [Fedora-packaging] installation of info files In-Reply-To: <1152787869.4569.131.camel@mccallum.corsepiu.local> References: <200607122228.01842.opensource@till.name> <1152787869.4569.131.camel@mccallum.corsepiu.local> Message-ID: <1152816336.6622.10.camel@localhost.localdomain> On Thu, 2006-07-13 at 12:51 +0200, Ralf Corsepius wrote: > Introducing such macros is a double sided sword: [...] Agreed. Regarding the case at hand, in case someone's thinking about submitting an RFE somewhere, FWIW Mandriva has had macros for installing and removing info files for a long time, they're defined as: %__install_info /sbin/install-info %_extension .bz2 %_install_info() if [[ -f %{_infodir}/%{1}%{_extension} ]];then %{__install_info} %{_infodir}/%{1}%{_extension} --dir=%{_infodir}/dir;fi \ %{nil} %_remove_install_info() if [ "$1" = "0" ]; then if [[ -f %{_infodir}/%{1}%{_extension} ]];then %{__install_info} %{_infodir}/%{1}%{_extension} --dir=%{_infodir}/dir --remove ;fi; fi \ %{nil} The naming (%_extension, %_remove_install_info) is unfortunate and other nitpicks could be said, but perhaps these are useful as a starting point. From orion at cora.nwra.com Thu Jul 13 19:13:18 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 13 Jul 2006 13:13:18 -0600 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <44A9026F.1050903@timj.co.uk> <20060704103743.GA30570@redhat.com> <1152029074.14439.15.camel@localhost.localdomain> <1152030596.16687.2.camel@localhost.localdomain> Message-ID: <44B69B4E.2010906@cora.nwra.com> Christopher Stone wrote: > On 7/4/06, Jason L Tibbitts III wrote: >> >>>>> "CS" == Christopher Stone writes: > >> [Smarty] >> CS> If there is something wrong with installing it in >> CS> %_datadir, where should it go instead? >> >> Well, thankfully every Perl and Python class library doesn't go in >> %_datadir; we'd have thousands and thousands of directories there. >> Why not some PHP-specific place? > > /usr/share/php/Smarty is definately smarter ;-) > Will php own /usr/share/php ? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 13 19:28:26 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 13 Jul 2006 21:28:26 +0200 Subject: [Fedora-packaging] installation of info files In-Reply-To: <1152816336.6622.10.camel@localhost.localdomain> (Ville Skytt's message of "Thu, 13 Jul 2006 21:45:36 +0300") References: <200607122228.01842.opensource@till.name> <1152787869.4569.131.camel@mccallum.corsepiu.local> <1152816336.6622.10.camel@localhost.localdomain> Message-ID: <87d5c9nw2t.fsf@kosh.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: > Regarding the case at hand, in case someone's thinking about submitting > an RFE somewhere, FWIW Mandriva has had macros for installing and > removing info files for a long time, they're defined as: > > %__install_info /sbin/install-info > > %_extension .bz2 install-info is smart enough to add at least '.gz' when needed. Hence the %_extension macro is not needed. > %_install_info() if [[ -f %{_infodir}/%{1}%{_extension} ]];then %{__install_info} %{_infodir}/%{1}%{_extension} --dir=%{_infodir}/dir;fi \ > %{nil} > > %_remove_install_info() if [ "$1" = "0" ]; then if [[ -f %{_infodir}/%{1}%{_extension} ]];then %{__install_info} %{_infodir}/%{1}%{_extension} --dir=%{_infodir}/dir --remove ;fi; fi \ > %{nil} I used | %__install_info /sbin/install-info --info-dir=%_infodir | %__install_info_post g() { %__install_info "$@" || :; }; g | %__install_info_preun g() { %__install_info --delete "$@" || :; }; test "$1" != 0 || g some time ago. I do not see much sense in the test-for-existence check; when a packager uses | %__install_info_post %_infodir/zsh.info he knows that 'zsh.info' exists there (else, package would be broken). I am not sure about automatic detection of pre/postun requires; perhaps a similar approach like for fedora-usermgmt can be chosen and | %FE_INSTALL_INFO_REQ \ | Requires(pre): %__install_info \ | Requires(postun): %__install_info defined which is applied like | BuildRequires: package-with-these-macros | %{?FE_INSTALL_INFO_REQ} Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Christian.Iseli at licr.org Thu Jul 13 22:09:03 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 14 Jul 2006 00:09:03 +0200 Subject: [Fedora-packaging] installation of info files In-Reply-To: Your message of "Thu, 13 Jul 2006 21:28:26 +0200." <87d5c9nw2t.fsf@kosh.bigo.ensc.de> Message-ID: <200607132209.k6DM94eM001094@mx1.redhat.com> enrico.scholz at informatik.tu-chemnitz.de said: > I do not see much sense in the test-for-existence check; > when a packager uses > | %__install_info_post %_infodir/zsh.info > he knows that 'zsh.info' exists there (else, package would be broken). Hrm, not sure here, but what about --excludedocs ? Christian From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 13 22:22:05 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 14 Jul 2006 00:22:05 +0200 Subject: [Fedora-packaging] installation of info files In-Reply-To: <200607132209.k6DM94eM001094@mx1.redhat.com> (Christian Iseli's message of "Fri, 14 Jul 2006 00:09:03 +0200") References: <87d5c9nw2t.fsf@kosh.bigo.ensc.de> <200607132209.k6DM94eM001094@mx1.redhat.com> Message-ID: <87veq1m9gy.fsf@kosh.bigo.ensc.de> Christian.Iseli at licr.org writes: >> I do not see much sense in the test-for-existence check; >> when a packager uses >> | %__install_info_post g() { %__install_info "$@" || :; }; g >> | ... >> | %__install_info_post %_infodir/zsh.info >> he knows that 'zsh.info' exists there (else, package would be broken). > > Hrm, not sure here, but what about --excludedocs ? Not really a problem; the command has a '|| :' making the scriptlet succeed. When you would want to handle missing files (--excludedocs or --excludepaths), you would have to handle read-only %netsharedpath mounts too (which would make install-info fail). My (real) original macro was | %define __isDirectoryShared f() { rpm --eval '%%{_netsharedpath}' | awk -v y="$1" '{ split($1, x, ":"); for (i in x) if (index(y,x[i])==1) exit 0; exit 1; }'; }; fi | %define __install_info ( %__isDirectoryShared %_infodir ) || /sbin/install-info --info-dir=%_infodir but it is not really worth the effort because e.g. 'rpm' might be missing in chroot environments and rpm maintainer refuses to add functionality allowing to detect whether path is covered by %netsharedpath resp. missing due to --exclude*. Perhaps a '2>/dev/null' should be added. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From toshio at tiki-lounge.com Fri Jul 14 01:28:32 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 13 Jul 2006 18:28:32 -0700 Subject: [Fedora-packaging] Java Naming Page Message-ID: <1152840512.6818.9.camel@localhost> I've added a Java Naming page to PackagingDrafts:: http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming Feel free to review it and see if I've missed anything, misstated the effects of naming according to a certain proposal, etc. I think before anything can be decided we have to identify which of the goals on that page (and any others that might be out there) are real goals and which are not. As lutter said, if it really is a goal to allow interleaved updates between Fedora and jpackage repositories, then the releases have to start with the jpackage version. I have more ideas to place under the discussion sections but I'm going home to deal with termites and a clogged sewer line so I might not get to it for a while. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 14 06:33:26 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 14 Jul 2006 08:33:26 +0200 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <1152840512.6818.9.camel@localhost> (Toshio Kuratomi's message of "Thu, 13 Jul 2006 18:28:32 -0700") References: <1152840512.6818.9.camel@localhost> Message-ID: <87hd1kg0g9.fsf@kosh.bigo.ensc.de> toshio at tiki-lounge.com (Toshio Kuratomi) writes: > http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming > > Feel free to review it and see if I've missed anything, misstated the > effects of naming according to a certain proposal, etc. | 1. Allow for upgrading between the Fedora and JPackage repositories so | that upgrade paths similar to the following works: This will be needed for the first installation of a Java package from FE only. Then, I see the following two situations: 1. user enabled on FE repository --> jpackage versioning is uninteresting 2. user enabled both FE and JPackage repositories --> When FE packager is a little bit behind, jpackage packages will override FE packags again. This would render JPackages in FE useless. General versioniong rules for mixing repositories are impossible so I suggest to ignore the jpackage Release: resp. just make sure that first FE package wins against the original JPackage package. | 2. Allow packagers to tell what JPackage release the java package was | based against. I do not think that this must be expressed with Release:; you could document this somewhere else (%description) or write | Provides: jpackage(%name) = %jpackage_version-%jpackage_release Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From smooge at gmail.com Fri Jul 14 14:28:10 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 14 Jul 2006 08:28:10 -0600 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <87hd1kg0g9.fsf@kosh.bigo.ensc.de> References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> Message-ID: <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> On 7/14/06, Enrico Scholz wrote: > toshio at tiki-lounge.com (Toshio Kuratomi) writes: > > > http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming > > > > Feel free to review it and see if I've missed anything, misstated the > > effects of naming according to a certain proposal, etc. > > | 1. Allow for upgrading between the Fedora and JPackage repositories so > | that upgrade paths similar to the following works: > > This will be needed for the first installation of a Java package from FE > only. Then, I see the following two situations: > > 1. user enabled on FE repository > --> jpackage versioning is uninteresting > > 2. user enabled both FE and JPackage repositories > --> When FE packager is a little bit behind, jpackage packages will > override FE packags again. This would render JPackages in FE > useless. > > General versioniong rules for mixing repositories are impossible so I > suggest to ignore the jpackage Release: resp. just make sure that first > FE package wins against the original JPackage package. > > > | 2. Allow packagers to tell what JPackage release the java package was > | based against. > > I do not think that this must be expressed with Release:; you could > document this somewhere else (%description) or write > > | Provides: jpackage(%name) = %jpackage_version-%jpackage_release > Would it be better to look at the java packages being a seperate repo with its own naming standards? Anaconda could aim at these packages in their own on disk repo and a fuller jpackage repo could be included on the download sites. -- Stephen J Smoogen. CSIRT/Linux System Administrator From nicolas.mailhot at laposte.net Fri Jul 14 14:42:32 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Jul 2006 16:42:32 +0200 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> Message-ID: <1152888152.3087.5.camel@rousalka.dyndns.org> Le vendredi 14 juillet 2006 ? 08:28 -0600, Stephen John Smoogen a ?crit : > Would it be better to look at the java packages being a seperate repo > with its own naming standards? Anaconda could aim at these packages in > their own on disk repo and a fuller jpackage repo could be included on > the download sites. I think it would suck for everyone involved if Java was segregated in its own Fedora sandbox just before FLOSS java stacks reach API parity with closed ones. Really in a few years users should be able to install cool apps without having to care whether they're written in C, C++, python, Java, C# of whatever. You can't talk about perl without taking CPAN into account, you can't talk about Java without taking JPP into account, that's not reason enough to move perl or java to separate repositories. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tibbs at math.uh.edu Fri Jul 14 15:48:10 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 14 Jul 2006 10:48:10 -0500 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <1152888152.3087.5.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Fri, 14 Jul 2006 16:42:32 +0200") References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> Message-ID: I wonder how this discussion would go if we did s/Jpackage/DAG/ (or AT, or RPMForge, or any other external repository) and s/jpp/dag/. I mean, honestly, how is the situation really all that different? - J< From nicolas.mailhot at laposte.net Fri Jul 14 16:39:17 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Jul 2006 18:39:17 +0200 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> Message-ID: <1152895157.3087.17.camel@rousalka.dyndns.org> Le vendredi 14 juillet 2006 ? 10:48 -0500, Jason L Tibbitts III a ?crit : > I wonder how this discussion would go if we did s/Jpackage/DAG/ (or > AT, or RPMForge, or any other external repository) and s/jpp/dag/. I > mean, honestly, how is the situation really all that different? What's different is the package inter-dependencies. You can take bits from dag or rpmforge and import them in fedora one after the other because they are mostly independant apps (plus many more people know C or perl packaging than java packaging) You can not do the same for jpackage, you have a lot of fine-grained dependencies reaching several levels up to the jvm (so when the jvm changes you need a full synchronised rebuild or even spec rewrite like what's is happening right now in rawhide for C/C++ packages). Swallowing 500 packages at once, and them updating them is a large work. So large the effort is currently pooled at the jpackage level by rpm distros, and the fedora java group tries to minimise fc/jpp differences so they don't have to do it all by themselves. Take one of the rpm the dependency graphers and run it on jpp repo, it will enlighten you. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From toshio at tiki-lounge.com Fri Jul 14 16:44:06 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 14 Jul 2006 09:44:06 -0700 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> Message-ID: <1152895446.3010.21.camel@localhost> On Fri, 2006-07-14 at 10:48 -0500, Jason L Tibbitts III wrote: > I wonder how this discussion would go if we did s/Jpackage/DAG/ (or > AT, or RPMForge, or any other external repository) and s/jpp/dag/. I > mean, honestly, how is the situation really all that different? Nearly all of the java packages in Core are ongoing ports of JPackage. At least some of the Core Java Packagers are the JPackage packagers. They make changes to the JPackage package and then copy the changes back to Core. As Nicolas has expressed, JPackage is Core's immediate upstream for these packages. Core has adopted the JPackage methodology because they have intelligent, well thought out rules that don't conflict with the distro. So JPackage _is_ special. The question for me is not whether there is a special relationship but what goals we actually want to meet for users and developers using our packages and which of those goals need to map into changes to the Package Naming Guidelines and which can be achieved in alternate fashion. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri Jul 14 17:55:27 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 14 Jul 2006 12:55:27 -0500 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <1152895157.3087.17.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Fri, 14 Jul 2006 18:39:17 +0200") References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> <1152895157.3087.17.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> What's different is the package inter-dependencies. So they get to violate our in-place packaging and naming conventions? Just because they have lots of dependencies? Yes, I'm being deliberately difficult. But I think the point is valid; jpackage is special because it's special, and we have to decide whether we're going to eat it. And if we do eat it, what happens when the next pile of "special" packages comes along? - J< From nicolas.mailhot at laposte.net Fri Jul 14 18:21:12 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Jul 2006 20:21:12 +0200 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> <1152895157.3087.17.camel@rousalka.dyndns.org> Message-ID: <1152901272.3087.45.camel@rousalka.dyndns.org> Le vendredi 14 juillet 2006 ? 12:55 -0500, Jason L Tibbitts III a ?crit : > >>>>> "NM" == Nicolas Mailhot writes: > > NM> What's different is the package inter-dependencies. > > So they get to violate our in-place packaging and naming conventions? > Just because they have lots of dependencies? Our naming conventions are not tables of law, they were written to solve specific problems and the people who wrote them didn't think about this particular case, so now they'll have to think about it, come with a solution, put it in the guidelines and everyone will be happy. Instead of screaming "they're not following the holy guidelines" please spent 5s thinking about what the guidelines are about (solve technical problems). I'd have thought the somewhat irritated intervention of Paul Nasrat and all the posts about technicalities vs ?sthetics would have make all this clean. (and BTW these people don't _need_ the guidelines, they were doing inter-repo multi-package-updater updates when Fedora Core was still thinking "the next anaconda run will clean it all") -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From toshio at tiki-lounge.com Fri Jul 14 18:42:49 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 14 Jul 2006 11:42:49 -0700 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <87hd1kg0g9.fsf@kosh.bigo.ensc.de> References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> Message-ID: <1152902569.3010.43.camel@localhost> On Fri, 2006-07-14 at 08:33 +0200, Enrico Scholz wrote: > toshio at tiki-lounge.com (Toshio Kuratomi) writes: > > > http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming > > > > Feel free to review it and see if I've missed anything, misstated the > > effects of naming according to a certain proposal, etc. > > | 1. Allow for upgrading between the Fedora and JPackage repositories so > | that upgrade paths similar to the following works: > > This will be needed for the first installation of a Java package from FE > only. Then, I see the following two situations: > > 1. user enabled on FE repository > --> jpackage versioning is uninteresting > > 2. user enabled both FE and JPackage repositories > --> When FE packager is a little bit behind, jpackage packages will > override FE packags again. This would render JPackages in FE > useless. > > General versioniong rules for mixing repositories are impossible so I > suggest to ignore the jpackage Release: resp. just make sure that first > FE package wins against the original JPackage package. > The way I understand it, fnasser says this goal _is_ to make Fedora and jpackage override each other depending on who has the newer jpackage base. The argument is that when the jpackage packager is more on top of making fixes than the Fedora maintainer, the end user gets those fixes quicker. Once the Fedora maintainer rebases to the new jpackage, the Fedora package takes precedence again. The counter argument is that the Fedora Package has patches local to Fedora (sometimes bugfixes that jpackage wants to fix a different way at a later time, many times Ahead of time compiling to native libraries) and upgrading to the jpackage will lose these changes. > > | 2. Allow packagers to tell what JPackage release the java package was > | based against. > > I do not think that this must be expressed with Release:; you could > document this somewhere else (%description) or write > > | Provides: jpackage(%name) = %jpackage_version-%jpackage_release I've added this to the wiki page under both discussion of the goals and as part of the proposal for keeping things the way they are. If I've misrepresented anything there, feel free to correct it. http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri Jul 14 19:21:41 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 14 Jul 2006 14:21:41 -0500 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <1152901272.3087.45.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Fri, 14 Jul 2006 20:21:12 +0200") References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> <1152895157.3087.17.camel@rousalka.dyndns.org> <1152901272.3087.45.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> Instead of screaming "they're not following the holy guidelines" NM> please spent 5s thinking about what the guidelines are about NM> (solve technical problems). I spent a whole lot longer than five seconds, honestly. It's not about the holy guidelines, it's about taking something that's relatively clean and piling stuff on top of it for zero benefit. This whole thing is about getting clean packages. The jpackage stuff I've worked with in Extras actually looks reasonable once you take out all of the stuff that has no use in Extras. NM> I'd have thought the somewhat irritated intervention of Paul NM> Nasrat and all the posts about technicalities vs ?sthetics would NM> have make all this clean. Honestly, not to me. - J< From toshio at tiki-lounge.com Fri Jul 14 19:22:20 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 14 Jul 2006 12:22:20 -0700 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <1152901272.3087.45.camel@rousalka.dyndns.org> References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> <1152895157.3087.17.camel@rousalka.dyndns.org> <1152901272.3087.45.camel@rousalka.dyndns.org> Message-ID: <1152904940.3010.74.camel@localhost> On Fri, 2006-07-14 at 20:21 +0200, Nicolas Mailhot wrote: > Le vendredi 14 juillet 2006 ? 12:55 -0500, Jason L Tibbitts III a > ?crit : > > >>>>> "NM" == Nicolas Mailhot writes: > > > > NM> What's different is the package inter-dependencies. > > > > So they get to violate our in-place packaging and naming conventions? > > Just because they have lots of dependencies? > > Our naming conventions are not tables of law, they were written to solve > specific problems and the people who wrote them didn't think about this > particular case, so now they'll have to think about it, come with a > solution, put it in the guidelines and everyone will be happy. > > Instead of screaming "they're not following the holy guidelines" please > spent 5s thinking about what the guidelines are about (solve technical > problems). > I agree. I'm not yet convinced that _they're_ solving a problem, though. There are definite drawbacks to interleaving packages with the jpackage repositories. On -maintainers I pointed to some @rh packagers who aren't onboard with the interleaved strategy and I think lutter is dropping a line onto the internal rh list to get feedback from them and the other rh-java packagers as to whether interleaving is a goal or not. > I'd have thought the somewhat irritated intervention of Paul Nasrat Err Paul Nasrat? Which post, which list? (If you meant fnasser, then I know what you're talking about.) > and > all the posts about technicalities vs ?sthetics would have make all this > clean. > If interleaving is not a goal, then I don't see a reason to change the guidelines. Consistency is a technical goal; not an aesthetic one. In the absence of a conflicting technical goal this is what we should go with. > (and BTW these people don't _need_ the guidelines, they were doing > inter-repo multi-package-updater updates when Fedora Core was still > thinking "the next anaconda run will clean it all") _We_ need the guidelines. Look at the proliferation of ways that snapshot dates are added to the release field in jpackage. Now imagine how many new packagers and package reviewers are going to build packages that break the upgrade path if we allow all of that into naming. It's also bad for a reviewer when we have two different sets of guidelines for naming. If this is a JPackage derived package, you have to check that NEVR fits into the JPackage rules for naming followed by a proper Fedora Named tag. Otherwise use the Fedora Naming Guidelines to decide if NEVR is correct. Or do we just assume that jpackage has always caught bad naming? So we're left holding the bag when something goes wrong? (cryptix-asn1-20011119) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Fri Jul 14 19:53:09 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Jul 2006 21:53:09 +0200 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <1152904940.3010.74.camel@localhost> References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> <1152895157.3087.17.camel@rousalka.dyndns.org> <1152901272.3087.45.camel@rousalka.dyndns.org> <1152904940.3010.74.camel@localhost> Message-ID: <1152906789.3087.88.camel@rousalka.dyndns.org> Le vendredi 14 juillet 2006 ? 12:22 -0700, Toshio Kuratomi a ?crit : > On Fri, 2006-07-14 at 20:21 +0200, Nicolas Mailhot wrote: > > Instead of screaming "they're not following the holy guidelines" please > > spent 5s thinking about what the guidelines are about (solve technical > > problems). > > > I agree. I'm not yet convinced that _they're_ solving a problem, > though. > > I'd have thought the somewhat irritated intervention of Paul Nasrat > > Err Paul Nasrat? Which post, which list? (If you meant fnasser, then I > know what you're talking about.) I though Paul had written something yesterday, but there's so many messages on this thread on multiple lists I'm too lazy to check it. Let's say Fernando then. > > and > > all the posts about technicalities vs ?sthetics would have make all this > > clean. > > > > If interleaving is not a goal, then I don't see a reason to change the > guidelines. Then ask Fernando if he needs interleaving. > > (and BTW these people don't _need_ the guidelines, they were doing > > inter-repo multi-package-updater updates when Fedora Core was still > > thinking "the next anaconda run will clean it all") > > _We_ need the guidelines. Look at the proliferation of ways that > snapshot dates are added to the release field in jpackage. Now imagine > how many new packagers and package reviewers are going to build packages > that break the upgrade path if we allow all of that into naming. Sure; JPackage releases use lots of "dangerous" constructs because they have experienced packages who won't abuse them to the point things break, but this is not the case in Extras. So it's be probably safer is JPP changed its own releases to pure FC conventions (I mean upstream release before they're stacked and interleaved at Fedora). But you need to realise it's a lot of work for them with zero technical benefit, and there are many nicer ways to ask than make them some sort of scapegoat > > It's also bad for a reviewer when we have two different sets of > guidelines for naming. If this is a JPackage derived package, you have > to check that NEVR fits into the JPackage rules for naming followed by a > proper Fedora Named tag. Otherwise use the Fedora Naming Guidelines to > decide if NEVR is correct. In this particular case it's more release = jpp release + fedora release, but Fedora has clearly a voice on what jpp release is, if only via all the fc packagers which are also jpp members. However when the fedora jpp members explain to their mandrake or suse friends what changes need to be made, they need better arguments than "because" > Or do we just assume that jpackage has always caught bad naming? So > we're left holding the bag when something goes wrong? > (cryptix-asn1-20011119) I think this one is already fixed in JPP 1.7 and 5.0. But anyway: no you're not left holding the bag, you report the problem either to the fedora java team or directly to jpp, and as responsible maintainers they'll fix up their stuff. They're not packager newbies you need to herd through draconian rules, and they'll react better to a technical analysis than to a "just do it, we don"t need to explain" (been hurt before by the fedora.us epoch policy changes for example) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From toshio at tiki-lounge.com Fri Jul 14 20:14:20 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 14 Jul 2006 13:14:20 -0700 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> <1152895157.3087.17.camel@rousalka.dyndns.org> Message-ID: <1152908061.3010.101.camel@localhost> On Fri, 2006-07-14 at 12:55 -0500, Jason L Tibbitts III wrote: > >>>>> "NM" == Nicolas Mailhot writes: > > NM> What's different is the package inter-dependencies. > > So they get to violate our in-place packaging and naming conventions? > Just because they have lots of dependencies? > > Yes, I'm being deliberately difficult. But I think the point is > valid; jpackage is special because it's special, and we have to decide > whether we're going to eat it. And if we do eat it, what happens when > the next pile of "special" packages comes along? JPackage is special because of the way we let them do most of the work building the packages and we are using their packaging standards which make java portable (between distros) and pluggable (between java stacks). As long as we use their framework for making java packages we need to figure out how to make things work with that framework. The question is how does naming impact that framework? Are those areas important to us? Are there already other things impacting those areas so naming won't affect things one way or the other? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Fri Jul 14 21:04:50 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 14 Jul 2006 14:04:50 -0700 Subject: [Fedora-packaging] Java Naming Page In-Reply-To: <1152906789.3087.88.camel@rousalka.dyndns.org> References: <1152840512.6818.9.camel@localhost> <87hd1kg0g9.fsf@kosh.bigo.ensc.de> <80d7e4090607140728q7c7ad0f9te62fcd777bbc74ce@mail.gmail.com> <1152888152.3087.5.camel@rousalka.dyndns.org> <1152895157.3087.17.camel@rousalka.dyndns.org> <1152901272.3087.45.camel@rousalka.dyndns.org> <1152904940.3010.74.camel@localhost> <1152906789.3087.88.camel@rousalka.dyndns.org> Message-ID: <1152911090.3010.140.camel@localhost> On Fri, 2006-07-14 at 21:53 +0200, Nicolas Mailhot wrote: > Le vendredi 14 juillet 2006 ? 12:22 -0700, Toshio Kuratomi a ?crit : > > On Fri, 2006-07-14 at 20:21 +0200, Nicolas Mailhot wrote: > > > and > > > all the posts about technicalities vs ?sthetics would have make all this > > > clean. > > > > > > > If interleaving is not a goal, then I don't see a reason to change the > > guidelines. > > Then ask Fernando if he needs interleaving. > ...and gbenson and Tom Fitzsimmons and... Some people interleave upstream rpm with the distro. That doesn't make it the right choice for Red Hat to support that. The java team as a whole needs to make this decision and tell us, "Interleaving with jpackage is important to us. Please ratify a naming scheme that allows that." or "Interleaving causes the same problems here as elsewhere. We don't support it." That's why lutter is emailing the java team. > > > (and BTW these people don't _need_ the guidelines, they were doing > > > inter-repo multi-package-updater updates when Fedora Core was still > > > thinking "the next anaconda run will clean it all") > > > > _We_ need the guidelines. Look at the proliferation of ways that > > snapshot dates are added to the release field in jpackage. Now imagine > > how many new packagers and package reviewers are going to build packages > > that break the upgrade path if we allow all of that into naming. > > Sure; JPackage releases use lots of "dangerous" constructs because they > have experienced packages who won't abuse them to the point things > break, but this is not the case in Extras. So it's be probably safer is > JPP changed its own releases to pure FC conventions (I mean upstream > release before they're stacked and interleaved at Fedora). But you need > to realise it's a lot of work for them with zero technical benefit, and > there are many nicer ways to ask than make them some sort of scapegoat > Yep. That's why I emphasized "We". Most of what I wrote was written with the status quo in mind. If JPackage is willing to change their guidelines it could make things easier. If a flaw in the Naming Guidelines is discovered we'd have to discuss it here and with JPackage to get it changed... probably not a big deal as (Hopefully) we'd only have small changes that concerned corener cases from now on. > > > > It's also bad for a reviewer when we have two different sets of > > guidelines for naming. If this is a JPackage derived package, you have > > to check that NEVR fits into the JPackage rules for naming followed by a > > proper Fedora Named tag. Otherwise use the Fedora Naming Guidelines to > > decide if NEVR is correct. > > In this particular case it's more release = jpp release + fedora > release, but Fedora has clearly a voice on what jpp release is, if only > via all the fc packagers which are also jpp members. > > However when the fedora jpp members explain to their mandrake or suse > friends what changes need to be made, they need better arguments than > "because" > That's a given. We have to explain to the rest of Extras why we make changes to the present rules as well. > > Or do we just assume that jpackage has always caught bad naming? So > > we're left holding the bag when something goes wrong? > > (cryptix-asn1-20011119) > > I think this one is already fixed in JPP 1.7 and 5.0. > But anyway: no you're not left holding the bag, you report the problem > either to the fedora java team or directly to jpp, and as responsible > maintainers they'll fix up their stuff. > Maybe it was replaced (Or I'm looking in the wrong jpackage trees). It's in the 1.6 repo but I couldn't find it in the 1.7. > They're not packager newbies you need to herd through draconian rules, > and they'll react better to a technical analysis than to a "just do it, > we don"t need to explain" (been hurt before by the fedora.us epoch > policy changes for example) No they aren't. But we have lots that are. So new packager comes along and proposes a new java package in our bugzilla. Now what? A) We send new packager up to get the package into jpackage first which increases the work he has to do and rules he has to learn but hopefully makes him a better packager and then he'll come back and resubmit the new package to us. B) We let someone try their hand at reviewing the package. They apply the Fedora Guidelines to it because it's not based on a JPackage package. It's approved. Later JPackage adds the package to their repository and we have a version within Fedora space that's different from the JPackage one but that happens with any other package as well. C) We let someone try their hand at reviewing. They're a newly sponsored packager they stumble over different sets of rules from us and jpackage and approve something with problematic versions and releases because the jpackage rules allow it and neither the packager nor the reviewer had the experience to see the problems. Changes to the NEVR require an epoch bump. Packages for jpackage, when they appear, have to know that Fedora Extras has a package with epochs otherwise they will never upgrade the Fedora Package. I think A & B are fine (although I think A is going to be troublesome if we want to encourage more people to become packagers -- people say the complexity of getting a package into just Fedora Extras is bad enough.) C is what I want to avoid by keeping the naming guidelines as strict as possible. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue Jul 18 16:53:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 18 Jul 2006 18:53:53 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153223974.2594.3.camel@bureau.maison> References: <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153206620.2605.2.camel@bureau.maison> <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> Message-ID: <20060718165353.GB5874@neu.nirvana> On Tue, Jul 18, 2006 at 01:59:34PM +0200, Eric Tanguy wrote: > > kernels=`rpm -qf /boot/vmlinuz-* | grep -v "^file .* is not owned by any package"` > > uname_rs=`rpm -ql $kernels | grep ^/boot/vmlinuz- | sed -e's,^/boot/vmlinuz-\(.*\)$,\1,'` > > for kmdl in `rpm -qa \*kmdl\* | sed -e's,-kmdl-.*,-kmdl,' | sort -u`; > > do > > for uname_r in $uname_rs; do > > package=${kmdl}-$uname_r > > rpm -q $package > /dev/null 2>&1 || echo $package > > done > > done | xargs -r smart install -y > > Ok this script seems to use smart. is it working with yum ? Yes, I think "smart install -y" -> "yum -y install" is the only change needed. And for apt it would be "apt-get -y install". > How is this problem handled by livna because it works fine using > this repo : the kernel modules are installed and not updated > It's known that there are issues with this scheme, or any scheme > that will merge module and kernel versions. rpm for one can't cope with it. Suppose you have two active kernels (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have foo-kmdl for both in version 1. Now foo-kmdl in version 2 is released. Both rpm -i (coinstall, no replacement of of foo-kmdl for the same kernel) and rpm -U (remove all foo-kmdl but the highest one, e.g. at least one kernel stay w/o any kmdl) won't work. yum/smart/apt can be tought to be more clever than rpm and try to do the proper thing, which they will only be able to do if the merged versions are distangled again, e.g. hidden in Provides: and the like. So in order for a merged-version scheme to work there is special handling neccessary (and for atrpms' system, too, but read on). I prefer to have rpm itself already do something sensible and since it can only upgrade one versioning system (e.g. either the kernel's or the module's) it's preferable to allow it to upgrade the module within the same kernel and not touch the cross-kernel boundaries. "No harm done" like accidentially removing kmdls for other kernels or coinstalling several kmdls for the same kernel. You "only" need to reinstall the missing kmdl upon each kernel upgrade. It's far easier to get this into the brains of yum/smart/apt (e.g. translate the 9 lines of bash above into plugings/hooks for these depsolvers) or simply use the 9liner above than have a scheme which is broken at the level of rpm. Incidentially one on my personal targets is to get thie discussed in the fedora packaging group and review the currently scheme. Of course, I'm proposing adoption of ATrpms' kmdl scheme :) http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo > when i install a new kernel and are removed when the kernel is > removed. How the dependencies to the kernel are installed (which is responsible for having an automatic removal on kernel removal) is a different story, which the version merging does not break. The issue is with the system (system=rpm and(or any higher depsolver tool, e.g. yum/smart/apt) being able to distinguish different foo-kmdls as _upgrades_ vs _coinstalls_. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jul 18 17:29:54 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 18 Jul 2006 19:29:54 +0200 Subject: [Fedora-packaging] Minutes/Logs of 20060713 anyone? Message-ID: <20060718172954.GF5874@neu.nirvana> Hi, I couldn't make it to the last IRC meeting, does anyone have the logs/minutes? If so could you send them to me or even better upload to http://www.fedoraproject.org/wiki/Packaging/Minutes? Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Tue Jul 18 20:10:38 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 18 Jul 2006 13:10:38 -0700 Subject: [Fedora-packaging] Minutes/Logs of 20060713 anyone? In-Reply-To: <20060718172954.GF5874@neu.nirvana> References: <20060718172954.GF5874@neu.nirvana> Message-ID: <1153253438.3007.7.camel@localhost> On Tue, 2006-07-18 at 19:29 +0200, Axel Thimm wrote: > Hi, > > I couldn't make it to the last IRC meeting, does anyone have the > logs/minutes? If so could you send them to me or even better upload to > http://www.fedoraproject.org/wiki/Packaging/Minutes? I've added the IRCLog for the last meeting:: http://www.fedoraproject.org/wiki/Packaging/IRCLog20060713 No minutes, though. The 2006-07-06 meeting needs to be filled in as well. I have the logs but not much time right now. If someone else doesn't get to it, I'll add it tonight. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Wed Jul 19 06:24:23 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 19 Jul 2006 08:24:23 +0200 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> Message-ID: <1153290264.7982.36.camel@mccallum.corsepiu.local> On Wed, 2006-07-19 at 00:55 -0400, bugzilla at redhat.com wrote: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > Summary: Review Request: perl-POE-Filter-IRCD > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198881 > > > cweyl at alumni.drew.edu changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|ASSIGNED |CLOSED > Resolution| |NEXTRELEASE > > > > > ------- Additional Comments From cweyl at alumni.drew.edu 2006-07-19 00:46 EST ------- > Ok, I think the rhetoric here is getting a touch out of hand, and making a very > large issue out of a not-so-large one. > > Perl modules are fairly "special", in that basically the same specfile can > handle all of them (with package specific description, etc, being adapted, of > course). They're also special in that there's a LOT of them. > > For those two reasons, I try to hew as close to the specfile template as > possible. --> The closer to the template a perl module spec is the more readily > apparent errors are, especially when there's a _lot_ of them. <-- I beg to differ. IMO, you are slavishly copying without thinking what you are doing. > It's easy to scan a perl spec and almost instinctively know when something is > missing, when as little deviation as necessary is made from it. The only party which deviates is Tibbs/Weyl. If Jason had directed you to drop OPTIMIZE/find *.bs from the very beginning, as probably all other perl-package reviewers in the past have done, this would have not escalated. IIRC, JPO, Steve P., Jesse Keating, Paul H., Warren T. and me have all done so in the past. > Ralf, I do not do this "mindlessly", "without thinking", or "sloppily". I do > check to ensure the extra lines (w.r.t. OPTIMIZE) doesn't adversely impact the > building of the package. I'm not resistant to learning, and in fact find myself > learning daily and seeking input. To date I haven't been provided with any > reason why, in my judgement, it would be advantagous to abandon this practice. Well, that's not the impression you make on me. I regret having to say this, but I sense you as a person who seems to need "regulations" for each any every bit he writes and who doesn't have understood the meaning of "templates" Templates are supposed to be filled with life by humans, not to be slavishly copied. > If you want, bring this issue before the packaging committee. In Fedora it has always been common agreement to keep specs minimal and not to clutter/pollute them with potentially harmful junk. Ralf From paul at city-fan.org Wed Jul 19 09:37:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 19 Jul 2006 10:37:49 +0100 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <1153290264.7982.36.camel@mccallum.corsepiu.local> References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> Message-ID: <44BDFD6D.3000507@city-fan.org> Ralf Corsepius wrote: > On Wed, 2006-07-19 at 00:55 -0400, bugzilla at redhat.com wrote: >> Please do not reply directly to this email. All additional >> comments should be made in the comments box of this bug report. >> >> Summary: Review Request: perl-POE-Filter-IRCD >> >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198881 >> >> >> cweyl at alumni.drew.edu changed: >> >> What |Removed |Added >> ---------------------------------------------------------------------------- >> Status|ASSIGNED |CLOSED >> Resolution| |NEXTRELEASE >> >> >> >> >> ------- Additional Comments From cweyl at alumni.drew.edu 2006-07-19 00:46 EST ------- >> Ok, I think the rhetoric here is getting a touch out of hand, and making a very >> large issue out of a not-so-large one. >> >> Perl modules are fairly "special", in that basically the same specfile can >> handle all of them (with package specific description, etc, being adapted, of >> course). They're also special in that there's a LOT of them. I have just looked through the specs of the perl module packages I maintain. The following ones might be said to be close to the original template (and I'm not including the removal of the redundant noarch stuff as being a difference of note here): perl-Crypt-DSA perl-Crypt-SmbHash perl-IO-stringy perl-Crypt-DSA has some additional buildreqs not in the template btw. The following have something of significance that's not in the template: perl-Authen-DigestMD5 perl-Class-Loader perl-Convert-BinHex perl-Crypt-DH perl-Crypt-Primes perl-Crypt-Random perl-Crypt-RSA perl-Date-Simple perl-Mail-Mbox-MessageParser perl-MailTools perl-Math-GMP perl-Math-Pari perl-MIME-tools perl-Net-SSH-Perl perl-Tie-EncryptedHash So I don't think it's true to say that the same template works for most perl modules. Nor do I think that just because perl modules are small and plentiful, their packages don't deserve the same degree of love and attention that any other other package would get. Paul. From Axel.Thimm at ATrpms.net Wed Jul 19 12:19:41 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jul 2006 14:19:41 +0200 Subject: [Fedora-packaging] Re: Minutes/Logs of 20060713 anyone? In-Reply-To: <1153253438.3007.7.camel@localhost> References: <20060718172954.GF5874@neu.nirvana> <1153253438.3007.7.camel@localhost> Message-ID: <20060719121941.GH13785@neu.nirvana> On Tue, Jul 18, 2006 at 01:10:38PM -0700, Toshio Kuratomi wrote: > On Tue, 2006-07-18 at 19:29 +0200, Axel Thimm wrote: > > I couldn't make it to the last IRC meeting, does anyone have the > > logs/minutes? If so could you send them to me or even better upload to > > http://www.fedoraproject.org/wiki/Packaging/Minutes? > > I've added the IRCLog for the last meeting:: > http://www.fedoraproject.org/wiki/Packaging/IRCLog20060713 Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Jul 19 12:22:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jul 2006 13:22:05 +0100 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153223974.2594.3.camel@bureau.maison> References: <1153172566.3515.3.camel@bureau.maison><20060718012432.GA466@neu.nirvana><1153206620.2605.2.camel@bureau.maison><1153172566.3515.3.camel@bureau.maison><20060718012432.GA466@neu.nirvana><1153191448.5648.161.camel@canyon.wittsend.com><20060718084104.GA2997@neu.nirvana><1153223974.2594.3.camel@bureau.maison> Message-ID: <01c501c6ab2d$f29d2220$0210a8c0@hayloft.office> On Tue, Jul 18, 2006 at 01:59:34PM +0200, Eric Tanguy wrote: > > kernels=`rpm -qf /boot/vmlinuz-* | grep -v "^file .* is not owned by any package"` > > uname_rs=`rpm -ql $kernels | grep ^/boot/vmlinuz- | sed -e's,^/boot/vmlinuz-\(.*\)$,\1,'` > > for kmdl in `rpm -qa \*kmdl\* | sed -e's,-kmdl-.*,-kmdl,' | sort -u`; > > do > > for uname_r in $uname_rs; do > > package=${kmdl}-$uname_r > > rpm -q $package > /dev/null 2>&1 || echo $package > > done > > done | xargs -r smart install -y > > Ok this script seems to use smart. is it working with yum ? Yes, I think "smart install -y" -> "yum -y install" is the only change needed. And for apt it would be "apt-get -y install". > How is this problem handled by livna because it works fine using > this repo : the kernel modules are installed and not updated > It's known that there are issues with this scheme, or any scheme > that will merge module and kernel versions. rpm for one can't cope with it. Suppose you have two active kernels (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have foo-kmdl for both in version 1. Now foo-kmdl in version 2 is released. Both rpm -i (coinstall, no replacement of of foo-kmdl for the same kernel) and rpm -U (remove all foo-kmdl but the highest one, e.g. at least one kernel stay w/o any kmdl) won't work. yum/smart/apt can be tought to be more clever than rpm and try to do the proper thing, which they will only be able to do if the merged versions are distangled again, e.g. hidden in Provides: and the like. So in order for a merged-version scheme to work there is special handling neccessary (and for atrpms' system, too, but read on). I prefer to have rpm itself already do something sensible and since it can only upgrade one versioning system (e.g. either the kernel's or the module's) it's preferable to allow it to upgrade the module within the same kernel and not touch the cross-kernel boundaries. "No harm done" like accidentially removing kmdls for other kernels or coinstalling several kmdls for the same kernel. You "only" need to reinstall the missing kmdl upon each kernel upgrade. It's far easier to get this into the brains of yum/smart/apt (e.g. translate the 9 lines of bash above into plugings/hooks for these depsolvers) or simply use the 9liner above than have a scheme which is broken at the level of rpm. Incidentially one on my personal targets is to get thie discussed in the fedora packaging group and review the currently scheme. Of course, I'm proposing adoption of ATrpms' kmdl scheme :) http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo > when i install a new kernel and are removed when the kernel is > removed. How the dependencies to the kernel are installed (which is responsible for having an automatic removal on kernel removal) is a different story, which the version merging does not break. The issue is with the system (system=rpm and(or any higher depsolver tool, e.g. yum/smart/apt) being able to distinguish different foo-kmdls as _upgrades_ vs _coinstalls_. -- 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: -------------- next part -------------- -- fedora-list mailing list fedora-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list From Axel.Thimm at ATrpms.net Wed Jul 19 12:29:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jul 2006 14:29:27 +0200 Subject: [Fedora-packaging] Request to drop %(%{__id_u} -n) in preferred buildroot Message-ID: <20060719122927.GI13785@neu.nirvana> Hi, I think the `preferred buildroot' is not really making sense. The above has developed historically out of a misunderstanding in ancient buildroot times. When people were building as root and BuildRoots were defined as %{_tmppath}/%{name}-%{version}-root, some considered "root" to mean the uid of the builder. Later %release was added and some replaced root with `id -un`. Even later some realized that root was referring to the BuildRoot and in order to play safe added both. I'm using %{_tmppath}/%{name}-%{version}-%{release}-root in my packages and someone is now nitpicking on why not using the preferred BuildRoot as given in the guidelines. Instead of locally fighting a BuildRoot battle, I'd better get the guidelines fixed ;) Also consider what this really is about: Deambiguifying the BuildRoot per package makes sense as there may be several build processes sharing the same filesystem (either locally or through NFS), but deambiguifying the build user, too, means that we assume that the same EVR package will be possibly built on the same filesystem by different users? And even simultaneously? It makes more sense to include a conditional epoch or target/arch in the buildroot that the builder. In fact the best thing for a buildsystem is to override the buildroot adding a build-id to it anyway. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jul 19 12:41:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Jul 2006 08:41:45 -0400 Subject: [Fedora-packaging] Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <20060719122927.GI13785@neu.nirvana> References: <20060719122927.GI13785@neu.nirvana> Message-ID: <200607190841.45713.jkeating@redhat.com> On Wednesday 19 July 2006 08:29, Axel Thimm wrote: > It makes more sense to include a conditional epoch or target/arch in > the buildroot that the builder. In fact the best thing for a > buildsystem is to override the buildroot adding a build-id to it > anyway. Or what we REALLY should do is have rpm(build) supplant a standard buildroot when one isn't found in the spec file, so we can REMOVE Buildroot from the spec file all together and no longer have these discussions. Instead of nitpicking on how the buildroot should look, we just say 'remove buildroot definitions'. That's KISS. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Jul 19 12:51:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jul 2006 14:51:30 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <200607190841.45713.jkeating@redhat.com> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> Message-ID: <20060719125130.GJ13785@neu.nirvana> On Wed, Jul 19, 2006 at 08:41:45AM -0400, Jesse Keating wrote: > On Wednesday 19 July 2006 08:29, Axel Thimm wrote: > > It makes more sense to include a conditional epoch or target/arch in > > the buildroot that the builder. In fact the best thing for a > > buildsystem is to override the buildroot adding a build-id to it > > anyway. > > Or what we REALLY should do is have rpm(build) supplant a standard buildroot > when one isn't found in the spec file, so we can REMOVE Buildroot from the > spec file all together and no longer have these discussions. Instead of > nitpicking on how the buildroot should look, we just say 'remove buildroot > definitions'. That's KISS. I would agree, if it weren't for undefined behaviour at best when someone uses the buildroot-less specfile on a system not supplying a default buildroot. In the worst case you could end up with an empty buildroot and %install/%clean operations on the buildroot could suddenly really happen in the live filesystem. So, even if we get some current/future rpm version to behave as we wish it we would need to allow for many years to pass to really start dropping BuildRoot tags. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Wed Jul 19 13:10:16 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 Jul 2006 09:10:16 -0400 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <20060719125130.GJ13785@neu.nirvana> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> Message-ID: <200607190910.16601.jkeating@j2solutions.net> On Wednesday 19 July 2006 08:51, Axel Thimm wrote: > I would agree, if it weren't for undefined behaviour at best when > someone uses the buildroot-less specfile on a system not supplying a > default buildroot. > > In the worst case you could end up with an empty buildroot and > %install/%clean operations on the buildroot could suddenly really > happen in the live filesystem. Have you tried (within a chroot) to build a package w/out a chroot on our modern rpm? (I haven't yet, other things to do today...) -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Jul 19 13:24:06 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jul 2006 15:24:06 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <200607190910.16601.jkeating@j2solutions.net> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> Message-ID: <20060719132406.GK13785@neu.nirvana> On Wed, Jul 19, 2006 at 09:10:16AM -0400, Jesse Keating wrote: > On Wednesday 19 July 2006 08:51, Axel Thimm wrote: > > I would agree, if it weren't for undefined behaviour at best when > > someone uses the buildroot-less specfile on a system not supplying a > > default buildroot. > > > > In the worst case you could end up with an empty buildroot and > > %install/%clean operations on the buildroot could suddenly really > > happen in the live filesystem. > > Have you tried (within a chroot) to build a package w/out a chroot on our > modern rpm? (I haven't yet, other things to do today...) You mean w/out a buildroot? I did try on FC5, and there BuildRoot: foo is effectively the same as %define buildroot foo No errors/warnings if BuildRoot is missing (and of course no sensible default, in fact no definition of the buildroot macro at all), which is a bit disappointing if you ask me. But that's only half the story. Even if we would find FC5's rpm to do something sensible w/o a BuildRoot tag, we cannot rely only on modern rpm's behaviour and try to check whether a missing BuildRoot tag would create havoc there or not. You would need to check this behaviour with past rpm versions, both packaged in Red Hat/Fedora products/releases and even upstream. We don't want to be responsible for any breakage, not even outside Fedora/RHEL. I don't think it's worth while risking it. Better/easier to a) override it in buildsystems aynway, and b) put a sensible default in the guidelines -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Jul 19 13:35:53 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Jul 2006 08:35:53 -0500 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <20060719132406.GK13785@neu.nirvana> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> Message-ID: <44BE3539.1070107@math.unl.edu> Axel Thimm wrote: > On Wed, Jul 19, 2006 at 09:10:16AM -0400, Jesse Keating wrote: > I don't think it's worth while risking it. Better/easier to > > a) override it in buildsystems aynway, and It's been tossed around that this might be something worth stuffing into redhat-rpm-config > b) put a sensible default in the guidelines IMO, the guidelines already include a sensible default. -- Rex From Axel.Thimm at ATrpms.net Wed Jul 19 13:47:04 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jul 2006 15:47:04 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <44BE3539.1070107@math.unl.edu> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> Message-ID: <20060719134704.GL13785@neu.nirvana> On Wed, Jul 19, 2006 at 08:35:53AM -0500, Rex Dieter wrote: > Axel Thimm wrote: > >On Wed, Jul 19, 2006 at 09:10:16AM -0400, Jesse Keating wrote: > > >I don't think it's worth while risking it. Better/easier to > > > >a) override it in buildsystems aynway, and > > It's been tossed around that this might be something worth stuffing into > redhat-rpm-config > > >b) put a sensible default in the guidelines > > IMO, the guidelines already include a sensible default. Well, the thread instantly drifted from discussing the default to discussing removing it altogether. Unfortunately the arguments are only found at the beginning of the thread, so you may want to check that. In short id -un doesn't make sense, even epoch or target/arch would make more far more sense in a guideline's BuildRoot. Note that the guidelines are also there to educate people how to write clean and non-obfuscated specfiles. I'm quite sure the BuildRoot is cut & pasted in 99.99% of the packages making it a defacto proper thing to do. If it's bogus we need to fix it and not endorse it furthermore. Two independent reviewer considered this a blocker for a review's acceptance (even though it's marked "preferred"). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Jul 19 13:54:22 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Jul 2006 08:54:22 -0500 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> Message-ID: Axel Thimm wrote: > On Wed, Jul 19, 2006 at 08:35:53AM -0500, Rex Dieter wrote: >> >b) put a sensible default in the guidelines >> >> IMO, the guidelines already include a sensible default. > > In short id -un doesn't make sense, even epoch or target/arch > would make more far more sense in a guideline's BuildRoot. > > Note that the guidelines are also there to educate people how to write > clean and non-obfuscated specfiles. I'm quite sure the BuildRoot is > cut & pasted in 99.99% of the packages making it a defacto proper > thing to do. If it's bogus we need to fix it and not endorse it > furthermore. It's simply my opinion that it's not worth fixing something that isn't broken. > Two independent reviewer considered this a blocker for a > review's acceptance (even though it's marked "preferred"). The reviewers need to be whacked with a clue-stick. A working (non-broken) buildroot is *not* a blocker. -- Rex From Axel.Thimm at ATrpms.net Wed Jul 19 14:15:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jul 2006 16:15:53 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> Message-ID: <20060719141553.GA2807@neu.nirvana> On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote: > Axel Thimm wrote: > > > On Wed, Jul 19, 2006 at 08:35:53AM -0500, Rex Dieter wrote: > > >> >b) put a sensible default in the guidelines > >> > >> IMO, the guidelines already include a sensible default. > > > > In short id -un doesn't make sense, even epoch or target/arch > > would make more far more sense in a guideline's BuildRoot. > > > > Note that the guidelines are also there to educate people how to write > > clean and non-obfuscated specfiles. I'm quite sure the BuildRoot is > > cut & pasted in 99.99% of the packages making it a defacto proper > > thing to do. If it's bogus we need to fix it and not endorse it > > furthermore. > > It's simply my opinion that it's not worth fixing something that isn't > broken. It's not broken as in "fix all packages that use id -un", it just shouldn't be promoted anymore as a default since it makes no sense. And given that it does create workload on packager and reviewer everytime this will come up again, let's fix it. > > Two independent reviewer considered this a blocker for a > > review's acceptance (even though it's marked "preferred"). > > The reviewers need to be whacked with a clue-stick. A working (non-broken) > buildroot is *not* a blocker. That's what I meant with "wrong education". I can't blame reviewers for following the guidelines to the letter (and since they are scarce, I also don't want to use any punishment on them ;). I thought this would be an EasyFix. :/ -- 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 Wed Jul 19 14:37:25 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 19 Jul 2006 09:37:25 -0500 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <20060719141553.GA2807@neu.nirvana> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> Message-ID: <1153319845.12430.864.camel@localhost.localdomain> On Wed, 2006-07-19 at 16:15 +0200, Axel Thimm wrote: > On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote: > > Axel Thimm wrote: > > > > > On Wed, Jul 19, 2006 at 08:35:53AM -0500, Rex Dieter wrote: > > > > >> >b) put a sensible default in the guidelines > > >> > > >> IMO, the guidelines already include a sensible default. > > > > > > In short id -un doesn't make sense, even epoch or target/arch > > > would make more far more sense in a guideline's BuildRoot. > > > > > > Note that the guidelines are also there to educate people how to write > > > clean and non-obfuscated specfiles. I'm quite sure the BuildRoot is > > > cut & pasted in 99.99% of the packages making it a defacto proper > > > thing to do. If it's bogus we need to fix it and not endorse it > > > furthermore. > > > > It's simply my opinion that it's not worth fixing something that isn't > > broken. > > It's not broken as in "fix all packages that use id -un", it just > shouldn't be promoted anymore as a default since it makes no > sense. And given that it does create workload on packager and reviewer > everytime this will come up again, let's fix it. Axel, put the exact buildroot that you want to change the guidelines to use on the todo agenda for tomorrow, and we'll vote on it. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Wed Jul 19 14:46:34 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 19 Jul 2006 09:46:34 -0500 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <1153290264.7982.36.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Wed, 19 Jul 2006 08:24:23 +0200") References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> Message-ID: I suggested that Ralf put it on the schedule for discussion, but he never did so I went ahead and did so. Item: Tighten up Perl guidelines to disallow passing OPTIMIZE for noarch packages and tweak the Perl template to denote bits which must be left out of noarch packages. Currently I see this as a stylistic issue and recognize the packager's wish to follow the template here. I think it's reasonable for me to disagree with what he's adding to the packages without considering them blockers. In all truth, it's not really clear what's supposed to be done, and in fact when doing my first reviews I was asking for the OPTIMIZE bit to be _added_ to noarch packages to conform to the template. I mean, all we give people to go on is a template with a bunch of stuff that's mildly cryptic at best and expect them to know which bits can go. I don't think it's fair or productive to fail to give them any hints about what to do until Ralf blindsides them with statements about how crappy their packages are. So let's consider making it clear. One snag is that I recall discussion about adding a little bit of description to the Perl template and being told that the template should be kept clean of comments. I'm only proposing two lines in the style of what's already in the %files section; see the suggested patch I have attached. Finally, note that I do not intend to review any more of Chris Weyl's Perl packages until the committee clarifies this or until he decides to drop the extraneous bits. - J< --- spectemplate-perl.spec-orig 2006-07-19 09:44:04.621760113 -0500 +++ spectemplate-perl.spec 2006-07-19 09:44:34.674527337 -0500 @@ -21,6 +21,7 @@ %build +# Remove the OPTIMIZE bit for noarch packages %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS" make %{?_smp_mflags} @@ -29,6 +30,7 @@ rm -rf $RPM_BUILD_ROOT make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' +# Remove the following line for noarch packages find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' chmod -R u+w $RPM_BUILD_ROOT/* From rc040203 at freenet.de Wed Jul 19 14:46:56 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 19 Jul 2006 16:46:56 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <20060719141553.GA2807@neu.nirvana> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> Message-ID: <1153320416.7982.151.camel@mccallum.corsepiu.local> On Wed, 2006-07-19 at 16:15 +0200, Axel Thimm wrote: > On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote: > > Axel Thimm wrote: > > > Two independent reviewer considered this a blocker for a > > > review's acceptance (even though it's marked "preferred"). > > > > The reviewers need to be whacked with a clue-stick. A working (non-broken) > > buildroot is *not* a blocker. The point you seem to be missing, your buildroot is broken: buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root This directory is NOT unique and will break if 2 or more users are running an rpmbuild in parallel on the same /var/tmp filesystem. It will also break if 2 different users are running buildjobs of the same package consecutively and if the first one fails and leaves it buildroot behind. Ralf From rdieter at math.unl.edu Wed Jul 19 14:53:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Jul 2006 09:53:34 -0500 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> Message-ID: <44BE476E.6090400@math.unl.edu> Jason L Tibbitts III wrote: > --- spectemplate-perl.spec-orig 2006-07-19 09:44:04.621760113 -0500 > +++ spectemplate-perl.spec 2006-07-19 09:44:34.674527337 -0500 > @@ -29,6 +30,7 @@ > rm -rf $RPM_BUILD_ROOT > make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT > find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' > +# Remove the following line for noarch packages +%ifarch noarch > find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' +%endif > find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' > chmod -R u+w $RPM_BUILD_ROOT/* From rdieter at math.unl.edu Wed Jul 19 15:00:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Jul 2006 10:00:35 -0500 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <44BE476E.6090400@math.unl.edu> References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> <44BE476E.6090400@math.unl.edu> Message-ID: <44BE4913.7080303@math.unl.edu> Rex Dieter wrote: > Jason L Tibbitts III wrote: > >> --- spectemplate-perl.spec-orig 2006-07-19 09:44:04.621760113 -0500 >> +++ spectemplate-perl.spec 2006-07-19 09:44:34.674527337 -0500 >> @@ -29,6 +30,7 @@ >> rm -rf $RPM_BUILD_ROOT >> make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT >> find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' >> +# Remove the following line for noarch packages > +%ifarch noarch >> find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' > +%endif >> find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' >> chmod -R u+w $RPM_BUILD_ROOT/* Oops, make the %ifarch -> %ifnarch -- Rex From rdieter at math.unl.edu Wed Jul 19 15:03:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Jul 2006 10:03:09 -0500 Subject: [Fedora-packaging] Re: Re: Request to drop %(%{__id_u} -n) in preferred buildroot References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Wed, 2006-07-19 at 16:15 +0200, Axel Thimm wrote: >> On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote: >> > Axel Thimm wrote: >> > > Two independent reviewer considered this a blocker for a >> > > review's acceptance (even though it's marked "preferred"). >> > The reviewers need to be whacked with a clue-stick. A working >> > (non-broken) buildroot is *not* a blocker. > The point you seem to be missing, your buildroot is broken: > buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root And you missed the point that *in the context of Fedora Extras*, it's not broken. -- Rex From rc040203 at freenet.de Wed Jul 19 15:11:18 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 19 Jul 2006 17:11:18 +0200 Subject: [Fedora-packaging] Re: Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> Message-ID: <1153321878.7982.154.camel@mccallum.corsepiu.local> On Wed, 2006-07-19 at 10:03 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > > On Wed, 2006-07-19 at 16:15 +0200, Axel Thimm wrote: > >> On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote: > >> > Axel Thimm wrote: > > >> > > Two independent reviewer considered this a blocker for a > >> > > review's acceptance (even though it's marked "preferred"). > > >> > The reviewers need to be whacked with a clue-stick. A working > >> > (non-broken) buildroot is *not* a blocker. > > > The point you seem to be missing, your buildroot is broken: > > buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root > > And you missed the point that *in the context of Fedora Extras*, it's not > broken. Rebuilding rpms by users is not amongst the Fedora tasks? FE is living in the ivory towers of mock? With all due respect, .... Ralf From nicolas.mailhot at laposte.net Wed Jul 19 15:28:51 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 19 Jul 2006 17:28:51 +0200 (CEST) Subject: [Fedora-packaging] Re: Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> Message-ID: <21895.192.54.193.53.1153322931.squirrel@rousalka.dyndns.org> Le Mer 19 juillet 2006 17:03, Rex Dieter a ?crit : > And you missed the point that *in the context of Fedora Extras*, it's not > broken. The Fedora packaging guidelines will also 1. be used by Fedora Core 2. serve as a model for countless packaging efforts in the wild so Fedora Extras context can not be assumed. The buildroot chosen should not be simplified because of Extras buildsys specifics. It must be resilient to every rpm build scenario will know of, because as soon as Core uses it all these scenarii will be played out by someone somewhere. If anything, the OP message raeds the current buildroot is not safe enough yet. Assumming no ISV will ever have several people build the same package on the same build server using plain Fedora buildroot is dangerous. Thinking they won't blame the Fedora platform when breakage happens is unrealistic. Fedora is not just a 3rd party repo which can limit itself to whatever it chooses. Regards, -- Nicolas Mailhot From tibbs at math.uh.edu Wed Jul 19 15:41:14 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 19 Jul 2006 10:41:14 -0500 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <44BE476E.6090400@math.unl.edu> (Rex Dieter's message of "Wed, 19 Jul 2006 09:53:34 -0500") References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> <44BE476E.6090400@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> +%ifnarch noarch ... RD> +%endif The find call in there is completely harmless but unnecessary; the angry comments I've received are (partially) about allowing the unnecessary line to persist. Somehow I don't think wrapping it in %ifnarch is going to help, since that adds two additional unnecessary lines. - J< From rdieter at math.unl.edu Wed Jul 19 15:44:03 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Jul 2006 10:44:03 -0500 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> <44BE476E.6090400@math.unl.edu> Message-ID: <44BE5343.8060601@math.unl.edu> Jason L Tibbitts III wrote: >>>>>> "RD" == Rex Dieter writes: > > RD> +%ifnarch noarch > ... > RD> +%endif > > The find call in there is completely harmless but unnecessary; the > angry comments I've received are (partially) about allowing the > unnecessary line to persist. Somehow I don't think wrapping it in > %ifnarch is going to help, since that adds two additional unnecessary > lines. OK. (: You might want to remind the angry brow-beaters that the sky is falling too. -- Rex From paul at city-fan.org Wed Jul 19 16:31:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 19 Jul 2006 17:31:50 +0100 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <44BE5343.8060601@math.unl.edu> References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> <44BE476E.6090400@math.unl.edu> <44BE5343.8060601@math.unl.edu> Message-ID: <44BE5E76.9040109@city-fan.org> Rex Dieter wrote: > Jason L Tibbitts III wrote: >>>>>>> "RD" == Rex Dieter writes: >> >> RD> +%ifnarch noarch >> ... >> RD> +%endif >> >> The find call in there is completely harmless but unnecessary; the >> angry comments I've received are (partially) about allowing the >> unnecessary line to persist. Somehow I don't think wrapping it in >> %ifnarch is going to help, since that adds two additional unnecessary >> lines. > > OK. (: You might want to remind the angry brow-beaters that the sky is > falling too. Is it just me or shouldn't packagers actually have a reasonable understanding of what's in their spec files? Having a reasonable understanding of a perl module spec file for instance, would include knowing what each thing did and hence what wasn't needed. Paul. From rdieter at math.unl.edu Wed Jul 19 17:13:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Jul 2006 12:13:34 -0500 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <44BE5E76.9040109@city-fan.org> References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> <44BE476E.6090400@math.unl.edu> <44BE5343.8060601@math.unl.edu> <44BE5E76.9040109@city-fan.org> Message-ID: <44BE683E.4010302@math.unl.edu> Paul Howarth wrote: > Rex Dieter wrote: >> Jason L Tibbitts III wrote: >>>>>>>> "RD" == Rex Dieter writes: >>> >>> RD> +%ifnarch noarch >>> ... >>> RD> +%endif >>> >>> The find call in there is completely harmless but unnecessary; the >>> angry comments I've received are (partially) about allowing the >>> unnecessary line to persist. Somehow I don't think wrapping it in >>> %ifnarch is going to help, since that adds two additional unnecessary >>> lines. >> >> OK. (: You might want to remind the angry brow-beaters that the sky >> is falling too. > > Is it just me or shouldn't packagers actually have a reasonable > understanding of what's in their spec files? It's not just you. -- Rex From fedora at leemhuis.info Wed Jul 19 17:40:38 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 19 Jul 2006 19:40:38 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060718165353.GB5874@neu.nirvana> References: <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153206620.2605.2.camel@bureau.maison> <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> Message-ID: <44BE6E96.8070904@leemhuis.info> dropping fedora-list from CC Hi All! Seems Axel wants to bring kmod onto the topic again -- I can understand his situation so let's get this discussed... Axel Thimm schrieb: > On Tue, Jul 18, 2006 at 01:59:34PM +0200, Eric Tanguy wrote: >> How is this problem handled by livna because it works fine using >> this repo : the kernel modules are installed and not updated >> It's known that there are issues with this scheme, or any scheme >> that will merge module and kernel versions. > rpm for one can't cope with it. Suppose you have two active kernels > (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have > foo-kmdl for both in version 1. Now foo-kmdl in version 2 is > released. Both rpm -i (coinstall, no replacement of of foo-kmdl for > the same kernel) and rpm -U (remove all foo-kmdl but the highest one, > e.g. at least one kernel stay w/o any kmdl) won't work. Well, yes, coinstall will fail because this would result in a file conflict. But rpm -U works fine (but removes the older version) with the current Extras kmod scheme and "yum install foo" AFAICS works fine, too. > yum/smart/apt can be tought to be more clever than rpm and try to do > the proper thing, which they will only be able to do if the merged > versions are distangled again, e.g. hidden in Provides: and the like. > > So in order for a merged-version scheme to work there is special > handling neccessary (and for atrpms' system, too, but read on). All special handling I'm aware of is that all modules that have Provides: kernel-modules are installed by yum and not updated. Similar how all packages providing "kernel" are installed and not updated. Yum support that for a long time (two years?) already (IIRC). The latgest version seems to also have some magic to updat kmod packages if there would be conflics otherwise. > I > prefer to have rpm itself already do something sensible and since it > can only upgrade one versioning system (e.g. either the kernel's or > the module's) it's preferable to allow it to upgrade the module within > the same kernel and not touch the cross-kernel boundaries. "No harm > done" like accidentially removing kmdls for other kernels or > coinstalling several kmdls for the same kernel. You "only" need to > reinstall the missing kmdl upon each kernel upgrade. > > It's far easier to get this into the brains of yum/smart/apt > (e.g. translate the 9 lines of bash above into plugings/hooks for > these depsolvers) or simply use the 9liner above than have a scheme > which is broken at the level of rpm. Well, we (fedora.us and Livna in this case) had a scheme that used the output from "uname -r" in the name similar how atrpms still uses it AFAICS. We (e.g. those involved in the kmod discussion for Extras) were not satisfied with it AFICS. The decision against using the uname-output in the name was one of the first ones when the Extras kmod-standard was discussed. It was a rather quick decision IIRC to not use it. > Incidentially one on my personal targets is to get thie discussed in > the fedora packaging group and review the currently scheme. Of course, > I'm proposing adoption of ATrpms' kmdl scheme :) > > http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo Is you scheme documented somewhere properly so we can look at it again? Please also post a URL to the macros for FC5 (maybe rawhide, too) -- we probably need them if we want to look at the scheme. BTW, livna uses the Extras scheme for all kmod-packages since FC5 now. AFICS it works a lot better than the old fedora.us scheme. There are still some things that could need to be improved: - yum should install kmods for all latest kernels that are installed -- e.g. is one has a smp and a xen0 kernel installed yum should install kmods for both when running "yum install kmod-foo" - plague needs support for kmod-srpms to get rid of the hard coded kversion and kvariants >> when i install a new kernel and are removed when the kernel is >> removed. > How the dependencies to the kernel are installed (which is responsible > for having an automatic removal on kernel removal) is a different > story, which the version merging does not break. The issue is with the > system (system=rpm and(or any higher depsolver tool, > e.g. yum/smart/apt) being able to distinguish different foo-kmdls as > _upgrades_ vs _coinstalls_. As I said, Provides: kernel-modules and yum will install them. When you run rpm directly you are on your own -- it similar with the kernel itself. CU thl From tibbs at math.uh.edu Wed Jul 19 17:40:18 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 19 Jul 2006 12:40:18 -0500 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <44BE5E76.9040109@city-fan.org> (Paul Howarth's message of "Wed, 19 Jul 2006 17:31:50 +0100") References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> <44BE476E.6090400@math.unl.edu> <44BE5343.8060601@math.unl.edu> <44BE5E76.9040109@city-fan.org> Message-ID: >>>>> "PH" == Paul Howarth writes: PH> Is it just me or shouldn't packagers actually have a reasonable PH> understanding of what's in their spec files? Stuff creeps into specfiles to workaround rpm brokenness, deal with bizarre bits of the buildsystem, changes in requirements between Fedora versions, and more. I'm sorry, but if you require every packager to understand all of that up front then I'm afraid you've set the barrier way too high. Or, look at it this way. You're a new packager, trying to package up a perl module. There's a find line in the specfile template. You don't think it does anything, but it's there in the template for a reason, right? After all, those people who wrote the template must know a whole lot more about the process than you do. Unfortunately there's no descriptive comment or hint as to when you're supposed to use and when you aren't. What might change to make it necessary? Is that change completely within your control, or will perhaps some perl update or buildsys switch make it necessary? How can you even know? So just leaving it alone makes a ton of sense. Easily solved by us just adding a single freaking line saying "don't use this for noarch packages". - J< From paul at city-fan.org Wed Jul 19 17:45:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 19 Jul 2006 18:45:27 +0100 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> <44BE476E.6090400@math.unl.edu> <44BE5343.8060601@math.unl.edu> <44BE5E76.9040109@city-fan.org> Message-ID: <44BE6FB7.4020107@city-fan.org> Jason L Tibbitts III wrote: >>>>>> "PH" == Paul Howarth writes: > > PH> Is it just me or shouldn't packagers actually have a reasonable > PH> understanding of what's in their spec files? > > Stuff creeps into specfiles to workaround rpm brokenness, deal with > bizarre bits of the buildsystem, changes in requirements between > Fedora versions, and more. I'm sorry, but if you require every > packager to understand all of that up front then I'm afraid you've set > the barrier way too high. > > Or, look at it this way. You're a new packager, trying to package up > a perl module. There's a find line in the specfile template. You > don't think it does anything, but it's there in the template for a > reason, right? After all, those people who wrote the template must > know a whole lot more about the process than you do. Unfortunately > there's no descriptive comment or hint as to when you're supposed to > use and when you aren't. What might change to make it necessary? Is > that change completely within your control, or will perhaps some perl > update or buildsys switch make it necessary? How can you even know? > > So just leaving it alone makes a ton of sense. > > Easily solved by us just adding a single freaking line saying "don't > use this for noarch packages". Perhaps a better idea, which wouldn't result in spec files cluttered with comments, would be for each language SIG to have a page on the wiki explaining the magic in their spec templates? Paul. From ville.skytta at iki.fi Wed Jul 19 18:11:44 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 19 Jul 2006 21:11:44 +0300 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <44BE6FB7.4020107@city-fan.org> References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> <44BE476E.6090400@math.unl.edu> <44BE5343.8060601@math.unl.edu> <44BE5E76.9040109@city-fan.org> <44BE6FB7.4020107@city-fan.org> Message-ID: <1153332704.2683.68.camel@localhost.localdomain> On Wed, 2006-07-19 at 18:45 +0100, Paul Howarth wrote: > Perhaps a better idea, which wouldn't result in spec files cluttered > with comments, would be for each language SIG to have a page on the wiki > explaining the magic in their spec templates? Agreed, FWIW we already have a bit too much "stuff" for my personal taste in some current and some upcoming templates. One example of the magic doc is jpo's notes at http://gsd.di.uminho.pt/jpo/perl/specfiles/ which is linked from the Perl SIG page (but probably rightfully marked as "(old)" based on a quick look at the contents). From tibbs at math.uh.edu Wed Jul 19 18:41:46 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 19 Jul 2006 13:41:46 -0500 Subject: [Fedora-packaging] Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD In-Reply-To: <1153332704.2683.68.camel@localhost.localdomain> (Ville Skytt's message of "Wed, 19 Jul 2006 21:11:44 +0300") References: <200607190455.k6J4tZrp012005@bugzilla.redhat.com> <1153290264.7982.36.camel@mccallum.corsepiu.local> <44BE476E.6090400@math.unl.edu> <44BE5343.8060601@math.unl.edu> <44BE5E76.9040109@city-fan.org> <44BE6FB7.4020107@city-fan.org> <1153332704.2683.68.camel@localhost.localdomain> Message-ID: >>>>> "VS" == Ville Skytt writes: VS> Agreed, FWIW we already have a bit too much "stuff" for my VS> personal taste in some current and some upcoming templates. The Perl template has exactly two comments. Hopefully this isn't too much; I find it to be woefully undercommented. I'm only proposing to add two more comments of the type that are already there. - J< From Axel.Thimm at ATrpms.net Wed Jul 19 19:02:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jul 2006 21:02:43 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <1153320416.7982.151.camel@mccallum.corsepiu.local> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> Message-ID: <20060719190243.GB4405@neu.nirvana> On Wed, Jul 19, 2006 at 02:29:27PM +0200, Axel Thimm wrote: > Also consider what this really is about: Deambiguifying the > BuildRoot per package makes sense as there may be several build > processes sharing the same filesystem (either locally or through > NFS), but deambiguifying the build user, too, means that we assume > that the same EVR package will be possibly built on the same > filesystem by different users? And even simultaneously? On Wed, Jul 19, 2006 at 04:46:56PM +0200, Ralf Corsepius wrote: > On Wed, 2006-07-19 at 16:15 +0200, Axel Thimm wrote: > > On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote: > > > Axel Thimm wrote: > > > > > Two independent reviewer considered this a blocker for a > > > > review's acceptance (even though it's marked "preferred"). > > > > > > The reviewers need to be whacked with a clue-stick. A working (non-broken) > > > buildroot is *not* a blocker. > The point you seem to be missing, your buildroot is broken: > buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root No, I'm not, I added the original post above to prove I was aware of that ;) > This directory is NOT unique and will break if 2 or more users are > running an rpmbuild in parallel on the same /var/tmp filesystem. And everything will break if someone builds for i686 and i586 (e.g. a kernel or glibc) simultaneously on the same filesystem (as the same user), which is even worse and probably more common than two non-root users sharing the same build server and building *exactly* the same package EVR-wise. > It will also break if 2 different users are running buildjobs of the > same package consecutively and if the first one fails and leaves it > buildroot behind. That's what rm -fr %{buildroot} at the beginning of %install is for. But even if it were an issue you are currently in the same more realistic situation that the build for the i686 kernel may fail and the next build is the one for i586 and will find the broken buildroot from the predecessor. I'm just saying that we are focusing on an almost non-existant corner case obfuscating the BuildRoot while we allow failures in non-corner cases. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Wed Jul 19 19:59:23 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 19 Jul 2006 14:59:23 -0500 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: (Jason L. Tibbitts, III's message of "Wed, 12 Jul 2006 18:35:03 -0500") References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> <1152482379.2728.457.camel@localhost.localdomain> <20060710095844.GA14442@redhat.com> Message-ID: Trying to resurrect the PHP discussion so that we can finally put this to bed. >>>>> "JLT" == Jason L Tibbitts, writes: JLT> We have nice macros which should be in FC5 soon. As far as I can tell, the updated php-pear package isn't released yet. JLT> * FC4. Will these macros make it there, or do we just not target JLT> that release? I'm going to take this as a no. Is it problematic that we're not going to target FC4? JLT> * Guidelines. They need to be altered to take into account the JLT> existence of these new macros. I have done a first pass cleanup of what we have at http://fedoraproject.org/wiki/PackagingDrafts/PHP Still needed there: A block of Provides and Requires for PECL modules analogous to those for PEAR modules. Scriptlets for PECL module registration. Or maybe not; I have no idea if PECL modules need to be registered in the same way that PEAR modules are. More comments about non-PEAR-PECL modules. JLT> * Specfile templates. We either need a template or JLT> fedora-newrpmspec should call into the specfile generator module. What happened with this? Chris Stone had a patch; did it get reported upstream? Is there something analogous that we could do for PECL modules? - J< From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 19 20:32:08 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 19 Jul 2006 22:32:08 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <20060719190243.GB4405@neu.nirvana> (Axel Thimm's message of "Wed, 19 Jul 2006 21:02:43 +0200") References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> <20060719190243.GB4405@neu.nirvana> Message-ID: <87u05dnxo7.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> This directory is NOT unique and will break if 2 or more users are >> running an rpmbuild in parallel on the same /var/tmp filesystem. > > And everything will break if someone builds for i686 and i586 (e.g. a > kernel or glibc) simultaneously on the same filesystem (as the same > user), which is even worse and probably more common than two non-root > users sharing the same build server and building *exactly* the same > package EVR-wise. ACK; when you build on multi-user systems, you should use a secure %_tmppath instead of trusting into %(id -u). Else, attacker could create between | rm -rf $RPM_BUILD_ROOT | ... | make install --> mkinstalldir $RPM_BUILD_ROOT an $RPM_BUILD_ROOT with e.g. files for symlink attacks (it should be trivial to find the window above with inotify(2)). Therefore, multi-user environments are not an argument pro %(id -u). Enrico From ville.skytta at iki.fi Wed Jul 19 20:36:06 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 19 Jul 2006 23:36:06 +0300 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> <1152482379.2728.457.camel@localhost.localdomain> <20060710095844.GA14442@redhat.com> Message-ID: <1153341366.2683.130.camel@localhost.localdomain> On Wed, 2006-07-19 at 14:59 -0500, Jason L Tibbitts III wrote: > >>>>> "JLT" == Jason L Tibbitts, writes: > > JLT> We have nice macros which should be in FC5 soon. > > As far as I can tell, the updated php-pear package isn't released yet. > > JLT> * FC4. Will these macros make it there, or do we just not target > JLT> that release? > > I'm going to take this as a no. Is it problematic that we're not > going to target FC4? See also https://bugzilla.redhat.com/198706#c4 and the rest of the comments there: IMHO with pretty nonintrusive changes to the suggested/submitted template, no new external macros at all would be needed. From ville.skytta at iki.fi Wed Jul 19 20:37:20 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 19 Jul 2006 23:37:20 +0300 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <20060719190243.GB4405@neu.nirvana> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> <20060719190243.GB4405@neu.nirvana> Message-ID: <1153341440.2683.132.camel@localhost.localdomain> On Wed, 2006-07-19 at 21:02 +0200, Axel Thimm wrote: > I'm just saying that we are focusing on [...] ...generating a lengthy thread and a fuss about changing something that is not broken, thus negatively contributing to the already decreasing S/N ratio of packaging related discussions here and there? Sorry, can't help trolling, but that trend worries me. From Axel.Thimm at ATrpms.net Wed Jul 19 22:02:01 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 20 Jul 2006 00:02:01 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <1153341440.2683.132.camel@localhost.localdomain> References: <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> <20060719190243.GB4405@neu.nirvana> <1153341440.2683.132.camel@localhost.localdomain> Message-ID: <20060719220201.GC4405@neu.nirvana> On Wed, Jul 19, 2006 at 11:37:20PM +0300, Ville Skytt? wrote: > On Wed, 2006-07-19 at 21:02 +0200, Axel Thimm wrote: > > > I'm just saying that we are focusing on [...] > > ...generating a lengthy thread and a fuss about changing something > that is not broken, thus negatively contributing to the already > decreasing S/N ratio of packaging related discussions here and > there? Sorry, can't help trolling, but that trend worries me. I did say I assumed this to be an EasyFix item and was myself dissappointed that it turns out to become a lengthy thread. It takes more than one to generate a thread ... And obviously this seems to be something many people have really strong opinion about and also different perception of whether this is broken or not. At this point of time I wished I wouldn't had bring it up, my opinion on that is not that strong and it doesn't seem to get anywhere. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Jul 19 22:08:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 20 Jul 2006 00:08:11 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <1153319845.12430.864.camel@localhost.localdomain> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153319845.12430.864.camel@localhost.localdomain> Message-ID: <20060719220811.GD4405@neu.nirvana> On Wed, Jul 19, 2006 at 09:37:25AM -0500, Tom 'spot' Callaway wrote: > Axel, put the exact buildroot that you want to change the guidelines to > use on the todo agenda for tomorrow, and we'll vote on it. I'm not sure I'd like to waste IRC time on this. At first I thought most people would second that and that it would be a trivial item. As it stands a vote could require further discussion and we'd rather keep our IRC time for more valued items. The only thing would be a clarification of the wording that the "preferred buildroot" as quoted in the guidelines is a SHOULD item as the word "preferred" implies. I don't want to fight this battle with each review on every package I submit. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jul 19 22:11:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Jul 2006 18:11:01 -0400 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <20060719220811.GD4405@neu.nirvana> References: <20060719122927.GI13785@neu.nirvana> <1153319845.12430.864.camel@localhost.localdomain> <20060719220811.GD4405@neu.nirvana> Message-ID: <200607191811.04218.jkeating@redhat.com> On Wednesday 19 July 2006 18:08, Axel Thimm wrote: > The only thing would be a clarification of the wording that the > "preferred buildroot" as quoted in the guidelines is a SHOULD item as > the word "preferred" implies. I don't want to fight this battle with > each review on every package I submit. Sure, it's a should. I still say "Buildroot SHOULD be " even if they have a Buildroot defined. Its their choice to follow the advice. I don't block on it (anymore). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Jul 19 22:11:34 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 20 Jul 2006 00:11:34 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <87u05dnxo7.fsf@kosh.bigo.ensc.de> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> <20060719190243.GB4405@neu.nirvana> <87u05dnxo7.fsf@kosh.bigo.ensc.de> Message-ID: <1153347094.2845.5.camel@rousalka.dyndns.org> Le mercredi 19 juillet 2006 ? 22:32 +0200, Enrico Scholz a ?crit : > an $RPM_BUILD_ROOT with e.g. files for symlink attacks (it should be > trivial to find the window above with inotify(2)). > > Therefore, multi-user environments are not an argument pro %(id -u). Yes it is. You are far more likely to share resources like a build system with friendlies than with attackers. So even if you don't protect against attackers, protecting against people stomping on each other is a worthwhile goal. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Wed Jul 19 22:37:17 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 20 Jul 2006 00:37:17 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <44BE6E96.8070904@leemhuis.info> References: <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153206620.2605.2.camel@bureau.maison> <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> Message-ID: <20060719223717.GE4405@neu.nirvana> On Wed, Jul 19, 2006 at 07:40:38PM +0200, Thorsten Leemhuis wrote: > Seems Axel wants to bring kmod onto the topic again -- I can understand > his situation so let's get this discussed... > > Axel Thimm schrieb: > > On Tue, Jul 18, 2006 at 01:59:34PM +0200, Eric Tanguy wrote: > >> How is this problem handled by livna because it works fine using > >> this repo : the kernel modules are installed and not updated > >> It's known that there are issues with this scheme, or any scheme > >> that will merge module and kernel versions. > > rpm for one can't cope with it. Suppose you have two active kernels > > (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have > > foo-kmdl for both in version 1. Now foo-kmdl in version 2 is > > released. Both rpm -i (coinstall, no replacement of of foo-kmdl for > > the same kernel) and rpm -U (remove all foo-kmdl but the highest one, > > e.g. at least one kernel stay w/o any kmdl) won't work. > > Well, yes, coinstall will fail because this would result in a file > conflict. But rpm -U works fine (but removes the older version) with the > current Extras kmod scheme and "yum install foo" AFAICS works fine, too. No, rpm -U would remove both kernel modules from both kernels and only install the selected kernel module, you end up with one kernel losing the kernel module w/o replacement. rpm -U will always leave only one kernel module package behind unless these packages are disambiguated in their name by extending the name to contain the kernel's uname -r. > Well, we (fedora.us and Livna in this case) had a scheme that used > the output from "uname -r" in the name similar how atrpms still uses > it AFAICS. We (e.g. those involved in the kmod discussion for > Extras) were not satisfied with it AFICS. > > The decision against using the uname-output in the name was one of > the first ones when the Extras kmod-standard was discussed. It was a > rather quick decision IIRC to not use it. I wished I had been involved at that time to argue against this unfortunate change, but probably it was during the "cold war" where most people including myself had run out of batteries and could not try to save the world anymore :) Anyway it's never too late, I'm optimistic about the new world order. :) > > Incidentially one on my personal targets is to get thie discussed in > > the fedora packaging group and review the currently scheme. Of course, > > I'm proposing adoption of ATrpms' kmdl scheme :) > > > > http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo > > Is you scheme documented somewhere properly so we can look at it again? > Please also post a URL to the macros for FC5 (maybe rawhide, too) -- we > probably need them if we want to look at the scheme. I committed myself to prepare some documentation after asking in the packaging group whether there is general interest to review this part of the guidelines. Not only on the actual usage but also on the rationale behind it hoping that some design decisions will become more apparent. In this sense this thread is perhaps a tad too early, but it was triggered by some user discussion and led naturally to explaining some parts of it with mentioning the review proposal. But since it got started (which is a good thing) we should not let it drown again. I'll try to prepare the docs ASAP. > BTW, livna uses the Extras scheme for all kmod-packages since FC5 now. > AFICS it works a lot better than the old fedora.us scheme. There are > still some things that could need to be improved: But if it's broken already at the rpm level how can it be better? You can start teaching yum special handling, then smart and finally apt and maybe up2date since the scheme is to be used in RHEL at some point in time. But is this really the way to go? Admittedly the kmdl scheme or the old livna scheme with the uname -r in name also need some special handling, but it's easier to add the coinstall logic (e.g. 9 lines of bash code were already anough) and the drawbacks w/o that special handling are far less severe (e.g. you never run into the situation that you might blow away kernel modules of unrelated kernels with a simple rpm -U). To summarize: o schemes w/o uname -r in name - break at rpm level - depsolver special handling is therefore a *must* otherwise old working kernel may get their kernel modules nuked. And even if all depsolvers will be patched to take this into account you are still broken on rpm level. o schemes w/ uname -r in name - no coinstalls at rpm level - depsolver special handling is *nice-to-have* otherwise new kernels won't "inherit" kernel modules installed for old ones. In the worst case users have to manually reinstall kmdl after/during each kernel upgrade. The latter "worst-case" scenario is what ATrpms ships for a couple of years now. kmdl at ATrpms be it for multimedia (ivtv, v4l, nvidia) or for wireless (ipw*, madwifi) have a large userbase that seem to cope well with reinstalling kmdls after a kernel upgrade (it's just the 9-liner bash scriplet after all). So field experiance if you'd like to call it, already shows that uname-r-in-name schemes are indeed consumable. > > How the dependencies to the kernel are installed (which is responsible > > for having an automatic removal on kernel removal) is a different > > story, which the version merging does not break. The issue is with the > > system (system=rpm and(or any higher depsolver tool, > > e.g. yum/smart/apt) being able to distinguish different foo-kmdls as > > _upgrades_ vs _coinstalls_. > > As I said, > Provides: kernel-modules > and yum will install them. When you run rpm directly you are on your own > -- it similar with the kernel itself. No, with the kernel it's always just rpm -i, never rpm -U, that's all a user needs to know. With kernel modules w/o uname-r-in-name you can easily run into a situation where you need something in between like the example above: Coinstall wrt to an installed kernel module package for another kernel, but upgrade any installed kernel module package for the matching kernel. In order for a depsolver to get that logic installed you need to reverse engineer the two dimensional versions of modules and kernel out of the kernel module package and define a completly new "upgrade/coinstall" mechanism with is definitely not any more rpm CLI compatible. And losing that only because kernel modules packages w/ uname-r-in-name look ugly isn't worth it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jul 19 22:59:37 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 19 Jul 2006 18:59:37 -0400 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060719223717.GE4405@neu.nirvana> References: <1153172566.3515.3.camel@bureau.maison> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> Message-ID: <200607191859.40796.jkeating@redhat.com> On Wednesday 19 July 2006 18:37, Axel Thimm wrote: > I wished I had been involved at that time to argue against this > unfortunate change, but probably it was during the "cold war" where > most people including myself had run out of batteries and could not > try to save the world anymore :) > > Anyway it's never too late, I'm optimistic about the new world > order. This becomes important as kernel ABI starts working, and you can build a module for a given kernel ABI and have it work on any new (or old) kernel that maintains the same ABI. No longer will modules be locked to a specific kernel version, and thus uname -r becomes irrelevant. I do believe Jon Masters is giving a talk on this at OLS. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Wed Jul 19 23:20:23 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 19 Jul 2006 18:20:23 -0500 Subject: [Fedora-packaging] fedora-newrpmspec patch for php-pear In-Reply-To: <1153341366.2683.130.camel@localhost.localdomain> (Ville Skytt's message of "Wed, 19 Jul 2006 23:36:06 +0300") References: <1152311681.11594.1.camel@localhost.localdomain> <87fyhcjhkk.fsf@kosh.bigo.ensc.de> <1152482379.2728.457.camel@localhost.localdomain> <20060710095844.GA14442@redhat.com> <1153341366.2683.130.camel@localhost.localdomain> Message-ID: >>>>> "VS" == Ville Skytt writes: VS> IMHO with pretty nonintrusive changes to the suggested/submitted VS> template, no new external macros at all would be needed. I didn't realize that a ticket had been opened for that. Honestly I don't care what is accepted; I just think we need to make some forward progress. But after a quick look at your template, it does seem really nice, especially the file list generation. I wonder if we couldn't do that for Python, where the complexity involving .pyo files is often needlessly confusing. Another topic, I guess. Obviously it would be nice to not have to wait for an update to the core php-pear package before we move ahead. On the other hand, Joe was nice enough to add the macros for us; we should at least be sure not to conflict with them. So what to do? We can't really proceed with the guidelines (at least for the PEAR bits) without knowing what's going into fedora-newrpmspec. We also really need to decide whether PECL modules need a template. I'm guessing they do, but I haven't actually looked at one. Finally, to answer a question in that ticket, all PEAR modules are indeed noarch and all PECL modules are arch-specific, by definition as I understand it. - J< From rc040203 at freenet.de Thu Jul 20 02:22:57 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 20 Jul 2006 04:22:57 +0200 Subject: [Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <20060719190243.GB4405@neu.nirvana> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> <20060719190243.GB4405@neu.nirvana> Message-ID: <1153362178.32123.17.camel@mccallum.corsepiu.local> On Wed, 2006-07-19 at 21:02 +0200, Axel Thimm wrote: > On Wed, Jul 19, 2006 at 02:29:27PM +0200, Axel Thimm wrote: > > Also consider what this really is about: Deambiguifying the > > BuildRoot per package makes sense as there may be several build > > processes sharing the same filesystem (either locally or through > > NFS), but deambiguifying the build user, too, means that we assume > > that the same EVR package will be possibly built on the same > > filesystem by different users? And even simultaneously? > > On Wed, Jul 19, 2006 at 04:46:56PM +0200, Ralf Corsepius wrote: > > On Wed, 2006-07-19 at 16:15 +0200, Axel Thimm wrote: > > > On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote: > > > > Axel Thimm wrote: > > > > > > > Two independent reviewer considered this a blocker for a > > > > > review's acceptance (even though it's marked "preferred"). > > > > > > > > The reviewers need to be whacked with a clue-stick. A working (non-broken) > > > > buildroot is *not* a blocker. > > > The point you seem to be missing, your buildroot is broken: > > buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root > > No, I'm not, I added the original post above to prove I was aware of > that ;) > > > This directory is NOT unique and will break if 2 or more users are > > running an rpmbuild in parallel on the same /var/tmp filesystem. > > And everything will break if someone builds for i686 and i586 (e.g. a > kernel or glibc) simultaneously on the same filesystem (as the same > user), True, i.e. defect/bug. > > It will also break if 2 different users are running buildjobs of the > > same package consecutively and if the first one fails and leaves it > > buildroot behind. > > That's what rm -fr %{buildroot} at the beginning of %install is > for. Nope, these buildroots will carry different uids => User2 cannot remove user1's buildroot. Let me demonstrate it with one of your rpms: # su -l user1 # rpmbuild -bi vtkdata.spec # exit # su -l user2 # rpmbuild -bb vtkdata.spec ... + rm -rf /var/tmp/vtkdata-5.0.1-4-root rm: cannot remove `/var/tmp/vtkdata-5.0.1-4-root/usr/share/vtkdata-5.0.1/Data/cth.vtr': Permission denied rm: cannot remove `/var/tmp/vtkdata-5.0.1-4-root/usr/share/vtkdata-5.0.1/Data/Particles.raw': Permission denied ... With FE's current buildroot this case doesn't happen. > I'm just saying that we are focusing on an almost non-existant corner > case obfuscating the BuildRoot while we allow failures in non-corner > cases. I don't see how working in a multiuser environment would qualify as a corner case. Building for different target archs to me is a corner case, but that's probably a matter of personal background. The above situation above would easily happen if working in a team, e.g. when developing an rpm.spec. Ralf From jjneely at ncsu.edu Thu Jul 20 14:59:47 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Thu, 20 Jul 2006 10:59:47 -0400 Subject: [Fedora-packaging] Yum Kernel Module Plugin Message-ID: <20060720145947.GQ2954@anduril.unity.ncsu.edu> Folks, I did some work on the fedorakmod.py plugin for Yum a couple weeks ago before I left for a bit of vacation. I've returned *sigh* and haven't seen any feedback from it. The code is in yum-utils CVS and will be in that package the next time its released. I support kernel module upgrading (where an older module needs to be removed to avoid file conflicts) and pinning the kernel until the kernel modules the system uses are available for the new kernel. What functionality from the plugin would folks like to see in FC6 so that we could be closer to having kernel modules in extras? Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From tibbs at math.uh.edu Thu Jul 20 15:42:21 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 20 Jul 2006 10:42:21 -0500 Subject: [Fedora-packaging] Yum Kernel Module Plugin In-Reply-To: <20060720145947.GQ2954@anduril.unity.ncsu.edu> (Jack Neely's message of "Thu, 20 Jul 2006 10:59:47 -0400") References: <20060720145947.GQ2954@anduril.unity.ncsu.edu> Message-ID: >>>>> "JN" == Jack Neely writes: JN> Folks, I did some work on the fedorakmod.py plugin for Yum a JN> couple weeks ago before I left for a bit of vacation. I've JN> returned *sigh* and haven't seen any feedback from it. Sorry, I don't recall having seen you post about it here previously. JN> [...] and pinning the kernel until the kernel modules the system JN> uses are available for the new kernel. Ahhh, that is just huge. What version of yum is supported? I'd test on FC5 now if it's supported. - J< From fedora at leemhuis.info Thu Jul 20 15:58:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Jul 2006 17:58:02 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060719223717.GE4405@neu.nirvana> References: <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153206620.2605.2.camel@bureau.maison> <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> Message-ID: <44BFA80A.6040709@leemhuis.info> Axel Thimm schrieb: > On Wed, Jul 19, 2006 at 07:40:38PM +0200, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: >>> rpm for one can't cope with it. Suppose you have two active kernels >>> (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have >>> foo-kmdl for both in version 1. Now foo-kmdl in version 2 is >>> released. Both rpm -i (coinstall, no replacement of of foo-kmdl for >>> the same kernel) and rpm -U (remove all foo-kmdl but the highest one, >>> e.g. at least one kernel stay w/o any kmdl) won't work. >> Well, yes, coinstall will fail because this would result in a file >> conflict. But rpm -U works fine (but removes the older version) with the >> current Extras kmod scheme and "yum install foo" AFAICS works fine, too. > No, rpm -U would remove both kernel modules from both kernels and only > install the selected kernel module, you end up with one kernel losing > the kernel module w/o replacement. > > rpm -U will always leave only one kernel module package behind unless > these packages are disambiguated in their name by extending the name > to contain the kernel's uname -r. I don't want to reply to the other aspects of this mail -- I don't think it makes to much sense now and prefer to wait for the docs from Axel. But it seems we talked pass each other in above section so I'll try to give an example to show the behavior with the current Extras scheme (note this is not tested, only written down how it works afaik): $ rpm -q kernel kernel-2.6.17-1.2145_FC5 kernel-2.6.17-1.2157_FC5 kernel-smp-2.6.17-1.2157_FC5 $ rpm -qa kmod-ntfs* kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 kmod-ntfs-2.1.27-1.2.6.17_1.2157_FC5 kmod-ntfs-smp-2.1.27-1.2.6.17_1.2157_FC5 kmod-ntfs{,-smp,xen0,...}-2.1.27-2.2.6.17_1.2157_FC5 show up in the repo and user runs yum update. After that: $ rpm -qa kmod-ntfs* kmod-ntfs-2.1.27-2.2.6.17_1.2157_FC5 kmod-ntfs-smp-2.1.27-2.2.6.17_1.2157_FC5 E.g. yes, kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 got removed. No, both the up and the smp-kernel still have their modules. CU thl From fedora at leemhuis.info Thu Jul 20 16:13:33 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Jul 2006 18:13:33 +0200 Subject: [Fedora-packaging] Yum Kernel Module Plugin In-Reply-To: <20060720145947.GQ2954@anduril.unity.ncsu.edu> References: <20060720145947.GQ2954@anduril.unity.ncsu.edu> Message-ID: <44BFABAD.6070206@leemhuis.info> Jack Neely schrieb: > The code is in yum-utils CVS and will be in that package the next time > its released. thx for your work! > I support kernel module upgrading (where an older module > needs to be removed to avoid file conflicts) and pinning the kernel > until the kernel modules the system uses are available for the new > kernel. Hmmm, pinning sounds nice, but should we enable it as default? The questions afaics simply is: Whats more important? Running the latest kernel where all known security problems are fixed or running a kernel where all modules are present? I'd prefer the solution where all security problems are fixed, even if I lose functionality. I know, that not ideal in every situation, but security IMHO is more important so it should be the default. If users modify it than it's not our fault. > What functionality from the plugin would folks like to see in FC6 so > that we could be closer to having kernel modules in extras? There is one oddity currently discussed on fedora-packaging. Maybe you can fix it in your plugin easily: Situation: $ rpm -q kernel kernel-2.6.17-1.2145_FC5 kernel-2.6.17-1.2157_FC5 kernel-smp-2.6.17-1.2157_FC5 $ rpm -qa kmod-ntfs* kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 kmod-ntfs-2.1.27-1.2.6.17_1.2157_FC5 kmod-ntfs-smp-2.1.27-1.2.6.17_1.2157_FC5 kmod-ntfs{,-smp,xen0,...}-2.1.27-2.2.6.17_1.2157_FC5 show up in the repo and user runs yum update. After that: $ rpm -qa kmod-ntfs* kmod-ntfs-2.1.27-2.2.6.17_1.2157_FC5 kmod-ntfs-smp-2.1.27-2.2.6.17_1.2157_FC5 e.g. kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 was removed. Can that be circumvented? BTW, does a simple "yum install kmod-foo" now install modules for all kernel-variants taht are present? E.g. I'd like to see this: $ rpm -q kernel kernel-2.6.17-1.2157_FC5 kernel-smp-2.6.17-1.2157_FC5 $ yum install kmod-foo [...] $ rpm -qa kmod-foo* kmod-foo-2.1.27-1.2.6.17_1.2157_FC5 kmod-foo-smp-2.1.27-1.2.6.17_1.2157_FC5 CU thl From jjneely at ncsu.edu Thu Jul 20 16:40:26 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Thu, 20 Jul 2006 12:40:26 -0400 Subject: [Fedora-packaging] Yum Kernel Module Plugin In-Reply-To: <44BFABAD.6070206@leemhuis.info> References: <20060720145947.GQ2954@anduril.unity.ncsu.edu> <44BFABAD.6070206@leemhuis.info> Message-ID: <20060720164026.GT2954@anduril.unity.ncsu.edu> On Thu, Jul 20, 2006 at 06:13:33PM +0200, Thorsten Leemhuis wrote: > Jack Neely schrieb: > > > The code is in yum-utils CVS and will be in that package the next time > > its released. > > thx for your work! > > > I support kernel module upgrading (where an older module > > needs to be removed to avoid file conflicts) and pinning the kernel > > until the kernel modules the system uses are available for the new > > kernel. > > Hmmm, pinning sounds nice, but should we enable it as default? The > questions afaics simply is: > > Whats more important? Running the latest kernel where all known security > problems are fixed or running a kernel where all modules are present? > I'd prefer the solution where all security problems are fixed, even if I > lose functionality. I know, that not ideal in every situation, but > security IMHO is more important so it should be the default. If users > modify it than it's not our fault. > *nod* Its configurable for this purpose. My insitution has to have OpenAFS working, but in the general case I agree. I think its set to on on yum-utils right now, I'll make sure it defaults to off. > > What functionality from the plugin would folks like to see in FC6 so > > that we could be closer to having kernel modules in extras? > > There is one oddity currently discussed on fedora-packaging. Maybe you > can fix it in your plugin easily: > > Situation: > > $ rpm -q kernel > kernel-2.6.17-1.2145_FC5 > kernel-2.6.17-1.2157_FC5 > kernel-smp-2.6.17-1.2157_FC5 > $ rpm -qa kmod-ntfs* > kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 > kmod-ntfs-2.1.27-1.2.6.17_1.2157_FC5 > kmod-ntfs-smp-2.1.27-1.2.6.17_1.2157_FC5 > > kmod-ntfs{,-smp,xen0,...}-2.1.27-2.2.6.17_1.2157_FC5 show up in the repo > and user runs yum update. After that: > > $ rpm -qa kmod-ntfs* > kmod-ntfs-2.1.27-2.2.6.17_1.2157_FC5 > kmod-ntfs-smp-2.1.27-2.2.6.17_1.2157_FC5 > > e.g. kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 was removed. Can that be > circumvented? > Yes. This is within the module's current functionality. Kernel modules are installed only. The only time a kmod is removed is when there is an updated version for a kernel that already has an older version of that kmod installed for it. > BTW, does a simple "yum install kmod-foo" now install modules for all > kernel-variants taht are present? E.g. I'd like to see this: > Not yet. But I'm not done yet. Jack > $ rpm -q kernel > kernel-2.6.17-1.2157_FC5 > kernel-smp-2.6.17-1.2157_FC5 > $ yum install kmod-foo > [...] > $ rpm -qa kmod-foo* > kmod-foo-2.1.27-1.2.6.17_1.2157_FC5 > kmod-foo-smp-2.1.27-1.2.6.17_1.2157_FC5 > > CU > thl > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jjneely at ncsu.edu Thu Jul 20 16:44:10 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Thu, 20 Jul 2006 12:44:10 -0400 Subject: [Fedora-packaging] Yum Kernel Module Plugin In-Reply-To: References: <20060720145947.GQ2954@anduril.unity.ncsu.edu> Message-ID: <20060720164410.GU2954@anduril.unity.ncsu.edu> > Ahhh, that is just huge. What version of yum is supported? I'd test > on FC5 now if it's supported. > > - J< > Test with Yum 2.9.3. I needed to add a couple bits to the PackageObject classes to make things work sanely. Jack -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From Axel.Thimm at ATrpms.net Fri Jul 21 05:22:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 21 Jul 2006 07:22:11 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <44BFA80A.6040709@leemhuis.info> References: <1153206620.2605.2.camel@bureau.maison> <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> Message-ID: <20060721052211.GD14267@neu.nirvana> On Thu, Jul 20, 2006 at 05:58:02PM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Wed, Jul 19, 2006 at 07:40:38PM +0200, Thorsten Leemhuis wrote: > >> Axel Thimm schrieb: > >>> rpm for one can't cope with it. Suppose you have two active kernels > >>> (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have > >>> foo-kmdl for both in version 1. Now foo-kmdl in version 2 is > >>> released. Both rpm -i (coinstall, no replacement of of foo-kmdl for > >>> the same kernel) and rpm -U (remove all foo-kmdl but the highest one, > >>> e.g. at least one kernel stay w/o any kmdl) won't work. > >> Well, yes, coinstall will fail because this would result in a file > >> conflict. But rpm -U works fine (but removes the older version) with the > >> current Extras kmod scheme and "yum install foo" AFAICS works fine, too. > > No, rpm -U would remove both kernel modules from both kernels and only > > install the selected kernel module, you end up with one kernel losing > > the kernel module w/o replacement. > > > > rpm -U will always leave only one kernel module package behind unless > > these packages are disambiguated in their name by extending the name > > to contain the kernel's uname -r. > > I don't want to reply to the other aspects of this mail -- I don't think > it makes to much sense now and prefer to wait for the docs from Axel. > But it seems we talked pass each other in above section so I'll try to > give an example to show the behavior with the current Extras scheme > (note this is not tested, only written down how it works afaik): No, I don't think we talked past each other, you are giving a perfect example outlining the design bug of any non-uname-r-in-name scheme. > $ rpm -q kernel > kernel-2.6.17-1.2145_FC5 > kernel-2.6.17-1.2157_FC5 > kernel-smp-2.6.17-1.2157_FC5 > $ rpm -qa kmod-ntfs* > kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 > kmod-ntfs-2.1.27-1.2.6.17_1.2157_FC5 > kmod-ntfs-smp-2.1.27-1.2.6.17_1.2157_FC5 > > kmod-ntfs{,-smp,xen0,...}-2.1.27-2.2.6.17_1.2157_FC5 show up in the repo > and user runs yum update. After that: > > $ rpm -qa kmod-ntfs* > kmod-ntfs-2.1.27-2.2.6.17_1.2157_FC5 > kmod-ntfs-smp-2.1.27-2.2.6.17_1.2157_FC5 > > E.g. yes, kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 got removed. Which is the bug in the scheme. You don't want to only support the rpm-latest kernel, just as you want to give freedom to the users to have multiple kernel rpms installed (of different versions) as it too often happens that the new kernel may not work on their systems. E.g. every policy you follow for the kernel rpms themselves needs to be followed for the per-kernel installed kernel modules. So the kernel module of the "old" kernels need to stay untouched, by rpm and any higher-level packaging manager/depsolver. Ignoring the bug on rpm CLI level and trying to fix all depsolvers out there is IMO wrong. rpm CLI needs to do a reasonable operation when presented these kernel module packages, not "accidentally" nuke away parts for the working previous (and perhaps already running) kernel. The next horror scenario is to decide to keep this scheme and start working around it in each depsolver leaving some out like for example the increasing in popularity smart depsolver. smart upgrade would then happily nuke your display driver kernel module of the running kernel! Same for apt and up2date. In fact the above is not to be layed in the future, but it's the current situation w/ for example livna, or not? Aren't there any livna reports that they lost their nvidia driver for old kernels while updateing their system? > No, both the up and the smp-kernel still have their modules. And the reason is kernel flavour disambiguation through the name. Add the kernel's version to the name and you'll fix the bug mentioned above. And suddenly it's a uname-r-in-name scheme again and very close to kmdl systems (so let's pick that design and be all happy). So, do we at least agree that the current kernel modules scheme breaks on rpm CLI level? Neither rpm -i, nor rpm -U could get you out of the above (typical!) situation. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Jul 21 15:51:10 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 21 Jul 2006 17:51:10 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060721052211.GD14267@neu.nirvana> References: <1153206620.2605.2.camel@bureau.maison> <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> Message-ID: <44C0F7EE.6010702@leemhuis.info> Axel Thimm schrieb: > On Thu, Jul 20, 2006 at 05:58:02PM +0200, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: >>> On Wed, Jul 19, 2006 at 07:40:38PM +0200, Thorsten Leemhuis wrote: >>>> Axel Thimm schrieb: >>>>> rpm for one can't cope with it. Suppose you have two active kernels >>>>> (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have >>>>> foo-kmdl for both in version 1. Now foo-kmdl in version 2 is >>>>> released. Both rpm -i (coinstall, no replacement of of foo-kmdl for >>>>> the same kernel) and rpm -U (remove all foo-kmdl but the highest one, >>>>> e.g. at least one kernel stay w/o any kmdl) won't work. >>>> Well, yes, coinstall will fail because this would result in a file >>>> conflict. But rpm -U works fine (but removes the older version) with the >>>> current Extras kmod scheme and "yum install foo" AFAICS works fine, too. >>> No, rpm -U would remove both kernel modules from both kernels and only >>> install the selected kernel module, you end up with one kernel losing >>> the kernel module w/o replacement. >>> rpm -U will always leave only one kernel module package behind unless >>> these packages are disambiguated in their name by extending the name >>> to contain the kernel's uname -r. >> I don't want to reply to the other aspects of this mail -- I don't think >> it makes to much sense now and prefer to wait for the docs from Axel. >> But it seems we talked pass each other in above section so I'll try to >> give an example to show the behavior with the current Extras scheme >> (note this is not tested, only written down how it works afaik): > > No, I don't think we talked past each other, you are giving a perfect > example outlining the design bug of any non-uname-r-in-name scheme. Well, you said "Suppose you have two active kernels (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) [...]e.g. at least one kernel stay w/o any kmdl[...]" above -- and xen0 and non-xen0 work fine with the scheme, both have a module. >> $ rpm -q kernel >> kernel-2.6.17-1.2145_FC5 >> kernel-2.6.17-1.2157_FC5 >> kernel-smp-2.6.17-1.2157_FC5 >> $ rpm -qa kmod-ntfs* >> kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 >> kmod-ntfs-2.1.27-1.2.6.17_1.2157_FC5 >> kmod-ntfs-smp-2.1.27-1.2.6.17_1.2157_FC5 >> >> kmod-ntfs{,-smp,xen0,...}-2.1.27-2.2.6.17_1.2157_FC5 show up in the repo >> and user runs yum update. After that: >> >> $ rpm -qa kmod-ntfs* >> kmod-ntfs-2.1.27-2.2.6.17_1.2157_FC5 >> kmod-ntfs-smp-2.1.27-2.2.6.17_1.2157_FC5 >> >> E.g. yes, kmod-ntfs-2.1.27-1.2.6.17_1.2145_FC5 got removed. > > Which is the bug in the scheme. Well, seems to be a bug for you. Okay, noted. I'd consider is as an minor annoyance. And it seems Jack Neely is working on getting it fixed. > You don't want to only support the > rpm-latest kernel, To support only the latest kernel was a decided early in the kmod discussion. That might have influenced the kmod standard. BTW, when we initially discussed the kmod standard there was also (IIRC) a strong resistance from multiple important and well known people at redhat against overloading %{NAME} with the output of "uname -r". I doubt that option changed. Spot? Jeremy? f13? [...] > In fact the above is not to be layed in the future, but it's the > current situation w/ for example livna, or not? Aren't there any livna > reports that they lost their nvidia driver for old kernels while > updateing their system? Nobody reported a bug yet. And the nvidia driver is a good example: we even have explicit "Obsoletes" in the spec to make sure old modules always get removed because nvidia-1.2.3 only works with kmod-nvidia-1.2.3, but not with kmod-nvidia-1.2.2 >> No, both the up and the smp-kernel still have their modules. > And the reason is kernel flavour disambiguation through the name. Add > the kernel's version to the name and you'll fix the bug mentioned > above. And suddenly it's a uname-r-in-name scheme again and very close > to kmdl systems (so let's pick that design and be all happy). And it also needs special support in depsolvers so you get all kernel-modules together with a kernel update. And you need to maintain a lot of obsoletes to get old kmods removed that are incompatible with the updated userland packages. Or you need to build kmods for each and every kernel that ever shipped -- that would take to long (and they are often not available anymore). > So, do we at least agree that the current kernel modules scheme breaks > on rpm CLI level? No. > Neither rpm -i, nor rpm -U could get you out of the > above (typical!) situation. I don't consider it a big problem. CU thl From rdieter at math.unl.edu Fri Jul 21 16:35:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 21 Jul 2006 11:35:28 -0500 Subject: [Fedora-packaging] Re: rawhide report: 20060721 changes References: <200607210951.k6L9p3Es008321@hs20-bc2-6.build.redhat.com> Message-ID: buildsys at redhat.com wrote: > Updated Packages: ... > alsa-lib-1.0.12-1.rc1 > alsa-utils-1.0.12-1.rc1 Red alert. Packaging/NamingGuidelines have been breached. Raise shields. (: -- Rex From tcallawa at redhat.com Fri Jul 21 17:06:39 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 21 Jul 2006 12:06:39 -0500 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <44C0F7EE.6010702@leemhuis.info> References: <1153206620.2605.2.camel@bureau.maison> <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> Message-ID: <1153501599.26196.10.camel@localhost.localdomain> On Fri, 2006-07-21 at 17:51 +0200, Thorsten Leemhuis wrote: > BTW, when we initially discussed the kmod standard there was also (IIRC) > a strong resistance from multiple important and well known people at > redhat against overloading %{NAME} with the output of "uname -r". I > doubt that option changed. Spot? Jeremy? f13? Yep. I'm still very strongly against overloading %{NAME}. We don't permit any other package to do this for any reason, and I don't want to start now. Name is not for versioning. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From Axel.Thimm at ATrpms.net Fri Jul 21 17:57:46 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 21 Jul 2006 19:57:46 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153501599.26196.10.camel@localhost.localdomain> References: <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> Message-ID: <20060721175746.GA16006@neu.nirvana> On Fri, Jul 21, 2006 at 12:06:39PM -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-07-21 at 17:51 +0200, Thorsten Leemhuis wrote: > > > BTW, when we initially discussed the kmod standard there was also (IIRC) > > a strong resistance from multiple important and well known people at > > redhat against overloading %{NAME} with the output of "uname -r". I > > doubt that option changed. Spot? Jeremy? f13? > > Yep. I'm still very strongly against overloading %{NAME}. We don't > permit any other package to do this for any reason, and I don't want to > start now. Name is not for versioning. Well, it's good to know as that kills any review attempt of the current scheme. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jul 21 18:32:22 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 21 Jul 2006 20:32:22 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <44C0F7EE.6010702@leemhuis.info> References: <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> Message-ID: <20060721183222.GB16006@neu.nirvana> On Fri, Jul 21, 2006 at 05:51:10PM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > >> I don't want to reply to the other aspects of this mail -- I don't think > >> it makes to much sense now and prefer to wait for the docs from Axel. Well, maybe there won't be any docs, we should really decide on the uname -r thing first, otherwise the docs will be invalid and unneccessary. > > No, I don't think we talked past each other, you are giving a perfect > > example outlining the design bug of any non-uname-r-in-name scheme. > > Well, you said "Suppose you have two active kernels (say 2.6.16 and > 2.6.17 or xen0 and non-xen0 etc.) [...]e.g. at least one kernel stay w/o > any kmdl[...]" above -- and xen0 and non-xen0 work fine with the scheme, > both have a module. OK, forget about the kernel flavours, I noted that further below, but the bigger bug is still in place: Nuking of kernel modules of all previous kernels including the one currently running and installing the next kernel. > Well, seems to be a bug for you. Okay, noted. I'd consider is as an > minor annoyance. And it seems Jack Neely is working on getting it fixed. He can't fix it on rpm level, and therefore each any every depsolver needs patching, will he do that for all major 4 (yum/smart/apt/up2date), or will we have to say don't use depsolvers 2-4 and any other future depsolver/applet because they don't fix the breakage we introduced at rpm level? And I stongly disagree with calling silently removing kernel modules for all installed kernels a "minor annoyance" (?). When upgrading to a new kernel one of the "old" kernels is by definition the one you are currently running. So nuking your display driver, maybe even your storage access (imagine ISV's 3w*, qla*) while upgrading is a critical bug IMO. > > You don't want to only support the rpm-latest kernel, > > To support only the latest kernel was a decided early in the kmod > discussion. That might have influenced the kmod standard. Maybe, but that's a wrong decision. It can only be decided that way if the previous kernel is also immediately obsoleted in the sense that it shouldn't even serve as a fallback anymore. That's a policy that can't go through. And having one policy for the kernel and another for modules is wrong, too. Imagine a policy of "we support the previous kernel for some transitions time, but only stripped from it's kernel modules?" > > In fact the above is not to be layed in the future, but it's the > > current situation w/ for example livna, or not? Aren't there any livna > > reports that they lost their nvidia driver for old kernels while > > updateing their system? > > Nobody reported a bug yet. And the nvidia driver is a good example: we > even have explicit "Obsoletes" in the spec to make sure old modules > always get removed because nvidia-1.2.3 only works with > kmod-nvidia-1.2.3, but not with kmod-nvidia-1.2.2 That's different, you are referring to module's version, not the kernel's. It's the kernel's version (e..g uname -r) that gets in the way. > >> No, both the up and the smp-kernel still have their modules. > > And the reason is kernel flavour disambiguation through the name. Add > > the kernel's version to the name and you'll fix the bug mentioned > > above. And suddenly it's a uname-r-in-name scheme again and very close > > to kmdl systems (so let's pick that design and be all happy). > > And it also needs special support in depsolvers so you get all > kernel-modules together with a kernel update. No, that's an unfair comparison. o Special support for kmdls is far easier to implement: No need to introduce special non-rpm versioning, half the work is already done by natural rpm ordering, only the coinstallation upon new kernel installs needs to be done. Remember the the 9-liner in bash? That's all there is to it, port that to python and let someone who has looked at yum plugins looks over it for a minute and you're ready. Due to it's simplicity it's is also rather bug-free from the beginning. o Not having special support for kmdls isn't as critical: The worst case is that the new kernel has no initial kmdls. But upgrading of old kmdls works as expected and there is no danger of nuking away unrelated kernel modules. IMO these make a very large difference in the quality, neccessity and ease of implementation of "required special support" in both schemes. > And you need to maintain a lot of obsoletes to get old kmods removed > that are incompatible with the updated userland packages. No, that's not neccessary, if you have the proper dependencies in place, which the kmdl scheme automatically has. > Or you need to build kmods for each and every kernel that ever > shipped -- that would take to long (and they are often not available > anymore). No, that's also not neccessary. You only build for the kernels you care about, e.g. the ones that the buildsystem considers still supported in whatever sense (e.g. exist in updates-relased). > > So, do we at least agree that the current kernel modules scheme breaks > > on rpm CLI level? > > No. Not being able to use rpm CLI, and if used using to either (partial) module overwrites or nuking of old kernel modules is no breakage? Well, we really differ in opinion here, I consider this a big design flaw to drop direct rpm support or to allow for overwrites/nuking to happen. > > Neither rpm -i, nor rpm -U could get you out of the > > above (typical!) situation. > > I don't consider it a big problem. So what's your cure of the problem? Disallow using /usr/bin/rpm? Moving it away and only allowing access through yum? We know rpm needs higher level tools to really manage the packages including net access to packages, but until now it's been an iron rule to remain rpm compatible (which means rpm -U/-i/-F should be applicable). Aynway if there is an unmovable blocker/veto by someone that the name may only contain kernel flavour, but no further uname -r, and he/they cannot be convinced otherwise the cause is lost right from the start. Before losing more time into this, this pricipal issue should be resolved (maybe by a vote on next Thursday), as my doc work will be wasted (in this scope) right from the start. Thorsten, besides commenting on this mail, would you have time next Thursday 1h before the fesco meeting to join #fedora-packaging for this? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jul 21 18:35:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 21 Jul 2006 20:35:53 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060721175746.GA16006@neu.nirvana> References: <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> <20060721175746.GA16006@neu.nirvana> Message-ID: <20060721183553.GC16006@neu.nirvana> On Fri, Jul 21, 2006 at 07:57:46PM +0200, Axel Thimm wrote: > On Fri, Jul 21, 2006 at 12:06:39PM -0500, Tom 'spot' Callaway wrote: > > On Fri, 2006-07-21 at 17:51 +0200, Thorsten Leemhuis wrote: > > > > > BTW, when we initially discussed the kmod standard there was also (IIRC) > > > a strong resistance from multiple important and well known people at > > > redhat against overloading %{NAME} with the output of "uname -r". I > > > doubt that option changed. Spot? Jeremy? f13? > > > > Yep. I'm still very strongly against overloading %{NAME}. We don't > > permit any other package to do this for any reason, and I don't want to > > start now. Name is not for versioning. > > Well, it's good to know as that kills any review attempt of the > current scheme. Does it make sense to gather all people against a uname -r in name scheme to try to persuade otherwise? Either in the regular #fedora-packaging meetings or on a special meeting? I really thing there is a flaw and the uname-r-in-name is the only way out, and I'd try to persuade people about that. Maybe they could be poited to this mail thread as well, as everything is in principle layed out here. Or, if you know it's a lost cause, let's silence this topic, which would be a rather sad outcome. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sat Jul 22 08:31:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 22 Jul 2006 10:31:32 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060721183222.GB16006@neu.nirvana> References: <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <20060721183222.GB16006@neu.nirvana> Message-ID: <44C1E264.1060908@leemhuis.info> Axel Thimm schrieb: > On Fri, Jul 21, 2006 at 05:51:10PM +0200, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: > [...] > Thorsten, besides commenting on this mail, would you have time next > Thursday 1h before the fesco meeting to join #fedora-packaging for > this? I don't know yet for sure if I have time then next Thursday, but I currently suppose I'm online then and in that case I of course can join that channel *if* the Committee wants to discuss this. CU thl From bugs.michael at gmx.net Sat Jul 22 12:04:17 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 22 Jul 2006 14:04:17 +0200 Subject: [Fedora-packaging] Extras packages violating versioning schemes Message-ID: <20060722140417.aa4a9f65.bugs.michael@gmx.net> From all packages in Extras, the following "Release" tag styles are chosen: Type pre-release : 47 Type %define rel : 1 Type %define release : 2 Type %define RELEASE : 0 Type normal : 1882 The following packages violate the versioning scheme for pre-releases: devel/azureus/azureus.spec Release: 0.20060529cvs_1%{?dist} devel/libapreq2/libapreq2.spec Release: 0.rc4.1%{?dist} devel/moin-latex/moin-latex.spec Release: 0.20051126.2%{?dist} devel/ktrack/ktrack.spec Release: 13.rc1%{?dist} devel/net6/net6.spec Release: 4.%{_rc}%{?dist} Should be Release: 0.1.20060529cvs%{?dist} Release: 0.1.rc4%{?dist} Release: 0.2.20051126%{?dist} Release: 0.13.rc1%{?dist} Release: 0.4.%{_rc}%{?dist} but that's impossible now. My version-bump script caught these, when I started porting it from Perl to Python. And I haven't made it examine the 1882 "normal" release tags yet. ;) Well, a few odd cases which I have not classified yet: Release: 2.0%{?dist} Release: 2.6%{?dist} Release: 5.20041017%{?dist} Release: 0.s11.9%{?dist} Release: 0.pre2%{?dist} Release: 9.%{releasename}%{?dist} Release: 1%{?pre:.%{pre}}%{?dist} Release: 3.FC4 Release: 3.2%{?dist} Release: 2.6.3.2.2%{?dist} Release: 0%{?nm_vpnc_cvs_version}.1%{?dist} Release: 0.%{ghdlsvnver}svn.2%{?dist} Release: 1%{?prerelease:.%{prerelease}}%{?dist} From jkeating at redhat.com Sat Jul 22 13:45:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Jul 2006 09:45:51 -0400 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060721183553.GC16006@neu.nirvana> References: <20060718084104.GA2997@neu.nirvana> <20060721175746.GA16006@neu.nirvana> <20060721183553.GC16006@neu.nirvana> Message-ID: <200607220945.51929.jkeating@redhat.com> On Friday 21 July 2006 14:35, Axel Thimm wrote: > I really thing there is a flaw and the uname-r-in-name is the only way > out, and I'd try to persuade people about that. Maybe they could be > poited to this mail thread as well, as everything is in principle layed > out here. With the kabi stuff coming along, there is no longer a need to lock a given module to a given kernel version, just an ABI version. The kernel could easily be bumped a version but the ABI that a particular module needs would remain unchanged, and thus the module will continue to work. Locking to a uname will be pointless at this point. Jon Masters is giving (gave?) a talk about this at OLS and was discussing these things at the kernel summit I do believe. I strongly feel we wait for him to return from OLS so that we can include him in the discussion surrounding packaging of external kernel modules. As it stands, the development kernel does automatically provide an ABI checksum for each module subdirectory, and rpm knows about it. Requires on an ABI supposedly works today. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at laiskiainen.org Sun Jul 23 06:39:44 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 22 Jul 2006 23:39:44 -0700 (PDT) Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153501599.26196.10.camel@localhost.localdomain> References: <1153206620.2605.2.camel@bureau.maison> <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> Message-ID: On Fri, 21 Jul 2006, Tom 'spot' Callaway wrote: > On Fri, 2006-07-21 at 17:51 +0200, Thorsten Leemhuis wrote: > >> BTW, when we initially discussed the kmod standard there was also (IIRC) >> a strong resistance from multiple important and well known people at >> redhat against overloading %{NAME} with the output of "uname -r". I >> doubt that option changed. Spot? Jeremy? f13? > > Yep. I'm still very strongly against overloading %{NAME}. We don't > permit any other package to do this for any reason, and I don't want to > start now. Name is not for versioning. The name is used for versioning in several other packages for similar reasons (to *sanely* allow more than one version of the package simultaneously installed and updated), for example: [pmatilai at cs181077098 ~]$ repoquery 'openssl*' openssl-perl-0:0.9.8a-5.2.i386 openssl097a-0:0.9.7a-4.2.1.i386 openssl-0:0.9.8a-5.2.i686 openssl-devel-0:0.9.8a-5.2.i386 openssl-0:0.9.8a-5.2.i386 [pmatilai at cs181077098 ~]$ repoquery 'libpng*' libpng-devel-2:1.2.8-2.2.1.i386 libpng10-0:1.0.18-3.2.1.i386 libpng-2:1.2.8-2.2.1.i386 libpng10-devel-0:1.0.18-3.2.1.i386 - Panu - From tcallawa at redhat.com Sun Jul 23 13:42:52 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 23 Jul 2006 08:42:52 -0500 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: References: <1153206620.2605.2.camel@bureau.maison> <1153172566.3515.3.camel@bureau.maison> <20060718012432.GA466@neu.nirvana> <1153191448.5648.161.camel@canyon.wittsend.com> <20060718084104.GA2997@neu.nirvana> <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> Message-ID: <1153662172.30446.37.camel@localhost.localdomain> On Sat, 2006-07-22 at 23:39 -0700, Panu Matilainen wrote: > The name is used for versioning in several other packages for similar > reasons (to *sanely* allow more than one version of the package > simultaneously installed and updated), for example: > > [pmatilai at cs181077098 ~]$ repoquery 'openssl*' > openssl-perl-0:0.9.8a-5.2.i386 > openssl097a-0:0.9.7a-4.2.1.i386 > openssl-0:0.9.8a-5.2.i686 > openssl-devel-0:0.9.8a-5.2.i386 > openssl-0:0.9.8a-5.2.i386 > [pmatilai at cs181077098 ~]$ repoquery 'libpng*' > libpng-devel-2:1.2.8-2.2.1.i386 > libpng10-0:1.0.18-3.2.1.i386 > libpng-2:1.2.8-2.2.1.i386 > libpng10-devel-0:1.0.18-3.2.1.i386 And I personally think those are abuses of %{NAME}. I'd much rather see the compat-* ideology used there instead of overloading Name. Let me put it this way: Unless someone can show me a solid write-up that shows that there is _NO_ way to handle kernel modules without overloading Name, I'm going to oppose it on principle. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From Axel.Thimm at ATrpms.net Sun Jul 23 15:45:17 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 17:45:17 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153662172.30446.37.camel@localhost.localdomain> References: <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> Message-ID: <20060723154517.GI17325@neu.nirvana> On Sun, Jul 23, 2006 at 08:42:52AM -0500, Tom 'spot' Callaway wrote: > On Sat, 2006-07-22 at 23:39 -0700, Panu Matilainen wrote: > > > The name is used for versioning in several other packages for similar > > reasons (to *sanely* allow more than one version of the package > > simultaneously installed and updated), for example: > > > > [pmatilai at cs181077098 ~]$ repoquery 'openssl*' > > openssl-perl-0:0.9.8a-5.2.i386 > > openssl097a-0:0.9.7a-4.2.1.i386 > > openssl-0:0.9.8a-5.2.i686 > > openssl-devel-0:0.9.8a-5.2.i386 > > openssl-0:0.9.8a-5.2.i386 > > [pmatilai at cs181077098 ~]$ repoquery 'libpng*' > > libpng-devel-2:1.2.8-2.2.1.i386 > > libpng10-0:1.0.18-3.2.1.i386 > > libpng-2:1.2.8-2.2.1.i386 > > libpng10-devel-0:1.0.18-3.2.1.i386 > > And I personally think those are abuses of %{NAME}. I'd much rather see > the compat-* ideology used there instead of overloading Name. compat-* is overloading the name just the same. There are dozens of further examples, gcc, autoconf, automake, gtk2 (or let's say g*2), libstdc++so, mysqlclient and so on. A quick check on current rawhide shows that at least 5% of the src.rpms are overloading the name. I really had to fight with myself long before I accepted that there is no other way that uname-r-in-the-name. It hurts my eyes just as it does anyone's else, but it proves to be a neccessity. > Let me put it this way: > > Unless someone can show me a solid write-up that shows that there is > _NO_ way to handle kernel modules without overloading Name, I'm > going to oppose it on principle. It's in the posts by Thorsten and myself including an example even, the summary is that There is no way to handle kernel modules for several kernels w/o using a uname-r disambiguation in the name on rpm level. That's a fact. You either get to a) ban usage of rpm CLI and patch all depsolvers to follow non-rpm ordering b) stop supporting more than the very latest published kernel (e.g. allowing the current kernel to nuke/overwrite its own kernel modules while upgrading/installing a new kernel) c) accept uname -r in the name There is disagreement about how bad a) is. I consider it a blocker, Thorsten can live with it. So currently we are effectively living in a), only that noone knows that rpm CLI usage is disallowed with kernel module packages. c) is the only technical sensible solution bringing us at 90% of the target with only one drawback: Ugly names. So what, technical aesthetics superseed what meets the eye. :) -- 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 Sun Jul 23 15:57:02 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 17:57:02 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <200607220945.51929.jkeating@redhat.com> References: <20060718084104.GA2997@neu.nirvana> <20060721175746.GA16006@neu.nirvana> <20060721183553.GC16006@neu.nirvana> <200607220945.51929.jkeating@redhat.com> Message-ID: <20060723155702.GJ17325@neu.nirvana> On Sat, Jul 22, 2006 at 09:45:51AM -0400, Jesse Keating wrote: > On Friday 21 July 2006 14:35, Axel Thimm wrote: > > I really thing there is a flaw and the uname-r-in-name is the only way > > out, and I'd try to persuade people about that. Maybe they could be > > poited to this mail thread as well, as everything is in principle layed > > out here. > > With the kabi stuff coming along, there is no longer a need to lock a given > module to a given kernel version, just an ABI version. The kernel could > easily be bumped a version but the ABI that a particular module needs would > remain unchanged, and thus the module will continue to work. Locking to a > uname will be pointless at this point. > > Jon Masters is giving (gave?) a talk about this at OLS and was discussing > these things at the kernel summit I do believe. I strongly feel we wait for > him to return from OLS so that we can include him in the discussion > surrounding packaging of external kernel modules. > > As it stands, the development kernel does automatically provide an ABI > checksum for each module subdirectory, and rpm knows about it. Requires on > an ABI supposedly works today. kABI will not really help, as it only measures what has changed in the ABI from on kernel release to the next, checking to see whether an old kernel module can be safely recycled. It will not magically force kernel developers to introduce a stable ABI, function signatures and other symbols will change just as frequent. And the areas where kABI would help is where the kernel has reached some level of maturity where indeed the ABI has become stable. But these are not the typical subsystems external kernel modules are built for. Currenlty the most frequent cases of kernel modules are such usually requiring v4l2, ieee82011 or vm subsystems. And these are currently guaranteed to change from kernel release to kernel release. And once these stabilize and other areas of the kernel become interesting you'll have the same situation there. Currently (the last 1-2 years) every kernel release breaks 70-80% of external kernel modules at build level already, and kABI would only confirm this. So what is really needed is a kernel developers' committment to stabilize the kernel ABI, and we are really far away from such a point in time. And even if that were tomorrow, we need to consider legacy support for a couple of FC releases and also RHEL for a couple of years more. But kABI is definitely the way towards a stable kernel ABI, just not within the timeframe we are interested in, e.g. <= 2 years. So for the current discussion this won't help us further. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jul 23 16:12:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Jul 2006 12:12:58 -0400 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060723155702.GJ17325@neu.nirvana> References: <20060718084104.GA2997@neu.nirvana> <200607220945.51929.jkeating@redhat.com> <20060723155702.GJ17325@neu.nirvana> Message-ID: <200607231212.58893.jkeating@redhat.com> On Sunday 23 July 2006 11:57, Axel Thimm wrote: > kABI will not really help, as it only measures what has changed in the > ABI from on kernel release to the next, checking to see whether an old > kernel module can be safely recycled. It will not magically force > kernel developers to introduce a stable ABI, function signatures and > other symbols will change just as frequent. > > And the areas where kABI would help is where the kernel has reached > some level of maturity where indeed the ABI has become stable. But > these are not the typical subsystems external kernel modules are built > for. > > Currenlty the most frequent cases of kernel modules are such usually > requiring v4l2, ieee82011 or vm subsystems. And these are currently > guaranteed to change from kernel release to kernel release. And once > these stabilize and other areas of the kernel become interesting > you'll have the same situation there. Currently (the last 1-2 years) > every kernel release breaks 70-80% of external kernel modules at build > level already, and kABI would only confirm this. There are kernel updates for new rebase, there are kernel updates for security, there are kernel updates for specific bug fixes. There are a lot of cases where the ABI would not change for particular drivers. SCSI, Video, yes even wireless. Any naming scheme that will be discussed should take the KABI system into account and use that. Even if the ABI changes just as frequently as kernel version we should still use the ABI so that the same naming and packaging scheme will work across Fedora Core current releases, maint releases (Legacy), and RHEL (and rebuilds) releases. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Sun Jul 23 16:54:17 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 23 Jul 2006 11:54:17 -0500 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060723154517.GI17325@neu.nirvana> References: <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> Message-ID: <1153673657.22693.11.camel@localhost.localdomain> On Sun, 2006-07-23 at 17:45 +0200, Axel Thimm wrote: > c) is the only technical sensible solution bringing us at 90% of the > target with only one drawback: Ugly names. So what, technical > aesthetics superseed what meets the eye. :) It breaks bugzilla for starters. We deal with this for things like openssl and gcc because they're minimal. Maybe one or two other than the primary. With kmod, we'd be looking at a LOT more than one or two. No other package puts the version for something it depends on in its Name. So, what it boils down to is: rpm is not well built to handle the kernel module packaging case. Can we fix rpm? I doubt it. Everytime I point out a weakness in rpm, I get told that its not going to be fixed. Since upstream is actively hostile towards us, we certainly can't expect them to help. With all of that said: I'll defer to Thorsten and Axel on this one, since they've been knee deep in this. If BOTH of you agree that the _ONLY_ way to have sane kernel module packages (without making rpm changes) is to overload Name, then I'll withdraw my objection to it. (I know Axel feels that way, do you Thorsten?) ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From fedora at leemhuis.info Sun Jul 23 17:31:46 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 23 Jul 2006 19:31:46 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153673657.22693.11.camel@localhost.localdomain> References: <1153223974.2594.3.camel@bureau.maison> <20060718165353.GB5874@neu.nirvana> <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> Message-ID: <44C3B282.2090903@leemhuis.info> Tom 'spot' Callaway schrieb: > [...] > I'll defer to Thorsten and Axel on this one, since they've been knee > deep in this. scop should be asked, too. He's probably knee deep (or even deeper) into this, too. > If BOTH of you agree that the _ONLY_ way to have sane > kernel module packages (without making rpm changes) is to overload Name, > then I'll withdraw my objection to it. (I know Axel feels that way, do > you Thorsten?) Well, I stick to my opinion that "uname -r" in Name creates some problems on its own and not worth the trouble. CU thl From Axel.Thimm at ATrpms.net Sun Jul 23 17:51:31 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 19:51:31 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153673657.22693.11.camel@localhost.localdomain> References: <44BE6E96.8070904@leemhuis.info> <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> Message-ID: <20060723175131.GA32495@neu.nirvana> On Sun, Jul 23, 2006 at 11:54:17AM -0500, Tom 'spot' Callaway wrote: > On Sun, 2006-07-23 at 17:45 +0200, Axel Thimm wrote: > > > c) is the only technical sensible solution bringing us at 90% of the > > target with only one drawback: Ugly names. So what, technical > > aesthetics superseed what meets the eye. :) > > It breaks bugzilla for starters. Kernel modules for foo should only have one bugzilla entry, namely "foo", e.g. the src.rpm's name. Just like there is no bugzilla netry for "foo-devel" and other subpackaging - you can safely consider kmdl subpackages of the same package. > No other package puts the version for something it depends on in its > Name. Well, we already gave some examples and there were gstreamer07 (or 08) plugins as well. When you have a very tight integration of core package and it's plugins (which is what the kernel and the kernel module packages are) *AND* you have the requirement that the core package can have multiple consurrent installs, then the plugins' association to the core packages need to be marked in the name. Specifically for kernel modules this means uname-r-in-the-name. > So, what it boils down to is: rpm is not well built to handle the kernel > module packaging case. > > Can we fix rpm? I doubt it. Everytime I point out a weakness in rpm, I > get told that its not going to be fixed. Since upstream is actively > hostile towards us, we certainly can't expect them to help. No, we can't fix rpm. If there is ever an rpm-ng project revising package management in general we could address this on the blueprint stage, but as it stands neither rpm, nor deb can be patched up to overcome some deficiencies (and this is not the only one). -- 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 Sun Jul 23 18:01:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 20:01:53 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <44C3B282.2090903@leemhuis.info> References: <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> Message-ID: <20060723180153.GB32495@neu.nirvana> On Sun, Jul 23, 2006 at 07:31:46PM +0200, Thorsten Leemhuis wrote: > Tom 'spot' Callaway schrieb: > > [...] > > I'll defer to Thorsten and Axel on this one, since they've been knee > > deep in this. > > scop should be asked, too. He's probably knee deep (or even deeper) into > this, too. > > > If BOTH of you agree that the _ONLY_ way to have sane kernel > > module packages (without making rpm changes) is to overload Name, > > then I'll withdraw my objection to it. (I know Axel feels that > > way, do you Thorsten?) > > Well, I stick to my opinion that "uname -r" in Name creates some > problems on its own and not worth the trouble. But please be as fair as to admit that w/o uname-r in name the problems are several magnitudes worse. rpm -U/-i will nuke or overwrite kernel modules of the running kernel in a uname-r-less scheme. uname-r-in-name and the kmdl scheme isn't going to bring peace on earth, but it is already very close to the requirements on kernel module packages which no merging-versions-scheme can be. -- 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 Sun Jul 23 18:12:48 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 20:12:48 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <200607231212.58893.jkeating@redhat.com> References: <20060718084104.GA2997@neu.nirvana> <200607220945.51929.jkeating@redhat.com> <20060723155702.GJ17325@neu.nirvana> <200607231212.58893.jkeating@redhat.com> Message-ID: <20060723181248.GC32495@neu.nirvana> On Sun, Jul 23, 2006 at 12:12:58PM -0400, Jesse Keating wrote: > On Sunday 23 July 2006 11:57, Axel Thimm wrote: > > kABI will not really help, as it only measures what has changed in the > > ABI from on kernel release to the next, checking to see whether an old > > kernel module can be safely recycled. It will not magically force > > kernel developers to introduce a stable ABI, function signatures and > > other symbols will change just as frequent. > > > > And the areas where kABI would help is where the kernel has reached > > some level of maturity where indeed the ABI has become stable. But > > these are not the typical subsystems external kernel modules are built > > for. > > > > Currenlty the most frequent cases of kernel modules are such usually > > requiring v4l2, ieee82011 or vm subsystems. And these are currently > > guaranteed to change from kernel release to kernel release. And once > > these stabilize and other areas of the kernel become interesting > > you'll have the same situation there. Currently (the last 1-2 years) > > every kernel release breaks 70-80% of external kernel modules at build > > level already, and kABI would only confirm this. > > There are kernel updates for new rebase, there are kernel updates for > security, there are kernel updates for specific bug fixes. There are a lot > of cases where the ABI would not change for particular drivers. SCSI, Video, > yes even wireless. Any naming scheme that will be discussed should take the > KABI system into account and use that. Even if the ABI changes just as > frequently as kernel version we should still use the ABI so that the same > naming and packaging scheme will work across Fedora Core current releases, > maint releases (Legacy), and RHEL (and rebuilds) releases. Well, add to the above that the kABI isn't going to give you an orderable single entry like uname-r does (but maybe noone cares, the kernel module packaging at least wouldn't), and that no user will understand the mapping between his kernel, whose uname -r he knows, and a kABI checksum. But in principle if one day kABI checksums gain a popularity/visibilty like uname-r has today on the user's side, then I agree, that uname-r in the name could be replaced with a kABI checksum. In the kmdl scheme this would be a rather trivial change. But you're not going to make friends with people already losing lunch on embedding uname-r in the name. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jul 23 18:20:13 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Jul 2006 14:20:13 -0400 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060723181248.GC32495@neu.nirvana> References: <20060718084104.GA2997@neu.nirvana> <200607231212.58893.jkeating@redhat.com> <20060723181248.GC32495@neu.nirvana> Message-ID: <200607231420.16285.jkeating@redhat.com> On Sunday 23 July 2006 14:12, Axel Thimm wrote: > Well, add to the above that the kABI isn't going to give you an > orderable single entry like uname-r does (but maybe noone cares, the > kernel module packaging at least wouldn't), and that no user will > understand the mapping between his kernel, whose uname -r he knows, > and a kABI checksum. > > But in principle if one day kABI checksums gain a popularity/visibilty > like uname-r has today on the user's side, then I agree, that uname-r > in the name could be replaced with a kABI checksum. In the kmdl scheme > this would be a rather trivial change. Perhaps I fail to see the problem. Once you have an ABI to use for requires and such, can't you use someting more simple in the version or release rather than a uname-r in the name? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Jul 23 18:24:34 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 20:24:34 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <200607231420.16285.jkeating@redhat.com> References: <20060718084104.GA2997@neu.nirvana> <200607231212.58893.jkeating@redhat.com> <20060723181248.GC32495@neu.nirvana> <200607231420.16285.jkeating@redhat.com> Message-ID: <20060723182434.GD32495@neu.nirvana> On Sun, Jul 23, 2006 at 02:20:13PM -0400, Jesse Keating wrote: > On Sunday 23 July 2006 14:12, Axel Thimm wrote: > > Well, add to the above that the kABI isn't going to give you an > > orderable single entry like uname-r does (but maybe noone cares, the > > kernel module packaging at least wouldn't), and that no user will > > understand the mapping between his kernel, whose uname -r he knows, > > and a kABI checksum. > > > > But in principle if one day kABI checksums gain a popularity/visibilty > > like uname-r has today on the user's side, then I agree, that uname-r > > in the name could be replaced with a kABI checksum. In the kmdl scheme > > this would be a rather trivial change. > > Perhaps I fail to see the problem. Once you have an ABI to use for requires > and such, can't you use someting more simple in the version or release rather > than a uname-r in the name? The kABI is a set of headers out of which you can generate a checksum. The checksum will by definition not be orderable, and also not memorizable. Similar to mercurial changeset ids. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jul 23 18:30:49 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Jul 2006 14:30:49 -0400 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060723182434.GD32495@neu.nirvana> References: <20060718084104.GA2997@neu.nirvana> <200607231420.16285.jkeating@redhat.com> <20060723182434.GD32495@neu.nirvana> Message-ID: <200607231430.50031.jkeating@redhat.com> On Sunday 23 July 2006 14:24, Axel Thimm wrote: > The kABI is a set of headers out of which you can generate a > checksum. The checksum will by definition not be orderable, and also > not memorizable. Similar to mercurial changeset ids. Right, I understand that. I'm far too late into the conversation I think. I'll wait for a complete proposal to come through. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sun Jul 23 19:32:06 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 23 Jul 2006 22:32:06 +0300 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060723180153.GB32495@neu.nirvana> References: <20060719223717.GE4405@neu.nirvana> <44BFA80A.6040709@leemhuis.info> <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> Message-ID: <1153683126.2769.103.camel@localhost.localdomain> On Sun, 2006-07-23 at 20:01 +0200, Axel Thimm wrote: > On Sun, Jul 23, 2006 at 07:31:46PM +0200, Thorsten Leemhuis wrote: > > > > Well, I stick to my opinion that "uname -r" in Name creates some > > problems on its own and not worth the trouble. > > But please be as fair as to admit that w/o uname-r in name the > problems are several magnitudes worse. Having been involved in designing, using, and maintaining schemes and packages both with and without uname-in-name for years and discussing the pros and cons to death several times, my opinion is that the problems created by both are roughly equal, and certainly not different by order of magnitude. The result of the last discussion round and yet another redesign of the kmod guidelines from scratch [0] has been accepted by a quite a few interested parties, reaching apparent critical mass so that it's actually possible to ship additional kernel modules in *some* usable and maintainable form in FE. I don't personally agree with every bit in the current design, but I see nothing critically wrong with it either. In particular, I see no need to challenge the achieved consensus with the controversial scheme change discussed in this thread, so -1. > rpm -U/-i will nuke or > overwrite kernel modules of the running kernel in a uname-r-less > scheme. rpm -U behaves just as documented and just like with all other packages, including the kernels, ie. upgrades them. Yes, I'm aware of the nuances that might make some say it's not the same. Whatever, if you don't want that behaviour, don't use -U. kernel packages don't have uname-r-in-name either, and people are perfectly capable of upgrading their kernels with the rpm CLI. Ditto, rpm -i behaves like for all other packages, it doesn't nuke or overwrite anything. Use --oldpackage in addition if you wish to deal with modules for old kernels. Sure, it's a bit difficult but not impossible, just use -e and -i, to "safely" upgrade a kmod package for an old installed kernel. But I think shipping updated modules for old kernels is just not going to (and one could argue should not) happen in FC/FE anyway. Either way, I'm certainly not losing any sleep over that. [0] Like I've said before, I'm not going to participate in more discussions about this unless specifically asked. I think I was asked in this thread, so here goes, but don't expect further replies. From Axel.Thimm at ATrpms.net Sun Jul 23 20:19:57 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 22:19:57 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153683126.2769.103.camel@localhost.localdomain> References: <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> Message-ID: <20060723201957.GE32495@neu.nirvana> On Sun, Jul 23, 2006 at 10:32:06PM +0300, Ville Skytt? wrote: > > rpm -U/-i will nuke or overwrite kernel modules of the running > > kernel in a uname-r-less scheme. > > rpm -U behaves just as documented and just like with all other packages, > including the kernels, ie. upgrades them. Yes, I'm aware of the nuances > that might make some say it's not the same. Whatever, if you don't want > that behaviour, don't use -U. kernel packages don't have > uname-r-in-name either, and people are perfectly capable of upgrading > their kernels with the rpm CLI. > > Ditto, rpm -i behaves like for all other packages, it doesn't nuke or > overwrite anything. Use --oldpackage in addition if you wish to deal > with modules for old kernels. Just pick Thorsten's example where rpm -U will nuke the kernel module from another unrelated kernel and rpm -i will overwrite (coinstall over) the kernel module of the latest kernel. To give the example again (for simplicity EVR is a single integer): kernel-a with module foo-1 has kmod-foo-1-a kernel-b with module foo-1 has kmod-foo-1-b (BTW this by itself already needs special support in all depsolvers to allow for multiple installs. smart for one cannot glob this, so you need to mention each kernel module in its config.) Now an update module foo-2 brings in kmod-foo-2-b in the repo. This *should* replace kmod-foo-1-b, but leave kmod-foo-1-a alone. o rpm -i fails as it simply (partly) *overwrites* kmod-foo-1-b o rpm -U faile as it *nukes* kmod-foo-1-a This will be the typical situation upon each kernel module upgrade. And w/o special handling in *each* depsolver depsolvers will automagically fail defaulting to nuking. So, the fact remains: W/o uname-r-in-name you generate a very messy situation with compilcated special handling to avoid breakage and you cannot avoid breakage on rpm CLI level. In contrast the kmdl scheme guarantees that old kernel modules will not be nuked and neither will anything be overwritten - in fact on rpm CLI level kmdls behave as a normal package - always use rpm -U. The only drawback of kmdl is that depsolvers don't coinstall for newly installed kernels. But this depsolver support is far more uncritical if missing and also easier to implement (like a 9-liner in bash). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Sun Jul 23 20:38:59 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Jul 2006 16:38:59 -0400 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060723201957.GE32495@neu.nirvana> References: <20060721052211.GD14267@neu.nirvana> <44C0F7EE.6010702@leemhuis.info> <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> Message-ID: <1153687139.13330.48.camel@cutter> On Sun, 2006-07-23 at 22:19 +0200, Axel Thimm wrote: > On Sun, Jul 23, 2006 at 10:32:06PM +0300, Ville Skytt? wrote: > > > > rpm -U/-i will nuke or overwrite kernel modules of the running > > > kernel in a uname-r-less scheme. > > > > rpm -U behaves just as documented and just like with all other packages, > > including the kernels, ie. upgrades them. Yes, I'm aware of the nuances > > that might make some say it's not the same. Whatever, if you don't want > > that behaviour, don't use -U. kernel packages don't have > > uname-r-in-name either, and people are perfectly capable of upgrading > > their kernels with the rpm CLI. > > > > Ditto, rpm -i behaves like for all other packages, it doesn't nuke or > > overwrite anything. Use --oldpackage in addition if you wish to deal > > with modules for old kernels. > > Just pick Thorsten's example where rpm -U will nuke the kernel module > from another unrelated kernel and rpm -i will overwrite (coinstall > over) the kernel module of the latest kernel. But I thought it was already stated that we don't care about rpm used on the cli to handle these sorts of things. That we've assumed we're operating at a level above rpm for constructing the transaction set. So if you think of rpm's direct use as not a concern what are the other issues with the current scheme? -sv From Axel.Thimm at ATrpms.net Sun Jul 23 21:03:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 23:03:43 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153687139.13330.48.camel@cutter> References: <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> Message-ID: <20060723210343.GF32495@neu.nirvana> On Sun, Jul 23, 2006 at 04:38:59PM -0400, seth vidal wrote: > On Sun, 2006-07-23 at 22:19 +0200, Axel Thimm wrote: > > On Sun, Jul 23, 2006 at 10:32:06PM +0300, Ville Skytt? wrote: > > > > rpm -U/-i will nuke or overwrite kernel modules of the running > > > > kernel in a uname-r-less scheme. > But I thought it was already stated that we don't care about rpm used on > the cli to handle these sorts of things. That we've assumed we're > operating at a level above rpm for constructing the transaction set. A scheme were two independent EVRs are merged together into one is broken and banning the tool that exhibits it and pasting it away from others isn't the solution. kmod-foo-1-a just has nothing to do with kmod-foo--b (in the simplified notation). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Sun Jul 23 21:13:40 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Jul 2006 17:13:40 -0400 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060723210343.GF32495@neu.nirvana> References: <1153501599.26196.10.camel@localhost.localdomain> <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> Message-ID: <1153689220.13330.51.camel@cutter> On Sun, 2006-07-23 at 23:03 +0200, Axel Thimm wrote: > On Sun, Jul 23, 2006 at 04:38:59PM -0400, seth vidal wrote: > > On Sun, 2006-07-23 at 22:19 +0200, Axel Thimm wrote: > > > On Sun, Jul 23, 2006 at 10:32:06PM +0300, Ville Skytt? wrote: > > > > > rpm -U/-i will nuke or overwrite kernel modules of the running > > > > > kernel in a uname-r-less scheme. > > > But I thought it was already stated that we don't care about rpm used on > > the cli to handle these sorts of things. That we've assumed we're > > operating at a level above rpm for constructing the transaction set. > > A scheme were two independent EVRs are merged together into one is > broken and banning the tool that exhibits it and pasting it away from > others isn't the solution. kmod-foo-1-a just has nothing to do with > kmod-foo--b (in the simplified notation). okay. I can take that. Here's my only complaint and it is a complaint for all sides equally: I would like one and final standard decided on BEFORE FC6 is released. We need to get the code for yum complete so we can stop messing around with this stuff. At this point I'm in favor of whatever gets it done. -sv From Axel.Thimm at ATrpms.net Sun Jul 23 21:17:39 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 23:17:39 +0200 Subject: [Fedora-packaging] COPYING (license) not under docdir Message-ID: <20060723211739.GA6491@neu.nirvana> Hi, I'm reviewing a package where the license file is under %{_datadir} beacuse the gtk GUI needs to display it. Moving it to %doc is bad as the application would be dependent on %doc content. But not having it in %doc is bad, too, as this is the canonical place someone will query the license text. IMHO in this case it should be doubled. Do you agree? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Sun Jul 23 21:25:30 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Jul 2006 17:25:30 -0400 Subject: [Fedora-packaging] COPYING (license) not under docdir In-Reply-To: <20060723211739.GA6491@neu.nirvana> References: <20060723211739.GA6491@neu.nirvana> Message-ID: <1153689930.13330.54.camel@cutter> On Sun, 2006-07-23 at 23:17 +0200, Axel Thimm wrote: > Hi, > > I'm reviewing a package where the license file is under %{_datadir} > beacuse the gtk GUI needs to display it. Moving it to %doc is bad as > the application would be dependent on %doc content. But not having it > in %doc is bad, too, as this is the canonical place someone will query > the license text. > > IMHO in this case it should be doubled. Do you agree? I don't see a problem with duplicating it but is there any problem with a symlink from %_datadir to the docdir? -sv From rc040203 at freenet.de Mon Jul 24 05:17:14 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 24 Jul 2006 07:17:14 +0200 Subject: [Fedora-packaging] COPYING (license) not under docdir In-Reply-To: <1153689930.13330.54.camel@cutter> References: <20060723211739.GA6491@neu.nirvana> <1153689930.13330.54.camel@cutter> Message-ID: <1153718235.22104.53.camel@mccallum.corsepiu.local> On Sun, 2006-07-23 at 17:25 -0400, seth vidal wrote: > On Sun, 2006-07-23 at 23:17 +0200, Axel Thimm wrote: > > Hi, > > > > I'm reviewing a package where the license file is under %{_datadir} > > beacuse the gtk GUI needs to display it. Moving it to %doc is bad as > > the application would be dependent on %doc content. But not having it > > in %doc is bad, too, as this is the canonical place someone will query > > the license text. > > > > IMHO in this case it should be doubled. Do you agree? > > I don't see a problem with duplicating it but is there any problem with > a symlink from %_datadir to the docdir? Yes, - they could be on different partitions, so symlinks might not be available. - A file under %{_datadir]/ is application data, not rpm %doc'umentation. Though the files might be identical, they are completely different beasts. - rpm --excludedocs (i.e. if symlinking, then the physical copy must be in %{_datadir} and the symlink in %docdir. Frankly speaking, I'd not waste any time on symlinking, but duplicate the files, instead. Ralf From rdieter at math.unl.edu Mon Jul 24 11:32:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 24 Jul 2006 06:32:47 -0500 Subject: [Fedora-packaging] COPYING (license) not under docdir In-Reply-To: <1153718235.22104.53.camel@mccallum.corsepiu.local> References: <20060723211739.GA6491@neu.nirvana> <1153689930.13330.54.camel@cutter> <1153718235.22104.53.camel@mccallum.corsepiu.local> Message-ID: <44C4AFDF.6080602@math.unl.edu> Ralf Corsepius wrote: > On Sun, 2006-07-23 at 17:25 -0400, seth vidal wrote: >> On Sun, 2006-07-23 at 23:17 +0200, Axel Thimm wrote: >>> Hi, >>> >>> I'm reviewing a package where the license file is under %{_datadir} >>> beacuse the gtk GUI needs to display it. Moving it to %doc is bad as >>> the application would be dependent on %doc content. But not having it >>> in %doc is bad, too, as this is the canonical place someone will query >>> the license text. >>> >>> IMHO in this case it should be doubled. Do you agree? >> I don't see a problem with duplicating it but is there any problem with >> a symlink from %_datadir to the docdir? > Yes, > > - they could be on different partitions, so symlinks might not be > available. Why not? > - A file under %{_datadir]/ is application data, not rpm > %doc'umentation. Though the files might be identical, they are > completely different beasts. So? > - rpm --excludedocs (i.e. if symlinking, then the physical copy must be > in %{_datadir} and the symlink in %docdir. As long as both are marked %doc, there shouldn't be a problem. > Frankly speaking, I'd not waste any time on symlinking, but duplicate > the files, instead. Agreed. While we're on the subject, what's the importance that the license file under %_docdir anyway? As far as I'm concerned, as long as the license is in the package somewhere, that's should be sufficient. -- Rex From Axel.Thimm at ATrpms.net Mon Jul 24 11:37:34 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 24 Jul 2006 13:37:34 +0200 Subject: [Fedora-packaging] Re: COPYING (license) not under docdir In-Reply-To: <44C4AFDF.6080602@math.unl.edu> References: <20060723211739.GA6491@neu.nirvana> <1153689930.13330.54.camel@cutter> <1153718235.22104.53.camel@mccallum.corsepiu.local> <44C4AFDF.6080602@math.unl.edu> Message-ID: <20060724113734.GE17281@neu.nirvana> On Mon, Jul 24, 2006 at 06:32:47AM -0500, Rex Dieter wrote: > While we're on the subject, what's the importance that the license file > under %_docdir anyway? As far as I'm concerned, as long as the license > is in the package somewhere, that's should be sufficient. Easier mass-review by legal? It's easier to check there than rpm -ql'ing the package and browsing though all file lists. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Mon Jul 24 11:42:56 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 24 Jul 2006 13:42:56 +0200 Subject: [Fedora-packaging] COPYING (license) not under docdir In-Reply-To: <44C4AFDF.6080602@math.unl.edu> References: <20060723211739.GA6491@neu.nirvana> <1153689930.13330.54.camel@cutter> <1153718235.22104.53.camel@mccallum.corsepiu.local> <44C4AFDF.6080602@math.unl.edu> Message-ID: <1153741377.22104.65.camel@mccallum.corsepiu.local> On Mon, 2006-07-24 at 06:32 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Sun, 2006-07-23 at 17:25 -0400, seth vidal wrote: > >> On Sun, 2006-07-23 at 23:17 +0200, Axel Thimm wrote: > >>> Hi, > >>> > >>> I'm reviewing a package where the license file is under %{_datadir} > >>> beacuse the gtk GUI needs to display it. Moving it to %doc is bad as > >>> the application would be dependent on %doc content. But not having it > >>> in %doc is bad, too, as this is the canonical place someone will query > >>> the license text. > >>> > >>> IMHO in this case it should be doubled. Do you agree? > >> I don't see a problem with duplicating it but is there any problem with > >> a symlink from %_datadir to the docdir? > > Yes, > > > > - they could be on different partitions, so symlinks might not be > > available. > > Why not? Because I mixed up hard and soft links ;) Sorry. > > - A file under %{_datadir]/ is application data, not rpm > > %doc'umentation. Though the files might be identical, they are > > completely different beasts. > > So? Data is "used by" relation. Documentation is a "has a" relation. > > - rpm --excludedocs (i.e. if symlinking, then the physical copy must be > > in %{_datadir} and the symlink in %docdir. > > As long as both are marked %doc, there shouldn't be a problem. If %{_datadir}//COPYING is used by a package, it's data, not documentation. %doc'ing it would be a fault. Ralf From rc040203 at freenet.de Mon Jul 24 11:51:35 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 24 Jul 2006 13:51:35 +0200 Subject: [Fedora-packaging] Re: COPYING (license) not under docdir In-Reply-To: <20060724113734.GE17281@neu.nirvana> References: <20060723211739.GA6491@neu.nirvana> <1153689930.13330.54.camel@cutter> <1153718235.22104.53.camel@mccallum.corsepiu.local> <44C4AFDF.6080602@math.unl.edu> <20060724113734.GE17281@neu.nirvana> Message-ID: <1153741895.22104.71.camel@mccallum.corsepiu.local> On Mon, 2006-07-24 at 13:37 +0200, Axel Thimm wrote: > On Mon, Jul 24, 2006 at 06:32:47AM -0500, Rex Dieter wrote: > > While we're on the subject, what's the importance that the license file > > under %_docdir anyway? As far as I'm concerned, as long as the license > > is in the package somewhere, that's should be sufficient. > > Easier mass-review by legal? It's easier to check there than rpm > -ql'ing the package and browsing though all file lists. A real legal review would have to look into each and every file in any case. No matter which kind of "detached license files" a package's tarball is accompanied by, or an FE rpm-packager might have added. Ralf From tibbs at math.uh.edu Mon Jul 24 17:19:24 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 24 Jul 2006 12:19:24 -0500 Subject: [Fedora-packaging] PHP guidelines Message-ID: So, is there still any interest in PHP guidelines at all? I worked up http://fedoraproject.org/wiki/PackagingDrafts/PHP but then Ville had an idea for a template that doesn't need any special macro definitions to be provided by the php-pear package. I don't know what the current state of things is. Is there any chance of making any forward movement soon? We're going to start losing packagers if we can't get some reviews done soon. Regarding PECL modules, I looked over the php-pecl-xdebug package which is the only PECL module under review currently. The spec is clean and requires two macros which I have in the above draft, although the means for determining the API version is completely different. Could someone comment on the differences and relative strengths of: %define php_apiver %((phpize --version 2>/dev/null || echo 'PHP Api Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*: *//p') and %define php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) besides the obvious additional complexity of the former (and the hilarity of having to do such gymnastics in the first place)? - J< From chris.stone at gmail.com Tue Jul 25 01:26:26 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 24 Jul 2006 18:26:26 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: References: Message-ID: On 7/24/06, Jason L Tibbitts III wrote: > So, is there still any interest in PHP guidelines at all? > > I worked up http://fedoraproject.org/wiki/PackagingDrafts/PHP but then > Ville had an idea for a template that doesn't need any special macro > definitions to be provided by the php-pear package. I don't know what > the current state of things is. > > Is there any chance of making any forward movement soon? We're going > to start losing packagers if we can't get some reviews done soon. > > Regarding PECL modules, I looked over the php-pecl-xdebug package > which is the only PECL module under review currently. The spec is > clean and requires two macros which I have in the above draft, > although the means for determining the API version is completely > different. Could someone comment on the differences and relative > strengths of: > > %define php_apiver %((phpize --version 2>/dev/null || echo 'PHP Api Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*: *//p') > > and > > %define php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) > > besides the obvious additional complexity of the former (and the > hilarity of having to do such gymnastics in the first place)? Well Ville made a bunch of changes to the spec file template so that it doesn't have to use macros. It essentially complicates the default spec template. The reason for adding all of this additional complexity is to support deprecated distributions. Personally, I don't see the advantage to adding a bunch of extra stuff to the spec files just to support FC4. Also Ville insists on their being a %build section for an unknown reason. He claims people don't know what rpm does and not having a %build will cause mysterious errors, when infact the rpm source code clealy indicates the consequences of not using %build. These consequences to no affect php-pear modules, so I do not understand his reasoning for wanting to add a %build section to the template. The whole thing with the files section looks like a total hack to me and I don't think we should be going through all this trouble just to support FC4 which may not get the new macro definitions. From nicolas.mailhot at laposte.net Tue Jul 25 06:24:00 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 25 Jul 2006 08:24:00 +0200 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: References: Message-ID: <1153808640.20491.10.camel@rousalka.dyndns.org> Le lundi 24 juillet 2006 ? 18:26 -0700, Christopher Stone a ?crit : > Personally, I don't see the advantage to adding a bunch of extra stuff > to the spec files just to support FC4. +1 > Also Ville insists on their being a %build section for an unknown > reason. He claims people don't know what rpm does and not having a > %build will cause mysterious errors, when infact the rpm source code > clealy indicates the consequences of not using %build. These > consequences to no affect php-pear modules, so I do not understand his > reasoning for wanting to add a %build section to the template. Ville is right there is you omit build you'll get many side-effects you didn't bargain for. Also do you never change files with sed before you install them? This belongs in %build, not %setup or %install (the PHP SM spec for example had a very nasty bug at a time because the packager didn't respect this discipline and mixed install and file munging in the last section) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 25 10:07:20 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 25 Jul 2006 12:07:20 +0200 Subject: [Fedora-packaging] BuildRoot Message-ID: <20060725120720.34b753f4@python2> Hi, Two quickies : 1) The current "preferred" BuildRoot which executes "id -u" isn't useful when used with mach or mock. I have nothing against it, I just don't feel the need to use it... as it's "preferred", I should be able to still use any BuildRoot value I want, right? I really simply prefer the same, but without forking a useless "id -u" execution. Yet another discussion about this here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188461 (nearly all my review requests change into debates regarding useless details... I'm surprised that no one has yet criticized the non-aligned header lines I use ;-)) If the "preferred" term is changed to "mandatory" in the guidelines, I will abide, but continue thinking it's plain silly, and this brings us to... 2) Why the heck is there still the need for BuildRoot to be defined in each and every spec file we have!? Could we once and for all push a sane default value into FC6 and start considering removing it once and for all from all spec files by the time we reach FC10 or so? Currently, if BuildRoot isn't defined, then "" is used (thus the system's "/")... years ago this might have made sense for someone, but nowadays I really don't think so. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2431.fc6 Load : 1.14 0.60 0.47 From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 25 10:13:33 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 25 Jul 2006 12:13:33 +0200 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: (Jason L. Tibbitts, III's message of "Mon, 24 Jul 2006 12:19:24 -0500") References: Message-ID: <87ac6ym1pu.fsf@kosh.bigo.ensc.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: > I worked up http://fedoraproject.org/wiki/PackagingDrafts/PHP We came to the agreement that things like | Requires: php >= 4.2 do not make sense. Why is | Requires: php >= current PHP version a MUST item? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rc040203 at freenet.de Tue Jul 25 10:20:40 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 12:20:40 +0200 Subject: [Fedora-packaging] BuildRoot In-Reply-To: <20060725120720.34b753f4@python2> References: <20060725120720.34b753f4@python2> Message-ID: <1153822840.22104.181.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 12:07 +0200, Matthias Saou wrote: > Hi, > > Two quickies : > > 1) The current "preferred" BuildRoot which executes "id -u" isn't > useful when used with mach or mock. I have nothing against it, I just > don't feel the need to use it... as it's "preferred", I should be able > to still use any BuildRoot value I want, right? I really simply prefer > the same, but without forking a useless "id -u" execution. > > Yet another discussion about this here : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188461 > (nearly all my review requests change into debates regarding useless > details... This isn't a useless detail. Your buildroot is plain broken: It is not suitable for multi-user environments: [Citation from a reply to a similar mail from Axel a couple of days ago.] # su -l user1 # rpmbuild -bi vtkdata.spec # exit # su -l user2 # rpmbuild -bb vtkdata.spec ... + rm -rf /var/tmp/vtkdata-5.0.1-4-root rm: cannot remove `/var/tmp/vtkdata-5.0.1-4-root/usr/share/vtkdata-5.0.1/Data/cth.vtr': Permission denied rm: cannot remove `/var/tmp/vtkdata-5.0.1-4-root/usr/share/vtkdata-5.0.1/Data/Particles.raw': Permission denied ... With FE's current buildroot-recommendation this case doesn't happen. To put it differently: Your buildroot regresses in comparison to the recommendation in the guidelines and therefore is harmful to users rebuilding FE packages. > If the "preferred" term is changed to "mandatory" in the guidelines, I > will abide, but continue thinking it's plain silly, and this brings us > to... Things are quite simple: I want "a mandatory BuildRoot" to stop this kind of discussions to stop once and for all times. Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 25 10:38:37 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 25 Jul 2006 12:38:37 +0200 Subject: [Fedora-packaging] BuildRoot In-Reply-To: <1153822840.22104.181.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <1153822840.22104.181.camel@mccallum.corsepiu.local> Message-ID: <20060725123837.594257b9@python2> Ralf Corsepius wrote : > On Tue, 2006-07-25 at 12:07 +0200, Matthias Saou wrote: > > Hi, > > > > Two quickies : > > > > 1) The current "preferred" BuildRoot which executes "id -u" isn't > > useful when used with mach or mock. I have nothing against it, I just > > don't feel the need to use it... as it's "preferred", I should be able > > to still use any BuildRoot value I want, right? I really simply prefer > > the same, but without forking a useless "id -u" execution. > > > > Yet another discussion about this here : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188461 > > (nearly all my review requests change into debates regarding useless > > details... > This isn't a useless detail. Your buildroot is plain broken: > > It is not suitable for multi-user environments: > > [Citation from a reply to a similar mail from Axel a couple of days > ago.] > > # su -l user1 > # rpmbuild -bi vtkdata.spec > # exit > > # su -l user2 > # rpmbuild -bb vtkdata.spec > ... > + rm -rf /var/tmp/vtkdata-5.0.1-4-root > rm: cannot remove > `/var/tmp/vtkdata-5.0.1-4-root/usr/share/vtkdata-5.0.1/Data/cth.vtr': > Permission denied > rm: cannot remove > `/var/tmp/vtkdata-5.0.1-4-root/usr/share/vtkdata-5.0.1/Data/Particles.raw': Permission denied > ... > > With FE's current buildroot-recommendation this case doesn't happen. > > To put it differently: > Your buildroot regresses in comparison to the recommendation in the > guidelines and therefore is harmful to users rebuilding FE packages. > > > If the "preferred" term is changed to "mandatory" in the guidelines, I > > will abide, but continue thinking it's plain silly, and this brings us > > to... > Things are quite simple: I want "a mandatory BuildRoot" to stop this > kind of discussions to stop once and for all times. Your example is bad. On a default installation, you'll hit permission problems in /usr/src/ way before hitting them on /var/tmp... so you need the users to define stuff in their ~/.rpmmacros anyway. Why not just also set %_tmppath there at the same time? Makes your example work fine. FYI, I never used /var/tmp for _tmppath when I used to build on real systems... now with mach and mock, I don't care anymore. I'd really prefer we try to move forward here, i.e. get some comments on my point n?2 about trying to set a sane (non empty like currently) default for BuildRoot, so that we can simply forget about it in a few releases. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2431.fc6 Load : 1.03 0.86 0.69 From Axel.Thimm at ATrpms.net Tue Jul 25 10:42:45 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 12:42:45 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725120720.34b753f4@python2> References: <20060725120720.34b753f4@python2> Message-ID: <20060725104245.GA1164@neu.nirvana> Hi, On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote: > Two quickies : > > 1) The current "preferred" BuildRoot which executes "id -u" isn't > useful when used with mach or mock. I have nothing against it, I just > don't feel the need to use it... as it's "preferred", I should be able > to still use any BuildRoot value I want, right? I really simply prefer > the same, but without forking a useless "id -u" execution. > > Yet another discussion about this here : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188461 > (nearly all my review requests change into debates regarding useless > details... I'm surprised that no one has yet criticized the non-aligned > header lines I use ;-)) > > If the "preferred" term is changed to "mandatory" in the guidelines, I > will abide, but continue thinking it's plain silly, and this brings us > to... This was discussed a couple of days ago here, check the archives. FWIW I agree 110%. Ralf argues that two users on a multiuser system building the same package with the same evr would get hurt (one would look the other's buildroot), which I consider an extreme corner case. Furthermore currently building the same package for two archs (like kernel at i686 and kernel at i586) will hurt even more, which is not a corner case, so if we were to play it mega-safe we would had to add arch/epoch also to it. Better keep it small, simple and functional. Anyway it looked like half the people here considered it an optional requirement (what "preferred" also really implied) and some would like to make it mandatory. > 2) Why the heck is there still the need for BuildRoot to be defined in > each and every spec file we have!? Could we once and for all push a > sane default value into FC6 and start considering removing it once and > for all from all spec files by the time we reach FC10 or so? Yes, that's the time scale, or maybe even FC110 :) > Currently, if BuildRoot isn't defined, then "" is used Not always, if you use %{buildroot} w/o BuildRoot: tag it expands to literally to itself, e.g. "%{buildroot}". At least with FC5's rpm. Maybe previously it was effectively %{nil}. > (thus the system's "/")... years ago this might have made sense for > someone, but nowadays I really don't think so. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jul 25 10:49:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 12:49:53 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725123837.594257b9@python2> References: <20060725120720.34b753f4@python2> <1153822840.22104.181.camel@mccallum.corsepiu.local> <20060725123837.594257b9@python2> Message-ID: <20060725104953.GB1164@neu.nirvana> On Tue, Jul 25, 2006 at 12:38:37PM +0200, Matthias Saou wrote: > I'd really prefer we try to move forward here, i.e. get some comments > on my point n?2 about trying to set a sane (non empty like currently) > default for BuildRoot, so that we can simply forget about it in a few > releases. Ideally the default BuildRoot would be something using mktemp-like methods to acquire an unpredictable tmp folder and would have to be done within rpm of course (by some guidance/template overidden by macros). Within a buildsystem you don't really care as the buildsystem overrides it anyway. So, perhaps it's something for rpm-devel? -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 25 10:52:47 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 25 Jul 2006 12:52:47 +0200 Subject: [Fedora-packaging] Re: Re: Request to drop %(%{__id_u} -n) in preferred buildroot In-Reply-To: <1153321878.7982.154.camel@mccallum.corsepiu.local> References: <20060719122927.GI13785@neu.nirvana> <200607190841.45713.jkeating@redhat.com> <20060719125130.GJ13785@neu.nirvana> <200607190910.16601.jkeating@j2solutions.net> <20060719132406.GK13785@neu.nirvana> <44BE3539.1070107@math.unl.edu> <20060719134704.GL13785@neu.nirvana> <20060719141553.GA2807@neu.nirvana> <1153320416.7982.151.camel@mccallum.corsepiu.local> <1153321878.7982.154.camel@mccallum.corsepiu.local> Message-ID: <20060725125247.67eeb948@python2> Ralf Corsepius wrote : > On Wed, 2006-07-19 at 10:03 -0500, Rex Dieter wrote: > > Ralf Corsepius wrote: > > > > > On Wed, 2006-07-19 at 16:15 +0200, Axel Thimm wrote: > > >> On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote: > > >> > Axel Thimm wrote: > > > > >> > > Two independent reviewer considered this a blocker for a > > >> > > review's acceptance (even though it's marked "preferred"). > > > > >> > The reviewers need to be whacked with a clue-stick. A working > > >> > (non-broken) buildroot is *not* a blocker. > > > > > The point you seem to be missing, your buildroot is broken: > > > buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root > > > > And you missed the point that *in the context of Fedora Extras*, it's not > > broken. > Rebuilding rpms by users is not amongst the Fedora tasks? > FE is living in the ivory towers of mock? > > With all due respect, .... Oops. I missed this thread and started a very similar one, since reviewers are complaining about the same BuildRoot problem in my packages than in Axel's. - I'd like non-broken BuildRoots to be considered OK (this should already be the case with "preferred" in the guidelines), and by non-broken I mean something like "starts with %{_tmppath}/ and contains at least a directory name unique to the package being built". Maybe the guidelines could be updated to include something like that. - I'd like the FUD about appending `id -u` solving the problem for multi-user builds on the same system stop. Ralf, please : Users of a same system will also have conflicts with %_builddir, %_rpmdir and %_srcrpmdir by default and are *REQUIRED* to at least change their %_topdir to get things working. Well, just have them also change their %_tmppath as it can only be a positive thing. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2431.fc6 Load : 0.19 0.56 0.70 From rc040203 at freenet.de Tue Jul 25 10:54:23 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 12:54:23 +0200 Subject: [Fedora-packaging] BuildRoot In-Reply-To: <20060725123837.594257b9@python2> References: <20060725120720.34b753f4@python2> <1153822840.22104.181.camel@mccallum.corsepiu.local> <20060725123837.594257b9@python2> Message-ID: <1153824863.22104.192.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 12:38 +0200, Matthias Saou wrote: > Ralf Corsepius wrote : > Your example is bad. On a default installation, you'll hit permission > problems in /usr/src/ way before hitting them on /var/tmp... Yes. > so > you need the users to define stuff in their ~/.rpmmacros anyway. Why not > just also set %_tmppath there at the same time? Agreed, in a perfect world users should not have to add anything to .rpmmacros, but ... real world is different. > Makes your example work > fine. FYI, I never used /var/tmp for _tmppath when I used to build > on real systems... now with mach and mock, I don't care anymore. If _tmppath would default to ~/, or if redhat was shipping an rpm with a safe %buildroot, none of these issues wouldn't have popped up. Current real world is different: Users set %_topdir in .rpmmacros but nobody sets %_tmppath. > I'd really prefer we try to move forward here, i.e. get some comments > on my point n?2 about trying to set a sane (non empty like currently) > default for BuildRoot, so that we can simply forget about it in a few > releases. IMO the answer is clear: We are playing with symptoms. It should be solved inside of RPM. Unfortunately the responsible parties seem to prefer to push this issue to users, instead of solving it. Ralf From Axel.Thimm at ATrpms.net Tue Jul 25 10:58:55 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 12:58:55 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153824863.22104.192.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <1153822840.22104.181.camel@mccallum.corsepiu.local> <20060725123837.594257b9@python2> <1153824863.22104.192.camel@mccallum.corsepiu.local> Message-ID: <20060725105855.GC1164@neu.nirvana> On Tue, Jul 25, 2006 at 12:54:23PM +0200, Ralf Corsepius wrote: > IMO the answer is clear: We are playing with symptoms. It should be > solved inside of RPM. Unfortunately the responsible parties seem to > prefer to push this issue to users, instead of solving it. Have you tried suggesting it? Any thread/URL we can jump in and support you? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 25 11:00:19 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 25 Jul 2006 13:00:19 +0200 Subject: [Fedora-packaging] BuildRoot In-Reply-To: <20060725120720.34b753f4@python2> (Matthias Saou's message of "Tue, 25 Jul 2006 12:07:20 +0200") References: <20060725120720.34b753f4@python2> Message-ID: <8764hmlzjw.fsf@kosh.bigo.ensc.de> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: > 1) The current "preferred" BuildRoot which executes "id -u" isn't > useful when used with mach or mock. I have nothing against it, I just > don't feel the need to use it... as it's "preferred", I should be able > to still use any BuildRoot value I want, right? Yes; 'id -u' is unneeded clutter. A custom %_tmppath is much better and secure. > 2) Why the heck is there still the need for BuildRoot to be defined in > each and every spec file we have!? Could we once and for all push a > sane default value into FC6 and start considering removing it once and > for all from all spec files by the time we reach FC10 or so? To make an BuildRoot: optional/discouraged, some changes in rpm would be needed: * 'rpmbuild' fails to run as root * 'rpmbuild' fails when %buildroot is empty/undefined * rpm ships with a proper default %buildroot * the points above are true on all supported platforms I think, FC9 or FC10 would be a realistic target date. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 25 11:01:32 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 25 Jul 2006 13:01:32 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725104245.GA1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725104245.GA1164@neu.nirvana> Message-ID: <20060725130132.3348ff6b@python2> Axel Thimm wrote : > > 2) Why the heck is there still the need for BuildRoot to be defined in > > each and every spec file we have!? Could we once and for all push a > > sane default value into FC6 and start considering removing it once and > > for all from all spec files by the time we reach FC10 or so? > > Yes, that's the time scale, or maybe even FC110 :) > > > Currently, if BuildRoot isn't defined, then "" is used > > Not always, if you use %{buildroot} w/o BuildRoot: tag it expands to > literally to itself, e.g. "%{buildroot}". At least with FC5's > rpm. Maybe previously it was effectively %{nil}. Rebuilding for RHEL4, using mach on RHEL4, it seems to want to install relative to "/", so %{buildroot} is empty or %{nil}. This is going to be a really big problem as if we do remove BuildRoot from spec files some day, people rebuilding those packages on ancient systems as root might get bitten pretty hard (the "rm -rf %{buildroot}" parts). One possible solution would be to also "externalise" a default %clean and the cleaning of the %{buildroot} as the first step of %install. This seems like it would actually make sense since those are also "silly copy/paste" items present in every spec file nowadays, and some --noclean option could probably easily be implemented in rpmbuild. Thoughts? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2431.fc6 Load : 0.60 0.42 0.47 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 25 11:05:10 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 25 Jul 2006 13:05:10 +0200 Subject: [Fedora-packaging] BuildRoot In-Reply-To: <1153824863.22104.192.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <1153822840.22104.181.camel@mccallum.corsepiu.local> <20060725123837.594257b9@python2> <1153824863.22104.192.camel@mccallum.corsepiu.local> Message-ID: <20060725130510.40346388@python2> Ralf Corsepius wrote : > > Makes your example work > > fine. FYI, I never used /var/tmp for _tmppath when I used to build > > on real systems... now with mach and mock, I don't care anymore. > > If _tmppath would default to ~/, or if redhat was shipping an > rpm with a safe %buildroot, none of these issues wouldn't have popped > up. > > Current real world is different: Users set %_topdir in .rpmmacros but > nobody sets %_tmppath. Educate users! And in this case it's even easier since it's not the average Joe, but packagers or more advanced users. We've been educating them to use mock now anyway, right? :-) > > I'd really prefer we try to move forward here, i.e. get some comments > > on my point n?2 about trying to set a sane (non empty like currently) > > default for BuildRoot, so that we can simply forget about it in a few > > releases. > > IMO the answer is clear: We are playing with symptoms. It should be > solved inside of RPM. Unfortunately the responsible parties seem to > prefer to push this issue to users, instead of solving it. Then let's try and solve it! See my last email, and let us know what you think (default BuildRoot, %clean and %install first step). I should have also added a %defattr default, at least for the user/group of root/root... but let's try one step at a time ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2431.fc6 Load : 0.39 0.38 0.42 From Axel.Thimm at ATrpms.net Tue Jul 25 11:11:51 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 13:11:51 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725130132.3348ff6b@python2> References: <20060725120720.34b753f4@python2> <20060725104245.GA1164@neu.nirvana> <20060725130132.3348ff6b@python2> Message-ID: <20060725111151.GD1164@neu.nirvana> On Tue, Jul 25, 2006 at 01:01:32PM +0200, Matthias Saou wrote: > This is going to be a really big problem as if we do remove > BuildRoot from spec files some day, people rebuilding those packages > on ancient systems as root might get bitten pretty hard (the "rm -rf > %{buildroot}" parts). Now I understand why the [ "%{buildroot}" != / ] safeguard was in all specfiles I removed it ;) > One possible solution would be to also "externalise" a default %clean > and the cleaning of the %{buildroot} as the first step of %install. > This seems like it would actually make sense since those are also > "silly copy/paste" items present in every spec file nowadays, and some > --noclean option could probably easily be implemented in rpmbuild. > Thoughts? Maybe start a wishlist about what we want rpm-5.x to do and present it to rpm developers? Anyway, we need both a (very) long term plan which the rpm maintainer must agree to which eliminates having to use BuildRoot and rm -fr %{buildroot} in various places, and also a short term one which we can recitify with default macros and good guidelines. For example we could start by setting %{_topdir} and %{_tmppath} defaults in redhat-rpm-confg for non-root users into their homes. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Jul 25 11:36:25 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 13:36:25 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725104245.GA1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725104245.GA1164@neu.nirvana> Message-ID: <1153827385.22104.214.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 12:42 +0200, Axel Thimm wrote: > Hi, > > On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote: > > Two quickies : > > > > 1) The current "preferred" BuildRoot which executes "id -u" isn't > > useful when used with mach or mock. I have nothing against it, I just > > don't feel the need to use it... as it's "preferred", I should be able > > to still use any BuildRoot value I want, right? I really simply prefer > > the same, but without forking a useless "id -u" execution. > > > > Yet another discussion about this here : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188461 > > (nearly all my review requests change into debates regarding useless > > details... I'm surprised that no one has yet criticized the non-aligned > > header lines I use ;-)) > > > > If the "preferred" term is changed to "mandatory" in the guidelines, I > > will abide, but continue thinking it's plain silly, and this brings us > > to... > > This was discussed a couple of days ago here, check the archives. FWIW > I agree 110%. > > Ralf argues that two users on a multiuser system building the same > package with the same evr would get hurt (one would look the other's > buildroot), which I consider an extreme corner case. Absolutely not, consider this: A team develops a piece of SW. A co-worker starts building an rpm, and leaves at 3am after an rpmbuild had bombed out leaving %buildroot behind. Next morning, you log in to the same machine, check out his sources from svn/cvs and want to finish this work. rpmbuild .. > Furthermore currently building the same package for two archs (like > kernel at i686 and kernel at i586) will hurt even more, which is not a > corner case, so if we were to play it mega-safe we would had to add > arch/epoch also to it. Another example of a how views can vary: To me *this* is a very extreme case, because apart of very few package almost nothing in FE is being build for several targets. What's different about this situation, is this: If building under the same account, this user at least is able to clean up %buildroot. In my situation above, user2 can't clean up the remnants in %buildroot without applying %_tmpdir tricks, "su" tricks or calling "the admin". > Better keep it small, simple and functional. Better keep it consistent and conflict free. I want "a mandatory buildroot" to achieve deterministic behavior, comprising deterministic deficits and bugs. Your and Thias' %buildroot regresses in comparison to the "recommendation". It diverges from the "recommendation" and introduces further non-deterministical behavior. That's reason why I refuse to approve your packages. > Anyway it looked like half the people here considered it an optional > requirement (what "preferred" also really implied) and some would like > to make it mandatory. > > > 2) Why the heck is there still the need for BuildRoot to be defined in > > each and every spec file we have!? Could we once and for all push a > > sane default value into FC6 and start considering removing it once and > > for all from all spec files by the time we reach FC10 or so? > > Yes, that's the time scale, or maybe even FC110 :) Well, nothing has happened for a decade, so ... my estimate is "near infinity". Ralf From Axel.Thimm at ATrpms.net Tue Jul 25 11:45:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 13:45:30 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153827385.22104.214.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <20060725104245.GA1164@neu.nirvana> <1153827385.22104.214.camel@mccallum.corsepiu.local> Message-ID: <20060725114530.GE1164@neu.nirvana> On Tue, Jul 25, 2006 at 01:36:25PM +0200, Ralf Corsepius wrote: > Your and Thias' %buildroot regresses in comparison to the > "recommendation". It diverges from the "recommendation" and > introduces further non-deterministical behavior. > > That's reason why I refuse to approve your packages. Rex, where is that cluestick again? ;) Ralf, you do understand that `preferred' is there to indicate an *optional* guideline, and if everybody would ignore the official guidelines and apply his own no package would ever get through? Both Matthias' and mine BuildRoots are therefore conformant to the guidelines. (That's not a plea to review any of my packages, in fact better not ... ;) -- 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 paul at all-the-johnsons.co.uk Tue Jul 25 11:52:12 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Tue, 25 Jul 2006 12:52:12 +0100 Subject: [Fedora-packaging] Advice sought on a package currently under review Message-ID: <1153828332.2961.22.camel@localhost.localdomain> Hi, I'm currently reviewing libpano12. It's GPL and the version supplied doesn't break any patents due to a change. However, I've asked the person who has submitted the package how simple it would be to alter the code to break the patent and it's incredibly easy. Could someone advise me how to proceed with this package? I know how anal they are in the US over patents (if they exist or not sometimes!) and don't want to land in any hot water. The BZ ref is #200064 TTFN Paul P.S. Given I'm currently reviewing, am I able to sponsor or is that something that is decided elsewhere? The packager on this bug is unsponsored. -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From nicolas.mailhot at laposte.net Tue Jul 25 12:10:32 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 25 Jul 2006 14:10:32 +0200 (CEST) Subject: [Fedora-packaging] BuildRoot In-Reply-To: <20060725130510.40346388@python2> References: <20060725120720.34b753f4@python2> <1153822840.22104.181.camel@mccallum.corsepiu.local> <20060725123837.594257b9@python2> <1153824863.22104.192.camel@mccallum.corsepiu.local> <20060725130510.40346388@python2> Message-ID: <33937.192.54.193.51.1153829432.squirrel@rousalka.dyndns.org> Le Mar 25 juillet 2006 13:05, Matthias Saou a ?crit : > Educate users! And in this case it's even easier since it's not the > average Joe, but packagers or more advanced users. We've been educating > them to use mock now anyway, right? :-) ROFL LOL MDR Have you not never seen the packages ISV produce in the wild? -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Jul 25 12:15:10 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 25 Jul 2006 14:15:10 +0200 (CEST) Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725104245.GA1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725104245.GA1164@neu.nirvana> Message-ID: <56053.192.54.193.51.1153829710.squirrel@rousalka.dyndns.org> Le Mar 25 juillet 2006 12:42, Axel Thimm a ?crit : >> Currently, if BuildRoot isn't defined, then "" is used > > Not always, if you use %{buildroot} w/o BuildRoot: tag it expands to > literally to itself, e.g. "%{buildroot}". At least with FC5's > rpm. Maybe previously it was effectively %{nil}. That's actually a good argument to use %{buildroot} in every Fedora SPEC file, if you don't have the risk of ovewriting / with it. So my proposal would be: 1. add automatic buildroot to FC7 rpm (using mktemp and/or all the various ways packages can collide with each other) 2. replace all the $BUILDROOT instances with %{buildroot} so even if someone rebuilds a spec on pre-FC7 rpm as root he won't kill his system Regards, -- Nicolas Mailhot From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 25 12:27:20 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 25 Jul 2006 14:27:20 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725104953.GB1164@neu.nirvana> (Axel Thimm's message of "Tue, 25 Jul 2006 12:49:53 +0200") References: <20060725120720.34b753f4@python2> <1153822840.22104.181.camel@mccallum.corsepiu.local> <20060725123837.594257b9@python2> <20060725104953.GB1164@neu.nirvana> Message-ID: <871ws9na3b.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: > Ideally the default BuildRoot would be something using mktemp-like Plain 'mktemp' solution would be bad because different 'rpmbuild' ivocations (e.g. with '--short-circuit') would have different ideas about buildroot. Buildroot value must be predictable/reproducible; %_tmppath and %_topdir in $HOME is the easiest solution. This might cause conflict/problems with quotas or NFS, but should be a sane default. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Jul 25 13:43:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 08:43:52 -0500 Subject: [Fedora-packaging] Advice sought on a package currently under review In-Reply-To: <1153828332.2961.22.camel@localhost.localdomain> References: <1153828332.2961.22.camel@localhost.localdomain> Message-ID: <44C62018.8020804@math.unl.edu> PFJ wrote: > I'm currently reviewing libpano12. It's GPL and the version supplied > doesn't break any patents due to a change. > > However, I've asked the person who has submitted the package how simple > it would be to alter the code to break the patent and it's incredibly > easy. > > Could someone advise me how to proceed with this package? I know how > anal they are in the US over patents (if they exist or not sometimes!) > and don't want to land in any hot water. afaict, the package doesn't (knowingly) violate any patents as-is, so it should be fine. freetype is similar that as-is it is fine, but with a single change, it can (probably) be patent infringing. > P.S. Given I'm currently reviewing, am I able to sponsor or is that > something that is decided elsewhere? If you have to ask, then the answer is probably no. You need to be classified as a "sponsor" to be able to sponsor someone. See "Becoming a Sponsor" on http://fedoraproject.org/wiki/Extras/SponsorProcess -- Rex From paul at all-the-johnsons.co.uk Tue Jul 25 13:52:26 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Tue, 25 Jul 2006 14:52:26 +0100 Subject: [Fedora-packaging] Advice sought on a package currently under review In-Reply-To: <44C62018.8020804@math.unl.edu> References: <1153828332.2961.22.camel@localhost.localdomain> <44C62018.8020804@math.unl.edu> Message-ID: <1153835546.4532.2.camel@localhost.localdomain> Hi, > > Could someone advise me how to proceed with this package? I know how > > anal they are in the US over patents (if they exist or not sometimes!) > > and don't want to land in any hot water. > > afaict, the package doesn't (knowingly) violate any patents as-is, so it > should be fine. freetype is similar that as-is it is fine, but with a > single change, it can (probably) be patent infringing. Fair enough, my mind is set at piece. > > P.S. Given I'm currently reviewing, am I able to sponsor or is that > > something that is decided elsewhere? > > If you have to ask, then the answer is probably no. You need to be > classified as a "sponsor" to be able to sponsor someone. See "Becoming > a Sponsor" on > http://fedoraproject.org/wiki/Extras/SponsorProcess Looks like I need to be nominated which then gets poked through to the steering committee. The package in question builds find under mock and my review of it doesn't show any show stoppers anywhere, so can one of the existing sponsors have a looks and if they're happy, sponsor the chap? The BZ ref is #200064 TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From rdieter at math.unl.edu Tue Jul 25 13:54:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 08:54:24 -0500 Subject: [Fedora-packaging] Advice sought on a package currently under review In-Reply-To: <1153835546.4532.2.camel@localhost.localdomain> References: <1153828332.2961.22.camel@localhost.localdomain> <44C62018.8020804@math.unl.edu> <1153835546.4532.2.camel@localhost.localdomain> Message-ID: <44C62290.5080003@math.unl.edu> PFJ wrote: >>> P.S. Given I'm currently reviewing, am I able to sponsor or is that >>> something that is decided elsewhere? >> If you have to ask, then the answer is probably no. You need to be >> classified as a "sponsor" to be able to sponsor someone. See "Becoming >> a Sponsor" on >> http://fedoraproject.org/wiki/Extras/SponsorProcess > > Looks like I need to be nominated which then gets poked through to the > steering committee. You can nominate yourself too. (: -- Rex From tibbs at math.uh.edu Tue Jul 25 14:03:03 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 25 Jul 2006 09:03:03 -0500 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: <87ac6ym1pu.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Tue, 25 Jul 2006 12:13:33 +0200") References: <87ac6ym1pu.fsf@kosh.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> We came to the agreement that things like >> Requires: php >= 4.2 ES> do not make sense. We did? ES> Why is >> Requires: php >= current PHP version ES> a MUST item? Because you haven't gone in and changed the draft. Look, folks, I'm just a monkey here. I'm trying to parrot all of the discussion into a file because nobody else seems to be bothering to do so; if I miss something then I miss something. Don't read anything else into it. - J< From paul at all-the-johnsons.co.uk Tue Jul 25 14:05:49 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Tue, 25 Jul 2006 15:05:49 +0100 Subject: [Fedora-packaging] Advice sought on a package currently under review In-Reply-To: <44C62290.5080003@math.unl.edu> References: <1153828332.2961.22.camel@localhost.localdomain> <44C62018.8020804@math.unl.edu> <1153835546.4532.2.camel@localhost.localdomain> <44C62290.5080003@math.unl.edu> Message-ID: <1153836349.4532.4.camel@localhost.localdomain> Hi, > > Looks like I need to be nominated which then gets poked through to the > > steering committee. > > You can nominate yourself too. (: Neat! Who is the current FESCo chair? The wiki isn't exactly clear! TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 25 14:14:32 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 25 Jul 2006 16:14:32 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725114530.GE1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725104245.GA1164@neu.nirvana> <1153827385.22104.214.camel@mccallum.corsepiu.local> <20060725114530.GE1164@neu.nirvana> Message-ID: <20060725161432.3aa927b5@python2> Axel Thimm wrote : > On Tue, Jul 25, 2006 at 01:36:25PM +0200, Ralf Corsepius wrote: > > Your and Thias' %buildroot regresses in comparison to the > > "recommendation". It diverges from the "recommendation" and > > introduces further non-deterministical behavior. > > > > That's reason why I refuse to approve your packages. > > Rex, where is that cluestick again? ;) Oh, and please pass it on when you're done! :-) Ralf wrote in another reply : > > Furthermore currently building the same package for two archs (like > > kernel at i686 and kernel at i586) will hurt even more, which is not a > > corner case, so if we were to play it mega-safe we would had to add > > arch/epoch also to it. > > Another example of a how views can vary: > To me *this* is a very extreme case, because apart of very few package > almost nothing in FE is being build for several targets. If you're bringing the FE packaging back into the debate... err... it's weird since if we consider only FE, this is clearly a non issue. "Much ado about nothing" if you ask me. My final suggestions : 1) Bring up the default BuildRoot guideline issue at the next FESCO meeting. My suggestion for a possible change would be to have something like this in addition to the 'preferred' BuildRoot suggestion : "BuildRoot must be a sub-directory of "%{_tmppath}" and contain at least "%{name}" in its name." 2) Continue discussing simplifications and improvements for the long term which require changes ASAP. Typically like trying to drop the explicit BuildRoot from the spec files, set sane defaults for %clean, %defattr... basically avoid identical iterations across all spec files. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2431.fc6 Load : 0.39 0.30 0.28 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 25 14:32:58 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 25 Jul 2006 16:32:58 +0200 Subject: [Fedora-packaging] COPYING (license) not under docdir In-Reply-To: <1153741377.22104.65.camel@mccallum.corsepiu.local> References: <20060723211739.GA6491@neu.nirvana> <1153689930.13330.54.camel@cutter> <1153718235.22104.53.camel@mccallum.corsepiu.local> <44C4AFDF.6080602@math.unl.edu> <1153741377.22104.65.camel@mccallum.corsepiu.local> Message-ID: <20060725163258.7b36a90f@python2> Ralf Corsepius wrote : > If %{_datadir}//COPYING is used by a package, it's data, not > documentation. %doc'ing it would be a fault. Why? I don't understand why you claim (and not even just suggest) that. %_defaultdocdir even defaults to a sub-directory of %_datadir in our current setup. I don't see why a program's data under %_datadir couldn't contain its own online documentation, accessible from the program itself. And I really think this should be considered perfectly fine, as long as all of the relevant files are tagged as %doc in order to be easily identifiable when querying the package. This is even probably the reason why the %doc tag exists, since otherwise, why would you need to query a package for its documentation if it was mandatory for all of it to be under /usr/share/doc/name-version-rel? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2431.fc6 Load : 0.06 0.23 0.26 From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 25 14:36:40 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 25 Jul 2006 16:36:40 +0200 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: (Jason L. Tibbitts, III's message of "Tue, 25 Jul 2006 09:03:03 -0500") References: <87ac6ym1pu.fsf@kosh.bigo.ensc.de> Message-ID: <87r709lpjb.fsf@kosh.bigo.ensc.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: > ES> We came to the agreement that things like > >>> Requires: php >= 4.2 > > ES> do not make sense. > > We did? I think so: https://www.redhat.com/archives/fedora-packaging/2006-July/msg00086.html http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec >>> Requires: php >= current PHP version > > ES> a MUST item? > > Because you haven't gone in and changed the draft. ok; updated. > Look, folks, I'm just a monkey here. I'm trying to parrot all of the > discussion into a file because nobody else seems to be bothering to do > so; if I miss something then I miss something. Don't read anything > else into it. ok; but I do not understand the drafts-flow then. IMO, drafts should reflect the state of current discussion and should be updated. It does not help when discussion on maillist is ignored and some obsolete document will be ratified. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jul 25 14:46:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 16:46:10 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725120720.34b753f4@python2> References: <20060725120720.34b753f4@python2> Message-ID: <20060725144610.GG1164@neu.nirvana> On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote: > 1) The current "preferred" BuildRoot which executes "id -u" isn't > useful [...] How about the following patch (yet untested) to redhat-rpm-config in devel and thus FC6/RHEL5? It would eliminate some issues and allow for better planning: diff -rud redhat-rpm-config-8.0.43.org/macros redhat-rpm-config-8.0.43/macros --- redhat-rpm-config-8.0.43.org/macros 2005-08-17 02:27:33.000000000 +0200 +++ redhat-rpm-config-8.0.43/macros 2006-07-25 16:38:53.000000000 +0200 @@ -156,3 +156,18 @@ # Disable lookups %_hkp_keyserver %{nil} + +#============================================================================== +# These are the default values that can be overridden by other +# (e.g. per-platform, per-system, per-packager, per-package) macros. +# +# Path to top of build area. +%_topdir %(test `%{__id_u}` = 0 && echo %{_usrsrc}/redhat || echo $HOME/rpmbuild) + +# Directory where temporary files can be created. +%_tmppath %(test `%{__id_u}` = 0 && echo %{_var}/tmp || echo $HOME/rpmbuild/tmp + +# Configurable build root path, same as BuildRoot: in a specfile. +# (Note: the configured macro value will override the spec file value). + +%buildroot %{_tmppath}/%{name}-%{version}-%{release} -- 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 paul at city-fan.org Tue Jul 25 14:48:58 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 25 Jul 2006 15:48:58 +0100 Subject: [Fedora-packaging] COPYING (license) not under docdir In-Reply-To: <20060725163258.7b36a90f@python2> References: <20060723211739.GA6491@neu.nirvana> <1153689930.13330.54.camel@cutter> <1153718235.22104.53.camel@mccallum.corsepiu.local> <44C4AFDF.6080602@math.unl.edu> <1153741377.22104.65.camel@mccallum.corsepiu.local> <20060725163258.7b36a90f@python2> Message-ID: <44C62F5A.7060208@city-fan.org> Matthias Saou wrote: > Ralf Corsepius wrote : > >> If %{_datadir}//COPYING is used by a package, it's data, not >> documentation. %doc'ing it would be a fault. > > Why? I don't understand why you claim (and not even just suggest) that. > %_defaultdocdir even defaults to a sub-directory of %_datadir in our > current setup. > > I don't see why a program's data under %_datadir couldn't contain its > own online documentation, accessible from the program itself. And I > really think this should be considered perfectly fine, as long as all > of the relevant files are tagged as %doc in order to be easily > identifiable when querying the package. > > This is even probably the reason why the %doc tag exists, since > otherwise, why would you need to query a package for its documentation > if it was mandatory for all of it to be > under /usr/share/doc/name-version-rel? Documentation placed under %_datadir is both data *and* documentation. It's data from the point of view that the program uses it at runtime. As a result of this, that data should *not* be marked %doc because it would then be excluded from installation if the package was installed using "--excludedocs", and that would break the packaging rule: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. In the case under discussion, this would be broken if the license file under %_datadir was not installed, because the GTK GUI wants to be able to display it. Paul. From Axel.Thimm at ATrpms.net Tue Jul 25 14:55:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 16:55:08 +0200 Subject: [Fedora-packaging] Re: COPYING (license) not under docdir In-Reply-To: <20060725163258.7b36a90f@python2> References: <20060723211739.GA6491@neu.nirvana> <1153689930.13330.54.camel@cutter> <1153718235.22104.53.camel@mccallum.corsepiu.local> <44C4AFDF.6080602@math.unl.edu> <1153741377.22104.65.camel@mccallum.corsepiu.local> <20060725163258.7b36a90f@python2> Message-ID: <20060725145508.GH1164@neu.nirvana> On Tue, Jul 25, 2006 at 04:32:58PM +0200, Matthias Saou wrote: > Ralf Corsepius wrote : > > If %{_datadir}//COPYING is used by a package, it's data, not > > documentation. %doc'ing it would be a fault. > > Why? I don't understand why you claim (and not even just suggest) that. > %_defaultdocdir even defaults to a sub-directory of %_datadir in our > current setup. For minimal chroots you can install packages w/o docs, therefore the functionality of the package should not be hindered if docs are missing. Man & info, as well as /usr/share/doc/* are usually discardable, e.g. only used directly, not though the application. > I don't see why a program's data under %_datadir couldn't contain > its own online documentation, accessible from the program > itself. And I really think this should be considered perfectly fine, > as long as all of the relevant files are tagged as %doc in order to > be easily identifiable when querying the package. > > This is even probably the reason why the %doc tag exists, since > otherwise, why would you need to query a package for its > documentation if it was mandatory for all of it to be under > /usr/share/doc/name-version-rel? It seems like the only rpm-internal purpose of the doc flag on files is indeed to be able to skip them on installation, but this knowledge has been burried in the sands of time. As a side effect %doc on relative paths performs a copy operation, too, which is the most common use today. I think it's better to not assume %doc'ed files are really around for the application to use. BTW are gnome help files tagged as %doc? -- 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 Christian.Iseli at licr.org Tue Jul 25 15:01:18 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 25 Jul 2006 17:01:18 +0200 Subject: [Fedora-packaging] Advice sought on a package currently under review In-Reply-To: Your message of "Tue, 25 Jul 2006 15:05:49 BST." <1153836349.4532.4.camel@localhost.localdomain> Message-ID: <200607251501.k6PF1IUn032366@ludwig-alpha.unil.ch> paul at all-the-johnsons.co.uk said: > Neat! uh oh... too late. Thanks for volunteering :-) Your case will now be discussed at the next FESCo meeting... You seem to have participated in 12 review requests... https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&product=Fedora+Extras&component=Package+Review&emailassigned_to1=1&emaillongdesc1=1&emailtype1=exact&email1=paul%40all-the-johnsons.co.uk&emailreporter2=1&emailtype2=notregexp&email2=paul%40all-the-johnsons.co.uk > Who is the current FESCo chair? The wiki isn't exactly clear! thl Cheers, Christian From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 25 15:02:48 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 25 Jul 2006 17:02:48 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725144610.GG1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> Message-ID: <20060725170248.4bf15c6b@python2> Axel Thimm wrote : > On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote: > > 1) The current "preferred" BuildRoot which executes "id -u" isn't > > useful [...] > > How about the following patch (yet untested) to redhat-rpm-config in > devel and thus FC6/RHEL5? It would eliminate some issues and allow for > better planning: Exactly what I was about to try too :-) I'm really all for having that kind of change go in ASAP. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2431.fc6 Load : 1.79 1.26 0.73 From rdieter at math.unl.edu Tue Jul 25 15:08:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 10:08:28 -0500 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725170248.4bf15c6b@python2> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <20060725170248.4bf15c6b@python2> Message-ID: <44C633EC.7030304@math.unl.edu> Matthias Saou wrote: > Axel Thimm wrote : > >> On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote: >>> 1) The current "preferred" BuildRoot which executes "id -u" isn't >>> useful [...] >> How about the following patch (yet untested) to redhat-rpm-config in >> devel and thus FC6/RHEL5? It would eliminate some issues and allow for >> better planning: > > Exactly what I was about to try too :-) > I'm really all for having that kind of change go in ASAP. +1 -- Rex From paul at all-the-johnsons.co.uk Tue Jul 25 15:09:32 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Tue, 25 Jul 2006 16:09:32 +0100 Subject: [Fedora-packaging] Advice sought on a package currently under review In-Reply-To: <200607251501.k6PF1IUn032366@ludwig-alpha.unil.ch> References: <200607251501.k6PF1IUn032366@ludwig-alpha.unil.ch> Message-ID: <1153840172.4532.18.camel@localhost.localdomain> Hi, > Thanks for volunteering :-) :-D > Your case will now be discussed at the next FESCo meeting... I see many of the FESCo people on IRC every night where they are plied with lots of virtual goodies ;-) TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From tibbs at math.uh.edu Tue Jul 25 15:25:24 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 25 Jul 2006 10:25:24 -0500 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: <87r709lpjb.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Tue, 25 Jul 2006 16:36:40 +0200") References: <87ac6ym1pu.fsf@kosh.bigo.ensc.de> <87r709lpjb.fsf@kosh.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> IMO, drafts should reflect the state of current discussion and ES> should be updated. It does not help when discussion on maillist is ES> ignored and some obsolete document will be ratified. If you're trying to tell me that I shouldn't have tried then I'll be happy to stop. But I'm not sure that any progress at all is going to be made unless I push it. My only concern here is for the packagers whose packages are rotting in the queue because this committee can't seem to make any forward progress. - J< From rc040203 at freenet.de Tue Jul 25 15:26:24 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 17:26:24 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725161432.3aa927b5@python2> References: <20060725120720.34b753f4@python2> <20060725104245.GA1164@neu.nirvana> <1153827385.22104.214.camel@mccallum.corsepiu.local> <20060725114530.GE1164@neu.nirvana> <20060725161432.3aa927b5@python2> Message-ID: <1153841185.22104.280.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 16:14 +0200, Matthias Saou wrote: > Axel Thimm wrote : > > > On Tue, Jul 25, 2006 at 01:36:25PM +0200, Ralf Corsepius wrote: > > > Your and Thias' %buildroot regresses in comparison to the > > > "recommendation". It diverges from the "recommendation" and > > > introduces further non-deterministical behavior. > > > > > > That's reason why I refuse to approve your packages. > > > Furthermore currently building the same package for two archs (like > > > kernel at i686 and kernel at i586) will hurt even more, which is not a > > > corner case, so if we were to play it mega-safe we would had to add > > > arch/epoch also to it. > > > > Another example of a how views can vary: > > To me *this* is a very extreme case, because apart of very few package > > almost nothing in FE is being build for several targets. > > If you're bringing the FE packaging back into the debate... err... it's > weird since if we consider only FE, this is clearly a non issue. You intentional don't seem to be wanting to understand: I am saying: The FE guideline recommendation supports rebuilding in a typical user environment. Yours doesn't. As such it is a feature regression and qualifies as a bug, which is sufficient reason for me not to approve such packages. > My final suggestions : > > 1) Bring up the default BuildRoot guideline issue at the next FESCO > meeting. I have put it on the packaging committee's agenda a couple of days ago. > My suggestion for a possible change would be to have something > like this in addition to the 'preferred' BuildRoot suggestion : > > "BuildRoot must be a sub-directory of "%{_tmppath}" and contain at > least "%{name}" in its name." Unacceptable to me. Ralf From enrico.scholz at informatik.tu-chemnitz.de Tue Jul 25 15:39:49 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 25 Jul 2006 17:39:49 +0200 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: (Jason L. Tibbitts, III's message of "Tue, 25 Jul 2006 10:25:24 -0500") References: <87ac6ym1pu.fsf@kosh.bigo.ensc.de> <87r709lpjb.fsf@kosh.bigo.ensc.de> Message-ID: <87mzaxlmm2.fsf@kosh.bigo.ensc.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: > ES> IMO, drafts should reflect the state of current discussion and > ES> should be updated. It does not help when discussion on maillist is > ES> ignored and some obsolete document will be ratified. > > If you're trying to tell me that I shouldn't have tried then I'll be > happy to stop. No; I just think that the proposer of a draft shall maintain and update it. Wrong/outdated information is much more worse than missing one. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rc040203 at freenet.de Tue Jul 25 15:55:03 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 17:55:03 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725144610.GG1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> Message-ID: <1153842903.22104.288.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 16:46 +0200, Axel Thimm wrote: > On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote: > How about the following patch (yet untested) to redhat-rpm-config in > devel and thus FC6/RHEL5? It would eliminate some issues and allow for > better planning: This would need quite an amount of testing. > diff -rud redhat-rpm-config-8.0.43.org/macros redhat-rpm-config-8.0.43/macros > --- redhat-rpm-config-8.0.43.org/macros 2005-08-17 02:27:33.000000000 +0200 > +++ redhat-rpm-config-8.0.43/macros 2006-07-25 16:38:53.000000000 +0200 > @@ -156,3 +156,18 @@ > > # Disable lookups > %_hkp_keyserver %{nil} > + > +#============================================================================== > +# These are the default values that can be overridden by other > +# (e.g. per-platform, per-system, per-packager, per-package) macros. > +# > +# Path to top of build area. > +%_topdir %(test `%{__id_u}` = 0 && echo %{_usrsrc}/redhat || echo $HOME/rpmbuild) > + > +# Directory where temporary files can be created. > +%_tmppath %(test `%{__id_u}` = 0 && echo %{_var}/tmp || echo $HOME/rpmbuild/tmp > + > +# Configurable build root path, same as BuildRoot: in a specfile. > +# (Note: the configured macro value will override the spec file value). > + > +%buildroot %{_tmppath}/%{name}-%{version}-%{release} - Doesn't work in your several %arch's case. - Do %_topdir/%_tmppath in .rpmmacros still work? - How does this interact with *.spec files containing hard-coded %Buildroots? - Do %name, %version, %release always expand correctly (Rpm suffers from a bug, where at least %name or %version (I don't recall exactly) occasionally is not being expanded correctly)? Ralf From tibbs at math.uh.edu Tue Jul 25 15:57:50 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 25 Jul 2006 10:57:50 -0500 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: <87mzaxlmm2.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Tue, 25 Jul 2006 17:39:49 +0200") References: <87ac6ym1pu.fsf@kosh.bigo.ensc.de> <87r709lpjb.fsf@kosh.bigo.ensc.de> <87mzaxlmm2.fsf@kosh.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> No; I just think that the proposer of a draft shall maintain and ES> update it. It's a group effort, isn't it? I have stated many times that I do not fully understand all of the issues and am simply trying to move things forward. If I'm going to get flack for that, I'd rather just not bother. ES> Wrong/outdated information is much more worse than missing one. If others wish it, I will delete the draft and drop the item from the schedule. - J< From Fedora at FamilleCollet.com Tue Jul 25 16:08:08 2006 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 25 Jul 2006 18:08:08 +0200 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: References: Message-ID: <44C641E8.60702@FamilleCollet.com> Jason L Tibbitts III a ?crit : > So, is there still any interest in PHP guidelines at all? > Of course. I have a lot of packages in review or waiting for it to be approved. Bugs : 190007, 190066, 190101, 190156, 190956, 190957, 190958, 192583 And some others near ready... > I worked up http://fedoraproject.org/wiki/PackagingDrafts/PHP but then > Ville had an idea for a template that doesn't need any special macro > definitions to be provided by the php-pear package. I don't know what > the current state of things is. > > Is there any chance of making any forward movement soon? We're going > to start losing packagers if we can't get some reviews done soon. > > Regarding PECL modules, I looked over the php-pecl-xdebug package > which is the only PECL module under review currently. There is also php-pecl-zip (approved but waiting the this guidelines approved) > The spec is > clean and requires two macros which I have in the above draft, > although the means for determining the API version is completely > different. Could someone comment on the differences and relative > strengths of: > > %define php_apiver %((phpize --version 2>/dev/null || echo 'PHP Api Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*: *//p') > > and > > %define php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) > Default values are different (0 for php -i, 20041225 for phpize --version). I think phpize is faster and is made for this. In a future we'll probably have to check the 3 values (from phpize --version) as PHP Api Version seems meaningless for me (don't change). For php-5.1.4 : PHP Api Version: 20041225 Zend Module Api No: 20050922 Zend Extension Api No: 220051025 For php-5.2.0 (dev) PHP Api Version: 20041225 (no change) Zend Module Api No: 20060613 Zend Extension Api No: 220060519 I think "Requires: php >= #.#.#" is not a good thing (except for very recent version) as pear extensions could be used with php command. The requirement of php also imply httpd. And php already required by php-pear. In Rawhide, php as split in 3 packages : php (apache module) and php-cli and php-common php-api is now provides by php-common (there still have a lot of job to do to allow php-cli and extension installation possible without php). Having a template for spec file is probably a good idea, but the simplest way to create a spec file is to use "pear makerpm" or "pear make-rpm-spec". So this commands should conform to this guildelines. See bug # 185423 Cordialy Remi. From Axel.Thimm at ATrpms.net Tue Jul 25 16:16:39 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 18:16:39 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153842903.22104.288.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> Message-ID: <20060725161639.GJ1164@neu.nirvana> On Tue, Jul 25, 2006 at 05:55:03PM +0200, Ralf Corsepius wrote: > On Tue, 2006-07-25 at 16:46 +0200, Axel Thimm wrote: > > On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote: > > How about the following patch (yet untested) to redhat-rpm-config > > in devel and thus FC6/RHEL5? It would eliminate some issues and > > allow for better planning: > This would need quite an amount of testing. So start testing today :) > > diff -rud redhat-rpm-config-8.0.43.org/macros redhat-rpm-config-8.0.43/macros > > --- redhat-rpm-config-8.0.43.org/macros 2005-08-17 02:27:33.000000000 +0200 > > +++ redhat-rpm-config-8.0.43/macros 2006-07-25 16:38:53.000000000 +0200 > > @@ -156,3 +156,18 @@ > > > > # Disable lookups > > %_hkp_keyserver %{nil} > > + > > +#============================================================================== > > +# These are the default values that can be overridden by other > > +# (e.g. per-platform, per-system, per-packager, per-package) macros. > > +# > > +# Path to top of build area. > > +%_topdir %(test `%{__id_u}` = 0 && echo %{_usrsrc}/redhat || echo $HOME/rpmbuild) > > + > > +# Directory where temporary files can be created. > > +%_tmppath %(test `%{__id_u}` = 0 && echo %{_var}/tmp || echo $HOME/rpmbuild/tmp > > + > > +# Configurable build root path, same as BuildRoot: in a specfile. > > +# (Note: the configured macro value will override the spec file value). > > + > > +%buildroot %{_tmppath}/%{name}-%{version}-%{release} > > - Doesn't work in your several %arch's case. I didn't want to obfuscate it, better use sane and common defaults. The argument about arch was relative and not absolute anyway: "arch is more important than id, therefor if we skip arch, we need to skip id". But the scheme above even takes care of your multiuser- build-the-same-package-corner-case, so at least you have no reason not to be happy. > - Do %_topdir/%_tmppath in .rpmmacros still work? There's no reason not to. The current setup has their default setup in a macro file just the same, the above just changes these defaults. > - How does this interact with *.spec files containing hard-coded > %Buildroots? Read the comments. > - Do %name, %version, %release always expand correctly (Rpm suffers from > a bug, where at least %name or %version (I don't recall exactly) > occasionally is not being expanded correctly)? URL? I've never seen a macro fail using name/version and I use them quite a lot. Of course - as said - the above is untested, so anything may happen. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jul 25 16:21:28 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 18:21:28 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <44C633EC.7030304@math.unl.edu> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <20060725170248.4bf15c6b@python2> <44C633EC.7030304@math.unl.edu> Message-ID: <20060725162128.GK1164@neu.nirvana> On Tue, Jul 25, 2006 at 10:08:28AM -0500, Rex Dieter wrote: > Matthias Saou wrote: > >Axel Thimm wrote : > > > >>On Tue, Jul 25, 2006 at 12:07:20PM +0200, Matthias Saou wrote: > >>>1) The current "preferred" BuildRoot which executes "id -u" isn't > >>>useful [...] > >>How about the following patch (yet untested) to redhat-rpm-config in > >>devel and thus FC6/RHEL5? It would eliminate some issues and allow for > >>better planning: > > > >Exactly what I was about to try too :-) > >I'm really all for having that kind of change go in ASAP. > > +1 OK, let's vote on it on Thursday (as well as whether Matthias' and mine unpreferred-buildroot packages are to be banned or not ;), and if it passes I'll open up a bugzilla against redhat-rpm-config on behalf of the packaging group with whatever default macros we consider sane. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Jul 25 16:29:28 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 18:29:28 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725161639.GJ1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> Message-ID: <1153844968.22104.301.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 18:16 +0200, Axel Thimm wrote: > On Tue, Jul 25, 2006 at 05:55:03PM +0200, Ralf Corsepius wrote: > > - Doesn't work in your several %arch's case. > > I didn't want to obfuscate it, better use sane and common defaults. Well, your %buildroot isn't sane. It clashes and breaks on %arch > The argument about arch was relative and not absolute anyway: "arch is > more important than id, therefor if we skip arch, we need to skip id". That's your argumentation. Mine is: The current build root supports id, but breaks on arch (== defect of the recommendation) => We should fix this. > But the scheme above even takes care of your multiuser- > build-the-same-package-corner-case, so at least you have no reason not > to be happy. == no substantial progress on features in comparison to the current FE recommendation. > > - Do %name, %version, %release always expand correctly (Rpm suffers from > > a bug, where at least %name or %version (I don't recall exactly) > > occasionally is not being expanded correctly)? > > URL? Sorry, none. > I've never seen a macro fail using name/version and I use them > quite a lot. I once encountered it when simultaneously building several packages from several source packages in one rpm.spec. It had been a spec similar to this Name: xxx Version: 1 Release: 0 .. Source0: xxx-1.tar.gz Source1: yyy-2.tar.gz ... %package -n yyy Name: yyy Version: 2 .. In this case, the order of rpm sections (%build, %install etc.) is of essential importance. Depending on where they are located, %version or %name expands to either xxx or yyy rsp. 1 or 2. Unfortunately I don't have an example at hand to reproduce it. Ralf From Axel.Thimm at ATrpms.net Tue Jul 25 16:41:38 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 18:41:38 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153844968.22104.301.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> Message-ID: <20060725164138.GM1164@neu.nirvana> On Tue, Jul 25, 2006 at 06:29:28PM +0200, Ralf Corsepius wrote: > > But the scheme above even takes care of your multiuser- > > build-the-same-package-corner-case, so at least you have no reason not > > to be happy. > == no substantial progress on features in comparison to the current FE > recommendation. Apples are not more yellow than oranges. redhat-rpm-config patch: always ensures sane coherent buildroots, no matter what the specfile guideline: a disputable, non-mandatory recommendation > > > - Do %name, %version, %release always expand correctly (Rpm suffers from > > > a bug, where at least %name or %version (I don't recall exactly) > > > occasionally is not being expanded correctly)? > > > > URL? > > Sorry, none. > [...] > Unfortunately I don't have an example at hand to reproduce it. Let's file it under hear-say then and move on. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 25 17:29:12 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 25 Jul 2006 19:29:12 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153841185.22104.280.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <20060725104245.GA1164@neu.nirvana> <1153827385.22104.214.camel@mccallum.corsepiu.local> <20060725114530.GE1164@neu.nirvana> <20060725161432.3aa927b5@python2> <1153841185.22104.280.camel@mccallum.corsepiu.local> Message-ID: <20060725192912.66cba985@python2> Ralf Corsepius wrote : > You intentional don't seem to be wanting to understand: > > I am saying: The FE guideline recommendation supports rebuilding in a > typical user environment. Yours doesn't. As such it is a feature > regression and qualifies as a bug, which is sufficient reason for me not > to approve such packages. I really think you jump to conclusions way too fast here. As I already wrote a few times, I get your point, but as the `id -u` hack doesn't even take care of the default setup (i.e. users need to manually define a %_topdir anyway), and that I consider the proper fix to be defining a %_tmppath, I just find it as m00t as it can get. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.91 (FC6 Test2) - Linux kernel 2.6.17-1.2445.fc6 Load : 0.13 0.20 0.19 From rc040203 at freenet.de Tue Jul 25 17:37:24 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 19:37:24 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725164138.GM1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> Message-ID: <1153849045.22104.316.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 18:41 +0200, Axel Thimm wrote: > Let's file it under hear-say then and move on. No comment c.f. below and note the output of the "echos". Ralf -------------- next part -------------- Name: test1 Version: 1 Release: 0%{?dist}.0 Group: xxx License: Free outside of atrpms.org Summary: test1 %description -n test1 test1 %package -n test2 Summary: test2 Version: 2 Group: yyy %description -n test2 test2 %build echo "%name-%version" %install echo "%name-%version" From rdieter at math.unl.edu Tue Jul 25 17:40:18 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 12:40:18 -0500 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153849045.22104.316.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> <1153849045.22104.316.camel@mccallum.corsepiu.local> Message-ID: <44C65782.6080307@math.unl.edu> Ralf Corsepius wrote: > On Tue, 2006-07-25 at 18:41 +0200, Axel Thimm wrote: > >> Let's file it under hear-say then and move on. > No comment > > c.f. below and note the output of the "echos". I think it's safe to just say this is an example of bad rpm practice. If you really want/need two different sources and versions, package them separately. -- Rex > ------------------------------------------------------------------------ > > Name: test1 > Version: 1 > Release: 0%{?dist}.0 > Group: xxx > License: Free outside of atrpms.org > Summary: test1 > > %description -n test1 > test1 > > %package -n test2 > Summary: test2 > Version: 2 > Group: yyy > > %description -n test2 > test2 > > > %build > echo "%name-%version" > > %install > echo "%name-%version" From ville.skytta at iki.fi Tue Jul 25 18:14:58 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 25 Jul 2006 21:14:58 +0300 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: References: Message-ID: <1153851298.2769.396.camel@localhost.localdomain> On Mon, 2006-07-24 at 18:26 -0700, Christopher Stone wrote: > Well Ville made a bunch of changes to the spec file template so that > it doesn't have to use macros. That's just a "food for thought" patch attached to Bugzilla (#198706) for comments, not committed anywhere yet. > It essentially complicates the default > spec template. The reason for adding all of this additional > complexity is to support deprecated distributions. Such as FC5 as it stands now? Shrug. The initial suggested template hardcoded /usr/bin/pear scriptlet dependencies, but actually used %{__pear} in them. This is apparently done to work around the case where even "make srpm" would fail if %{__pear} is not defined (which would very likely result in eg. the current FE buildsys not being able to build those packages for *any* distro version without changes, because %{__pear} was not conditionally defined in the specfile). But the above workaround is broken everywhere, including when %{__pear} is defined, and makes the whole %{__pear} macro questionable. There are several ways to fix the problem consistently. As far as I can tell, all of them include either conditionally defining %{__pear} in the specfile and using it everywhere, or not using it at all and reverting to %{_bindir}/pear or /usr/bin/pear instead and using that everywhere. In addition to the above, it would be good to 1) buildrequire something that defines rest of the used macros, or 2) conditionally define them in the specfile, or 3) forget about the rest of the macros and use something like the "food for thought" approach. Until the macros are in FC5, 1) (or not adding the BR) is a blocker for inclusion of the template in rpmdevtools or a blocker for the new release of rpmdevtools for FC5. 2) and 3) don't block anything, and would have the additional benefit of working with earlier distro versions. The package.xml issue mentioned in #198706 comment 3 needs some attention too, and the comment contains a suggested fix. I'm not going to spend any more time working on this. Please just provide patches you would like to see applied over the spectemplate-php-pear.spec and newrpmspec in rpmdevtools CVS ("fedora-rpmdevtools" in the "fedora" (not extras) CVS root) to bug 198706 when you've figured out what it will be. > Also Ville insists on their being a %build section for an unknown > reason. I did provide a reason, you seem to choose to ignore it. From rc040203 at freenet.de Tue Jul 25 18:18:19 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 20:18:19 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <44C65782.6080307@math.unl.edu> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> <1153849045.22104.316.camel@mccallum.corsepiu.local> <44C65782.6080307@math.unl.edu> Message-ID: <1153851499.22104.323.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 12:40 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Tue, 2006-07-25 at 18:41 +0200, Axel Thimm wrote: > > > >> Let's file it under hear-say then and move on. > > No comment > > > > c.f. below and note the output of the "echos". > > I think it's safe to just say this is an example of bad rpm practice. > If you really want/need two different sources and versions, package them > separately. ... you are ignoring the fact that there exist cases where this is impossible. Ralf From rdieter at math.unl.edu Tue Jul 25 18:26:44 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 13:26:44 -0500 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153851499.22104.323.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> <1153849045.22104.316.camel@mccallum.corsepiu.local> <44C65782.6080307@math.unl.edu> <1153851499.22104.323.camel@mccallum.corsepiu.local> Message-ID: <44C66264.60106@math.unl.edu> Ralf Corsepius wrote: > On Tue, 2006-07-25 at 12:40 -0500, Rex Dieter wrote: >> Ralf Corsepius wrote: >>> On Tue, 2006-07-25 at 18:41 +0200, Axel Thimm wrote: >>> >>>> Let's file it under hear-say then and move on. >>> No comment >>> >>> c.f. below and note the output of the "echos". >> I think it's safe to just say this is an example of bad rpm practice. >> If you really want/need two different sources and versions, package them >> separately. > > ... you are ignoring the fact that there exist cases where this is > impossible. Seriously, it's bad practice, don't do it. But don't mind me, go ahead and do it, if it's so "impossible" to do otherwise... just don't complain when it doesn't work. Besides, in this context/discussion of BuildRoots, I don't see how your example applies anyway. -- Rex From rc040203 at freenet.de Tue Jul 25 18:47:33 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 20:47:33 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <44C66264.60106@math.unl.edu> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> <1153849045.22104.316.camel@mccallum.corsepiu.local> <44C65782.6080307@math.unl.edu> <1153851499.22104.323.camel@mccallum.corsepiu.local> <44C66264.60106@math.unl.edu> Message-ID: <1153853253.22104.339.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 13:26 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Tue, 2006-07-25 at 12:40 -0500, Rex Dieter wrote: > >> Ralf Corsepius wrote: > >>> On Tue, 2006-07-25 at 18:41 +0200, Axel Thimm wrote: > >>> > >>>> Let's file it under hear-say then and move on. > >>> No comment > >>> > >>> c.f. below and note the output of the "echos". > >> I think it's safe to just say this is an example of bad rpm practice. > >> If you really want/need two different sources and versions, package them > >> separately. > > > > ... you are ignoring the fact that there exist cases where this is > > impossible. > > Seriously, it's bad practice, don't do it. But don't mind me, go ahead > and do it, if it's so "impossible" to do otherwise... Check out any one tree style built GCC+newlib rpm, check out autogen + libopts (currently under review). > just don't > complain when it doesn't work. Bummer, a tool (here: rpm) isn't broken, just because it doesn't fail on the 90% of trivial cases it is being used by, but fails on the remaining 10% of complex cases? Ralf From ville.skytta at iki.fi Tue Jul 25 20:26:26 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 25 Jul 2006 23:26:26 +0300 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725161639.GJ1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> Message-ID: <1153859186.2769.478.camel@localhost.localdomain> On Tue, 2006-07-25 at 18:16 +0200, Axel Thimm wrote: > On Tue, Jul 25, 2006 at 05:55:03PM +0200, Ralf Corsepius wrote: > > On Tue, 2006-07-25 at 16:46 +0200, Axel Thimm wrote: > > > + > > > +#============================================================================== > > > +# These are the default values that can be overridden by other > > > +# (e.g. per-platform, per-system, per-packager, per-package) macros. > > > +# > > > +# Path to top of build area. > > > +%_topdir %(test `%{__id_u}` = 0 && echo %{_usrsrc}/redhat || echo $HOME/rpmbuild) > > > + > > > +# Directory where temporary files can be created. > > > +%_tmppath %(test `%{__id_u}` = 0 && echo %{_var}/tmp || echo $HOME/rpmbuild/tmp > > > + > > > +# Configurable build root path, same as BuildRoot: in a specfile. > > > +# (Note: the configured macro value will override the spec file value). > > > + > > > +%buildroot %{_tmppath}/%{name}-%{version}-%{release} > > > > - Doesn't work in your several %arch's case. > > I didn't want to obfuscate it, better use sane and common defaults. The above looks ok on first sight, and would look even better if %buildroot was defined as %{_tmppath}/%{name}-%{version}-%{release}-%{_target_cpu} which I'd assume to take care of the multiarch simultaneous build issue and not really obfuscate things at all. Too bad it doesn't work very well, for "BuildArch: noarch" packages, %{buildroot} ends up ending with -noarch here as expected, but $RPM_BUILD_ROOT ends with -x86_64. And for example many scripts in /usr/lib/rpm operate on $RPM_BUILD_ROOT. On the other hand, explicit --target to rpmbuild affects both consistently, so I suppose BuildArch (not limited to noarch) in specfiles kicks in too late to affect $RPM_BUILD_ROOT. Reproducer: try rpmbuild -bp with this specfile and the above %buildroot definition in macros somewhere: --- Name: foo Version: 1 Release: 1 Summary: foo Group: foo License: foo BuildArch: noarch %description %prep echo %{buildroot} echo $RPM_BUILD_ROOT --- /var/tmp/foo-1-1-noarch /var/tmp/foo-1-1-x86_64 From rdieter at math.unl.edu Tue Jul 25 20:47:00 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 15:47:00 -0500 Subject: [Fedora-packaging] Re: Re: BuildRoot References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> <1153849045.22104.316.camel@mccallum.corsepiu.local> <44C65782.6080307@math.unl.edu> <1153851499.22104.323.camel@mccallum.corsepiu.local> <44C66264.60106@math.unl.edu> <1153853253.22104.339.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Tue, 2006-07-25 at 13:26 -0500, Rex Dieter wrote: >> Ralf Corsepius wrote: >> > On Tue, 2006-07-25 at 12:40 -0500, Rex Dieter wrote: >> >> Ralf Corsepius wrote: >> >>> On Tue, 2006-07-25 at 18:41 +0200, Axel Thimm wrote: >> >>> >> >>>> Let's file it under hear-say then and move on. >> >>> No comment >> >>> >> >>> c.f. below and note the output of the "echos". >> >> I think it's safe to just say this is an example of bad rpm practice. >> >> If you really want/need two different sources and versions, package >> >> them separately. >> > >> > ... you are ignoring the fact that there exist cases where this is >> > impossible. >> >> Seriously, it's bad practice, don't do it. But don't mind me, go ahead >> and do it, if it's so "impossible" to do otherwise... > > Check out any one tree style built GCC+newlib rpm, Should be fine, only one Version: tag. > check out autogen + libopts (currently under review). Couldn't find that one. Pointer? -- Rex From Axel.Thimm at ATrpms.net Tue Jul 25 20:52:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 22:52:53 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153859186.2769.478.camel@localhost.localdomain> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153859186.2769.478.camel@localhost.localdomain> Message-ID: <20060725205253.GO1164@neu.nirvana> On Tue, Jul 25, 2006 at 11:26:26PM +0300, Ville Skytt? wrote: > Too bad it doesn't work very well, for "BuildArch: noarch" packages, > %{buildroot} ends up ending with -noarch here as expected, but > $RPM_BUILD_ROOT ends with -x86_64. Hm, I tried it w/o the patch (e.g. no default %buildroot) and the effects are even funnier: + echo '%{buildroot}' %{buildroot} + echo + exit 0 %{buildroot} becomes literally "%{buildroot}" and $RPM_BUILD_ROOT becomes "". So there is finally a difference between the two beyond style - usually $RPM_BUILD_ROOT is defined as %{buildroot} automagically within rpm upon creation of the scriplets to run for %prep and so on. But if a BuildRoot: tag is missing no such code is emitted and the $RPM_BUILD_ROOT environment variable is never instantiated. In that sense it is safer to use %{buildroot} all over as install ... %{buildroot}%{_bindir} resolves to a relative non-existant folder while $RPM_BUILD_ROOT%{_bindir} resolves to /usr/bin on missing BuildRoots. But to come back to Ville's observation: It means that one shouldn't mix %{buildroot} and $RPM_BUILD_ROOT in the same specfile, which hopefully noone is doing. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Jul 25 20:48:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 15:48:17 -0500 Subject: [Fedora-packaging] Re: Re: BuildRoot References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153859186.2769.478.camel@localhost.localdomain> Message-ID: Ville Skytt? wrote: > The above looks ok on first sight, and would look even better if > %buildroot was defined as > %{_tmppath}/%{name}-%{version}-%{release}-%{_target_cpu} which I'd > assume to take care of the multiarch simultaneous build issue and not > really obfuscate things at all. > > Too bad it doesn't work very well, for "BuildArch: noarch" packages, > %{buildroot} ends up ending with -noarch here as expected, but > $RPM_BUILD_ROOT ends with -x86_64. And for example many scripts > in /usr/lib/rpm operate on $RPM_BUILD_ROOT. On the other hand, explicit > --target to rpmbuild affects both consistently, so I suppose BuildArch > (not limited to noarch) in specfiles kicks in too late to affect > $RPM_BUILD_ROOT. Reproducer: try rpmbuild -bp with this specfile and > the above %buildroot definition in macros somewhere: > > --- > Name: foo ... > BuildArch: noarch > %description > %prep > echo %{buildroot} > echo $RPM_BUILD_ROOT > --- > > /var/tmp/foo-1-1-noarch > /var/tmp/foo-1-1-x86_64 Yuck, though, in practice mostly harmless, since we enforce the consistent use (ie, not mixing) of either %buildroot or $RPM_BUILD_ROOT. -- Rex From nicolas.mailhot at laposte.net Tue Jul 25 21:01:37 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 25 Jul 2006 23:01:37 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725205253.GO1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153859186.2769.478.camel@localhost.localdomain> <20060725205253.GO1164@neu.nirvana> Message-ID: <1153861297.2813.5.camel@rousalka.dyndns.org> Le mardi 25 juillet 2006 ? 22:52 +0200, Axel Thimm a ?crit : > But to come back to Ville's observation: It means that one shouldn't > mix %{buildroot} and $RPM_BUILD_ROOT in the same specfile, which > hopefully noone is doing. This part is already in the guidelines but you're the first to find a reason why one is better/safer than the other. IMHO that's reason enough to make %{buildroot} mandatory in Fedora specs (will simplify the guidelines too). Hope the packaging dark cabinet is reading this. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Tue Jul 25 21:13:58 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 26 Jul 2006 00:13:58 +0300 Subject: [Fedora-packaging] Re: Re: BuildRoot In-Reply-To: References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153859186.2769.478.camel@localhost.localdomain> Message-ID: <1153862039.2769.486.camel@localhost.localdomain> On Tue, 2006-07-25 at 15:48 -0500, Rex Dieter wrote: > Ville Skytt? wrote: > > > > /var/tmp/foo-1-1-noarch > > /var/tmp/foo-1-1-x86_64 > > Yuck, though, in practice mostly harmless, since we enforce the consistent > use (ie, not mixing) of either %buildroot or $RPM_BUILD_ROOT. I don't think it's harmless. Stuff in /usr/lib/rpm uses $RPM_BUILD_ROOT no matter what one does inside the specfile. So if one installs into and otherwise deals with %{buildroot} inside the spec, chances are that the scripts in /usr/lib/rpm will not operate on the expected build root. And if one uses $RPM_BUILD_ROOT everywhere in the specfile, things will probably work just fine but having %{_target_cpu} in the buildroot definition is useless for some cases. From toshio at tiki-lounge.com Tue Jul 25 21:22:50 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 25 Jul 2006 14:22:50 -0700 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153861297.2813.5.camel@rousalka.dyndns.org> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153859186.2769.478.camel@localhost.localdomain> <20060725205253.GO1164@neu.nirvana> <1153861297.2813.5.camel@rousalka.dyndns.org> Message-ID: <1153862571.3010.17.camel@localhost> On Tue, 2006-07-25 at 23:01 +0200, Nicolas Mailhot wrote: > Le mardi 25 juillet 2006 ? 22:52 +0200, Axel Thimm a ?crit : > > > But to come back to Ville's observation: It means that one shouldn't > > mix %{buildroot} and $RPM_BUILD_ROOT in the same specfile, which > > hopefully noone is doing. > > This part is already in the guidelines but you're the first to find a > reason why one is better/safer than the other. > > IMHO that's reason enough to make %{buildroot} mandatory in Fedora specs > (will simplify the guidelines too). Hope the packaging dark cabinet is > reading this. I'm reading but having a hard time caring at this point :-) Seriously, if we move the buildroot definition into rpm's config then it would make sense to change to %{buildroot}. Under current guidelines where the buildroot must be defined in every spec file, I don't think the issue is very big. BTW, is this property of undefined macros documented somewhere or is it something that can change at the whim of the rpm maintainer? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Tue Jul 25 21:29:40 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 26 Jul 2006 00:29:40 +0300 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <20060725205253.GO1164@neu.nirvana> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153859186.2769.478.camel@localhost.localdomain> <20060725205253.GO1164@neu.nirvana> Message-ID: <1153862980.2769.504.camel@localhost.localdomain> On Tue, 2006-07-25 at 22:52 +0200, Axel Thimm wrote: > In that sense it is safer to use %{buildroot} all over as install > ... %{buildroot}%{_bindir} resolves to a relative non-existant folder > while $RPM_BUILD_ROOT%{_bindir} resolves to /usr/bin on missing > BuildRoots. Ack. But: On Tue, 2006-07-25 at 23:01 +0200, Nicolas Mailhot wrote: > IMHO that's reason enough to make %{buildroot} mandatory in Fedora specs > (will simplify the guidelines too). Hope the packaging dark cabinet is > reading this. Note that if one uses %{buildroot} instead of $RPM_BUILD_ROOT (no matter how consistently), the end result is a potentially broken mixture due to https://www.redhat.com/archives/fedora-packaging/2006-July/msg00306.html , so one could come to the opposite conclusion, too. Oh well, pick your poison. Maybe it's best to just report a bug against rpm, not set %{_target_cpu} in any recommended/defined buildroots, and to shrug off for now the corner case concerning simultaneous builds of the same package by the same user for different archs. Or just shrug it off ;) From Axel.Thimm at ATrpms.net Tue Jul 25 21:31:29 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 23:31:29 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153689220.13330.51.camel@cutter> References: <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> Message-ID: <20060725213129.GR1164@neu.nirvana> On Sun, Jul 23, 2006 at 05:13:40PM -0400, seth vidal wrote: > On Sun, 2006-07-23 at 23:03 +0200, Axel Thimm wrote: > > On Sun, Jul 23, 2006 at 04:38:59PM -0400, seth vidal wrote: > > > On Sun, 2006-07-23 at 22:19 +0200, Axel Thimm wrote: > > > > On Sun, Jul 23, 2006 at 10:32:06PM +0300, Ville Skytt? wrote: > > > > > > rpm -U/-i will nuke or overwrite kernel modules of the running > > > > > > kernel in a uname-r-less scheme. > > > > > But I thought it was already stated that we don't care about rpm used on > > > the cli to handle these sorts of things. That we've assumed we're > > > operating at a level above rpm for constructing the transaction set. > > > > A scheme were two independent EVRs are merged together into one is > > broken and banning the tool that exhibits it and pasting it away from > > others isn't the solution. kmod-foo-1-a just has nothing to do with > > kmod-foo--b (in the simplified notation). > > okay. I can take that. > > Here's my only complaint and it is a complaint for all sides equally: > > I would like one and final standard decided on BEFORE FC6 is released. > We need to get the code for yum complete so we can stop messing around > with this stuff. > > At this point I'm in favor of whatever gets it done. Would you be interested in adding support for the kmdl scheme to yum (or a plugin) *before* a decision is made? I'm suggesting this because kernel module handling is for many in this list too abstract to discuss on paper and a live demonstration using yum and kmdls would certainly help moving on on this subject here. A bash shell script doing it is 9 lines, so I hope for you it would be almost trivial to pluginize. Even if the decision can't be made in time for FC6 (which effectively would mean to keep the current scheme) it would not be a waste of time as it is already in use at ATrpms, and many users want to see yum auto-coinstalling them upon new kernels. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jul 25 21:36:50 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 23:36:50 +0200 Subject: [Fedora-packaging] Re: BuildRoot In-Reply-To: <1153862571.3010.17.camel@localhost> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153859186.2769.478.camel@localhost.localdomain> <20060725205253.GO1164@neu.nirvana> <1153861297.2813.5.camel@rousalka.dyndns.org> <1153862571.3010.17.camel@localhost> Message-ID: <20060725213650.GS1164@neu.nirvana> On Tue, Jul 25, 2006 at 02:22:50PM -0700, Toshio Kuratomi wrote: > BTW, is this property of undefined macros documented somewhere or is it > something that can change at the whim of the rpm maintainer? You mean that %{notdefined} resolves to "%{notdefined}"? Quite a lot isn't really specified with rpm, jbj himself claims that rpm has no grammar. Anything that is rarely used can change w/o notice. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Tue Jul 25 22:00:35 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 25 Jul 2006 15:00:35 -0700 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060725213129.GR1164@neu.nirvana> References: <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> Message-ID: <1153864835.3010.31.camel@localhost> Apologies for posting into the wrong subthread of this monster, I already deleted the relevant mail. If one of the major issues with the current kmod spec is that neither rpm -U nor rpm -i work correctly, shouldn't that be corrected? If the module could install into something like this: /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko instead of: /lib/modules/KERNELVER/extra/MODULE/MODULE.ko wouldn't that bring the behaviour of kmods inline with that of the kernel? (Use rpm -i for normal operations, rpm -U if you don't believe in Murphy). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Tue Jul 25 22:00:35 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 25 Jul 2006 15:00:35 -0700 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060725213129.GR1164@neu.nirvana> References: <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> Message-ID: <1153864835.3010.30.camel@localhost> Apologies for posting into the wrong subthread of this monster, I already deleted the relevant mail. If one of the major issues with the current kmod spec is that neither rpm -U nor rpm -i work correctly, shouldn't that be corrected? If the module could install into something like this: /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko instead of: /lib/modules/KERNELVER/extra/MODULE/MODULE.ko wouldn't that bring the behaviour of kmods inline with that of the kernel? (Use rpm -i for normal operations, rpm -U if you don't believe in Murphy). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue Jul 25 22:22:06 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 26 Jul 2006 00:22:06 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153864835.3010.31.camel@localhost> References: <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> Message-ID: <20060725222206.GA27815@neu.nirvana> On Tue, Jul 25, 2006 at 03:00:35PM -0700, Toshio Kuratomi wrote: > Apologies for posting into the wrong subthread of this monster, I > already deleted the relevant mail. > > If one of the major issues with the current kmod spec is that neither > rpm -U nor rpm -i work correctly, shouldn't that be corrected? If the > module could install into something like this: > /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko > > instead of: > /lib/modules/KERNELVER/extra/MODULE/MODULE.ko > > wouldn't that bring the behaviour of kmods inline with that of the > kernel? (Use rpm -i for normal operations, rpm -U if you don't believe > in Murphy). The issue is with the package's name and evr, not its contents. And there are no "normal" operations possible unless you use uname-r-in-name: o non-kernel/non-kernel-module packages: Always UPGRADE (e.g. remove the old packages): rpm -U o kernel packages: (co)INSTALL, don't remove the current kernel, possibly also not a couple more kernels: rpm -i [1] o kernel-module packages: Do replace kernel modules for the same kernel, but don't touch kernel modules of other kernels: So it's a mixture of simultaneous UPGRADE/INSTALL operations. The latter is also the problem. Given this two-dimensional evr-space where verticals and horizontals are to be handled with upgrades and (co)install operations you get into trouble with trying to project the space onto one dimension. You get the different operations needed mangled. The only way out is to defuse one dimension, e.g. remove it from rpm's line of sight, and that is the kernel's version. Moving the uname-r into the package's name makes the packages behave properly both within one kernel and across different kernels with rpm -U, e.g. kmdls are to be handled like typical packages, for example (omitting releases, only versions for simplicity): rpm -Uhv foo-kmdl-2.6.20-2.i686.rpm will install kernel module foo in version 2 for kernel 2.6.20 w/o affecting kernel modules for kernels 2.6.19 or 2.6.21, but still replacing possibly previous versions of foo (say version 1) for kernel 2.6.20. That's exactly the desired functionality on rpm CLI level already! And all depsolvers already handle the part with upgrading the kmdls within the kernel. What they need to be tought to make the picture perfect is to install matching kmdls upon kernel upgrades. [1] With yum's installn it's not quite true, there is a delayed rpm -e lingering around waiting for enough kernels to gather to remove the oldest. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Wed Jul 26 03:37:28 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 26 Jul 2006 05:37:28 +0200 Subject: [Fedora-packaging] Re: Re: BuildRoot In-Reply-To: References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> <1153849045.22104.316.camel@mccallum.corsepiu.local> <44C65782.6080307@math.unl.edu> <1153851499.22104.323.camel@mccallum.corsepiu.local> <44C66264.60106@math.unl.edu> <1153853253.22104.339.camel@mccallum.corsepiu.local> Message-ID: <1153885048.22104.364.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 15:47 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > > On Tue, 2006-07-25 at 13:26 -0500, Rex Dieter wrote: > >> Ralf Corsepius wrote: > >> > On Tue, 2006-07-25 at 12:40 -0500, Rex Dieter wrote: > >> >> Ralf Corsepius wrote: > >> >>> On Tue, 2006-07-25 at 18:41 +0200, Axel Thimm wrote: > >> >>> > >> >>>> Let's file it under hear-say then and move on. > >> >>> No comment > >> >>> > >> >>> c.f. below and note the output of the "echos". > >> >> I think it's safe to just say this is an example of bad rpm practice. > >> >> If you really want/need two different sources and versions, package > >> >> them separately. > >> > > >> > ... you are ignoring the fact that there exist cases where this is > >> > impossible. > >> > >> Seriously, it's bad practice, don't do it. But don't mind me, go ahead > >> and do it, if it's so "impossible" to do otherwise... > > > > Check out any one tree style built GCC+newlib rpm, > > Should be fine, only one > Version: > tag. What you say is equivalent to assigning GCC the version of an OS's libc rsp. vice versa. Pardon, but politeness prohibits to further comment on this. > > check out autogen + libopts (currently under review). > > Couldn't find that one. Pointer? currently under review == Review request in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197814 autogen-5.8.x ships with libopts-27.1.2.tar.gz integrated A proper way to build libopts would be to generate libopts-27.1.2*rpms and autogen-5.8.x*rpms from it. Ralf From rdieter at math.unl.edu Wed Jul 26 04:01:38 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 23:01:38 -0500 Subject: [Fedora-packaging] Re: Re: BuildRoot In-Reply-To: <1153885048.22104.364.camel@mccallum.corsepiu.local> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> <1153849045.22104.316.camel@mccallum.corsepiu.local> <44C65782.6080307@math.unl.edu> <1153851499.22104.323.camel@mccallum.corsepiu.local> <44C66264.60106@math.unl.edu> <1153853253.22104.339.camel@mccallum.corsepiu.local> <1153885048.22104.364.camel@mccallum.corsepiu.local> Message-ID: <44C6E922.6060400@math.unl.edu> Ralf Corsepius wrote: > On Tue, 2006-07-25 at 15:47 -0500, Rex Dieter wrote: >>> Check out any one tree style built GCC+newlib rpm, >> Should be fine, only one >> Version: >> tag. > What you say is equivalent to assigning GCC the version of an OS's libc > rsp. vice versa. > > Pardon, but politeness prohibits to further comment on this. > >>> check out autogen + libopts (currently under review). >> Couldn't find that one. Pointer? > currently under review == Review request in bugzilla: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197814 > > autogen-5.8.x ships with libopts-27.1.2.tar.gz integrated > A proper way to build libopts would be to generate > libopts-27.1.2*rpms and autogen-5.8.x*rpms from it. This discussion is digressing even further offtopic, but... IMO, the "proper way" would be to build bootstraps (gcc+newlib and autogen+libopts), then use those to build *separately* each of gcc,newlib and autogen,libopts. Then, no overloading of Version would be required. -- Rex From rc040203 at freenet.de Wed Jul 26 04:09:41 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 26 Jul 2006 06:09:41 +0200 Subject: [Fedora-packaging] Re: Re: BuildRoot In-Reply-To: <44C6E922.6060400@math.unl.edu> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> <1153849045.22104.316.camel@mccallum.corsepiu.local> <44C65782.6080307@math.unl.edu> <1153851499.22104.323.camel@mccallum.corsepiu.local> <44C66264.60106@math.unl.edu> <1153853253.22104.339.camel@mccallum.corsepiu.local> <1153885048.22104.364.camel@mccallum.corsepiu.local> <44C6E922.6060400@math.unl.edu> Message-ID: <1153886981.22104.374.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 23:01 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Tue, 2006-07-25 at 15:47 -0500, Rex Dieter wrote: > > >>> Check out any one tree style built GCC+newlib rpm, > >> Should be fine, only one > >> Version: > >> tag. > > What you say is equivalent to assigning GCC the version of an OS's libc > > rsp. vice versa. > > > > Pardon, but politeness prohibits to further comment on this. > > > >>> check out autogen + libopts (currently under review). > >> Couldn't find that one. Pointer? > > currently under review == Review request in bugzilla: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197814 > > > > autogen-5.8.x ships with libopts-27.1.2.tar.gz integrated > > A proper way to build libopts would be to generate > > libopts-27.1.2*rpms and autogen-5.8.x*rpms from it. > > This discussion is digressing even further offtopic, but... > IMO, the "proper way" would be to build bootstraps (gcc+newlib and > autogen+libopts), then use those to build *separately* each of > gcc,newlib and autogen,libopts. So you are demanding to abandon features, due to rpm defects? BTW: The work-around is pretty easy: Don't use %version in rpm specs, but hard-code them or redirect them to other %defines. Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 26 09:23:16 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 26 Jul 2006 11:23:16 +0200 Subject: [Fedora-packaging] Re: Re: BuildRoot In-Reply-To: <1153862039.2769.486.camel@localhost.localdomain> References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153859186.2769.478.camel@localhost.localdomain> <1153862039.2769.486.camel@localhost.localdomain> Message-ID: <20060726112316.080bbb89@python2> Ville Skytt? wrote : > On Tue, 2006-07-25 at 15:48 -0500, Rex Dieter wrote: > > Ville Skytt? wrote: > > > > > > /var/tmp/foo-1-1-noarch > > > /var/tmp/foo-1-1-x86_64 > > > > Yuck, though, in practice mostly harmless, since we enforce the consistent > > use (ie, not mixing) of either %buildroot or $RPM_BUILD_ROOT. > > I don't think it's harmless. Stuff in /usr/lib/rpm uses $RPM_BUILD_ROOT > no matter what one does inside the specfile. > > So if one installs into and otherwise deals with %{buildroot} inside the > spec, chances are that the scripts in /usr/lib/rpm will not operate on > the expected build root. > > And if one uses $RPM_BUILD_ROOT everywhere in the specfile, things will > probably work just fine but having %{_target_cpu} in the buildroot > definition is useless for some cases. Things are getting fun and interesting now! :-) What I really fail to understand is how when you don't specify a BuildRoot: in a spec file, $RPM_BUILD_ROOT ends up empty, but when you define %buildroot in a macro, it gets a value which is different! The easiest possible explanation here would be that %buildroot gets expanded multiple times, one being what we see set as $RPM_BUILD_ROOT and another being what the "echo %{buildroot}" in the spec file shows. I've tried to dig a little deeper, as this might be easy to fix (although I doubt it), but am completely lost in the macros right now... might be a simple matter of having the arch globally set from the spec file value _before_ the buildroot gets globally set for the first time. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.91 (FC6 Test2) - Linux kernel 2.6.17-1.2445.fc6 Load : 0.14 0.18 0.15 From rdieter at math.unl.edu Wed Jul 26 11:55:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jul 2006 06:55:08 -0500 Subject: [Fedora-packaging] Re: Re: Re: BuildRoot References: <20060725120720.34b753f4@python2> <20060725144610.GG1164@neu.nirvana> <1153842903.22104.288.camel@mccallum.corsepiu.local> <20060725161639.GJ1164@neu.nirvana> <1153844968.22104.301.camel@mccallum.corsepiu.local> <20060725164138.GM1164@neu.nirvana> <1153849045.22104.316.camel@mccallum.corsepiu.local> <44C65782.6080307@math.unl.edu> <1153851499.22104.323.camel@mccallum.corsepiu.local> <44C66264.60106@math.unl.edu> <1153853253.22104.339.camel@mccallum.corsepiu.local> <1153885048.22104.364.camel@mccallum.corsepiu.local> <44C6E922.6060400@math.unl.edu> <1153886981.22104.374.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Tue, 2006-07-25 at 23:01 -0500, Rex Dieter wrote: >> This discussion is digressing even further offtopic, but... >> IMO, the "proper way" would be to build bootstraps (gcc+newlib and >> autogen+libopts), then use those to build *separately* each of >> gcc,newlib and autogen,libopts. > So you are demanding to abandon features, due to rpm defects? I'm only *suggesting* an alternative, and IMO better/safer, way of packaging these items to avoid the pitfalls associated with building multiple items and possibly using multiple Version: tags inside a single specfile. By all means ignore it, if you deem it beneath you to consider. -- Rex From jjneely at ncsu.edu Wed Jul 26 14:33:05 2006 From: jjneely at ncsu.edu (Jack Neely) Date: Wed, 26 Jul 2006 10:33:05 -0400 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <20060725213129.GR1164@neu.nirvana> References: <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> Message-ID: <20060726143305.GQ5520@anduril.unity.ncsu.edu> > > Would you be interested in adding support for the kmdl scheme to yum > (or a plugin) *before* a decision is made? > > I'm suggesting this because kernel module handling is for many in this > list too abstract to discuss on paper and a live demonstration using > yum and kmdls would certainly help moving on on this subject here. A > bash shell script doing it is 9 lines, so I hope for you it would be > almost trivial to pluginize. > > Even if the decision can't be made in time for FC6 (which effectively > would mean to keep the current scheme) it would not be a waste of time > as it is already in use at ATrpms, and many users want to see yum > auto-coinstalling them upon new kernels. > -- > Axel.Thimm at ATrpms.net If you'd like to contribute a Yum plugin or patches to one of the existing 2 they are in the yum-utils project. They're not hard to write and there are a handful of good examples now. My time is going toward the current proposal. Panu does have a plugin in yum-utils to support a uname-r in name scheme for kernel modules. Looks like it needs to be updated a bit, but perhaps that could be a starting point for your work. Jack > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From chris.stone at gmail.com Wed Jul 26 19:04:54 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 26 Jul 2006 12:04:54 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: <1153851298.2769.396.camel@localhost.localdomain> References: <1153851298.2769.396.camel@localhost.localdomain> Message-ID: On 7/25/06, Ville Skytt? wrote: > On Mon, 2006-07-24 at 18:26 -0700, Christopher Stone wrote: > > > Well Ville made a bunch of changes to the spec file template so that > > it doesn't have to use macros. > > That's just a "food for thought" patch attached to Bugzilla (#198706) > for comments, not committed anywhere yet. > > > It essentially complicates the default > > spec template. The reason for adding all of this additional > > complexity is to support deprecated distributions. > > Such as FC5 as it stands now? Shrug. FC5 should get the new php-pear that is in testing now. I think it is good enough to be added to updates. > The initial suggested template hardcoded /usr/bin/pear scriptlet > dependencies, but actually used %{__pear} in them. This is apparently > done to work around the case where even "make srpm" would fail if > %{__pear} is not defined (which would very likely result in eg. the > current FE buildsys not being able to build those packages for *any* > distro version without changes, because %{__pear} was not conditionally > defined in the specfile). But the above workaround is broken > everywhere, including when %{__pear} is defined, and makes the whole > %{__pear} macro questionable. Actually there was no reason at all why I used /usr/bin/pear other than I did not test it under mock and was being "safe than sorry". If %{__pear} works under mock, then I would add it back and remove the /usr/bin/pear BR. > > There are several ways to fix the problem consistently. As far as I can > tell, all of them include either conditionally defining %{__pear} in the > specfile and using it everywhere, or not using it at all and reverting > to %{_bindir}/pear or /usr/bin/pear instead and using that everywhere. > > In addition to the above, it would be good to 1) buildrequire something > that defines rest of the used macros, or 2) conditionally define them in > the specfile, or 3) forget about the rest of the macros and use > something like the "food for thought" approach. Until the macros are in > FC5, 1) (or not adding the BR) is a blocker for inclusion of the > template in rpmdevtools or a blocker for the new release of rpmdevtools > for FC5. 2) and 3) don't block anything, and would have the additional > benefit of working with earlier distro versions. The spec file template I submitted should not be added until the macros are in the php-pear package which hopefully should happen soon. > > The package.xml issue mentioned in #198706 comment 3 needs some > attention too, and the comment contains a suggested fix. > > I'm not going to spend any more time working on this. Please just > provide patches you would like to see applied over the > spectemplate-php-pear.spec and newrpmspec in rpmdevtools CVS > ("fedora-rpmdevtools" in the "fedora" (not extras) CVS root) to bug > 198706 when you've figured out what it will be. > > > Also Ville insists on their being a %build section for an unknown > > reason. > > I did provide a reason, you seem to choose to ignore it. Well you keep referencing a bug number with your argument and the comments made in the bug you refer to seem to suggest my point of view rather than yours. Basically the bug reporter simply did not know what he was doing. So this bug that you refer to basically invalidates your claim that there is a problem with not adding %build. So you provide some reason, then invalidate this reason with a bug number and therefore you provide an unknown or null or void or canceled out reason. Kind of like when matter collides with anti-matter... Basically none of this matters because we need the new php-pear in updates first. Then we can debate about the spec file changes that need to be made. From toshio at tiki-lounge.com Wed Jul 26 19:34:58 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 26 Jul 2006 12:34:58 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: References: <1153851298.2769.396.camel@localhost.localdomain> Message-ID: <1153942498.3004.36.camel@localhost> On Wed, 2006-07-26 at 12:04 -0700, Christopher Stone wrote: > On 7/25/06, Ville Skytt? wrote: > > On Mon, 2006-07-24 at 18:26 -0700, Christopher Stone wrote: > > > Also Ville insists on their being a %build section for an unknown > > > reason. > > > > I did provide a reason, you seem to choose to ignore it. > > Well you keep referencing a bug number with your argument and the > comments made in the bug you refer to seem to suggest my point of view > rather than yours. Basically the bug reporter simply did not know > what he was doing. So this bug that you refer to basically > invalidates your claim that there is a problem with not adding %build. > So you provide some reason, then invalidate this reason with a bug > number and therefore you provide an unknown or null or void or > canceled out reason. Kind of like when matter collides with > anti-matter... Bug#192422 is showing that specs without %build can trigger unexpected behaviour. The bug reporter did know what he was doing, he just didn't know that rpm had a bug in it that prevented it from working as expected. So it's better to anticipate that there might be other unexpected things when shipping without %build (either there now or added in the future when the rpm maintainer decides: debuginfos do it this way, I might as well make feature X do it that way as well) rather than letting everything work for the trivial cases we're dealing with now and then suddenly expose another bug somewhere down the road. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Wed Jul 26 19:45:05 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 26 Jul 2006 12:45:05 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: <1153942498.3004.36.camel@localhost> References: <1153851298.2769.396.camel@localhost.localdomain> <1153942498.3004.36.camel@localhost> Message-ID: On 7/26/06, Toshio Kuratomi wrote: > On Wed, 2006-07-26 at 12:04 -0700, Christopher Stone wrote: > > On 7/25/06, Ville Skytt? wrote: > > > On Mon, 2006-07-24 at 18:26 -0700, Christopher Stone wrote: > > > > Also Ville insists on their being a %build section for an unknown > > > > reason. > > > > > > I did provide a reason, you seem to choose to ignore it. > > > > Well you keep referencing a bug number with your argument and the > > comments made in the bug you refer to seem to suggest my point of view > > rather than yours. Basically the bug reporter simply did not know > > what he was doing. So this bug that you refer to basically > > invalidates your claim that there is a problem with not adding %build. > > So you provide some reason, then invalidate this reason with a bug > > number and therefore you provide an unknown or null or void or > > canceled out reason. Kind of like when matter collides with > > anti-matter... > > Bug#192422 is showing that specs without %build can trigger unexpected > behaviour. The bug reporter did know what he was doing, he just didn't > know that rpm had a bug in it that prevented it from working as > expected. No, bug #192422 is showing that without %build a debuginfo package will not be built. This is totally _expected_ behavior. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422#c11 > > So it's better to anticipate that there might be other unexpected things > when shipping without %build (either there now or added in the future > when the rpm maintainer decides: debuginfos do it this way, I might as > well make feature X do it that way as well) rather than letting > everything work for the trivial cases we're dealing with now and then > suddenly expose another bug somewhere down the road. You are working off the false premise that there is unexpected behavior in rpm. I am very highly doubtful that the rpm source code is so pathetically bad that no body really knows what might happen when certain things are added or removed from spec files. LOL. From toshio at tiki-lounge.com Wed Jul 26 20:13:22 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 26 Jul 2006 13:13:22 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: References: <1153851298.2769.396.camel@localhost.localdomain> <1153942498.3004.36.camel@localhost> Message-ID: <1153944802.3004.59.camel@localhost> On Wed, 2006-07-26 at 12:45 -0700, Christopher Stone wrote: > On 7/26/06, Toshio Kuratomi wrote: > > On Wed, 2006-07-26 at 12:04 -0700, Christopher Stone wrote: > > > On 7/25/06, Ville Skytt? wrote: > > > > On Mon, 2006-07-24 at 18:26 -0700, Christopher Stone wrote: > > > > > Also Ville insists on their being a %build section for an unknown > > > > > reason. > > > > > > > > I did provide a reason, you seem to choose to ignore it. > > > > > > Well you keep referencing a bug number with your argument and the > > > comments made in the bug you refer to seem to suggest my point of view > > > rather than yours. Basically the bug reporter simply did not know > > > what he was doing. So this bug that you refer to basically > > > invalidates your claim that there is a problem with not adding %build. > > > So you provide some reason, then invalidate this reason with a bug > > > number and therefore you provide an unknown or null or void or > > > canceled out reason. Kind of like when matter collides with > > > anti-matter... > > > > Bug#192422 is showing that specs without %build can trigger unexpected > > behaviour. The bug reporter did know what he was doing, he just didn't > > know that rpm had a bug in it that prevented it from working as > > expected. > > No, bug #192422 is showing that without %build a debuginfo package > will not be built. This is totally _expected_ behavior. > > See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422#c11 > Really? Where's the documentation? If php were to fail to process a section anytime I put extra spaces after my php tag " > > > So it's better to anticipate that there might be other unexpected things > > when shipping without %build (either there now or added in the future > > when the rpm maintainer decides: debuginfos do it this way, I might as > > well make feature X do it that way as well) rather than letting > > everything work for the trivial cases we're dealing with now and then > > suddenly expose another bug somewhere down the road. > > You are working off the false premise that there is unexpected > behavior in rpm. I am very highly doubtful that the rpm source code > is so pathetically bad that no body really knows what might happen > when certain things are added or removed from spec files. LOL. You are working off the false premise that it matters what the code says. If a program SegFaults, it's because the code says, please violate memory here. That doesn't mean that the user should expect the program to crash. jbj admits the code to create debuginfos is hacky. However, he doesn't propose that someone submit a patch to fix it; instead he closes it WONTFIX. rpm is littered with similar issues where the code doesn't do what the end-user expects. Attempting to stay away from issues that could trigger them is just good practice. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Wed Jul 26 21:54:26 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 26 Jul 2006 14:54:26 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: <1153944802.3004.59.camel@localhost> References: <1153851298.2769.396.camel@localhost.localdomain> <1153942498.3004.36.camel@localhost> <1153944802.3004.59.camel@localhost> Message-ID: On 7/26/06, Toshio Kuratomi wrote: > On Wed, 2006-07-26 at 12:45 -0700, Christopher Stone wrote: > > On 7/26/06, Toshio Kuratomi wrote: > > > On Wed, 2006-07-26 at 12:04 -0700, Christopher Stone wrote: > > > > On 7/25/06, Ville Skytt? wrote: > > > > > On Mon, 2006-07-24 at 18:26 -0700, Christopher Stone wrote: > > > > > > Also Ville insists on their being a %build section for an unknown > > > > > > reason. > > > > > > > > > > I did provide a reason, you seem to choose to ignore it. > > > > > > > > Well you keep referencing a bug number with your argument and the > > > > comments made in the bug you refer to seem to suggest my point of view > > > > rather than yours. Basically the bug reporter simply did not know > > > > what he was doing. So this bug that you refer to basically > > > > invalidates your claim that there is a problem with not adding %build. > > > > So you provide some reason, then invalidate this reason with a bug > > > > number and therefore you provide an unknown or null or void or > > > > canceled out reason. Kind of like when matter collides with > > > > anti-matter... > > > > > > Bug#192422 is showing that specs without %build can trigger unexpected > > > behaviour. The bug reporter did know what he was doing, he just didn't > > > know that rpm had a bug in it that prevented it from working as > > > expected. > > > > No, bug #192422 is showing that without %build a debuginfo package > > will not be built. This is totally _expected_ behavior. > > > > See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422#c11 > > > Really? Where's the documentation? The documentation is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422#c3 So it seems that the way the redhat-rpm-config package is set up, you must have a %build section to generate a debuginfo package. Since all php-pear packages are noarch and do not produce binaries, we do not need debuginfo packages, and therefore do not need a %build section. Secondly, it has been indicated that this design is hacky. Perhaps a bug filed against redhat-rpm-config can be filed to try and fix this hack in a better way. > > If php were to fail to process a section anytime I put extra spaces > after my php tag " php maintainer closed the bug saying, "Because of the way we coded php, > that's the way it works" would it then be expected behaviour? In php if you end your script file with "?> " (ie, you have a space after the >) then header information will be printed out and you will not be able to change the header tags after this point. This is expected behavior. In the same case as we have, the way redhat-rpm-config is set up, it is expected behavior that omitting %build will omit a debuginfo rpm. If this needs to be fixed then I would suggest filing a bug against redhat-rpm-config, not rpm. > > > > > > > So it's better to anticipate that there might be other unexpected things > > > when shipping without %build (either there now or added in the future > > > when the rpm maintainer decides: debuginfos do it this way, I might as > > > well make feature X do it that way as well) rather than letting > > > everything work for the trivial cases we're dealing with now and then > > > suddenly expose another bug somewhere down the road. > > > > You are working off the false premise that there is unexpected > > behavior in rpm. I am very highly doubtful that the rpm source code > > is so pathetically bad that no body really knows what might happen > > when certain things are added or removed from spec files. LOL. > > You are working off the false premise that it matters what the code > says. If a program SegFaults, it's because the code says, please > violate memory here. That doesn't mean that the user should expect the > program to crash. > > jbj admits the code to create debuginfos is hacky. However, he doesn't > propose that someone submit a patch to fix it; instead he closes it > WONTFIX. rpm is littered with similar issues where the code doesn't do > what the end-user expects. Attempting to stay away from issues that > could trigger them is just good practice. I think jbj is saying that it is not an rpm problem, it is a redhat-rpm-config problem. From toshio at tiki-lounge.com Wed Jul 26 22:28:40 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 26 Jul 2006 15:28:40 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: References: <1153851298.2769.396.camel@localhost.localdomain> <1153942498.3004.36.camel@localhost> <1153944802.3004.59.camel@localhost> Message-ID: <1153952920.27624.14.camel@localhost> On Wed, 2006-07-26 at 14:54 -0700, Christopher Stone wrote: > The documentation is here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422#c3 > That's not documentation. That's a documented bug. > So it seems that the way the redhat-rpm-config package is set up, you > must have a %build section to generate a debuginfo package. Since all > php-pear packages are noarch and do not produce binaries, we do not > need debuginfo packages, and therefore do not need a %build section. > Of course. No one has said that the bug bears on the php guidelines in this manner. It bears on it as an example of the hackiness of rpm (or in this case the rpm system we are using to package Fedora, which includes rpm, redhat-rpm-config, etc). > Secondly, it has been indicated that this design is hacky. Perhaps a > bug filed against redhat-rpm-config can be filed to try and fix this > hack in a better way. > Sure. Ralf, do you want to file that bug since jbj didn't have the courtesy to retarget your original one? >> If php were to fail to process a section anytime I put extra spaces >> after my php tag "> php maintainer closed the bug saying, "Because of the way we coded php, >> that's the way it works" would it then be expected behaviour? > In php if you end your script file with "?> " (ie, you have a space > after the >) then header information will be printed out and you will > not be able to change the header tags after this point. This is > expected behavior. In the same case as we have, the way > redhat-rpm-config is set up, it is expected behavior that omitting > %build will omit a debuginfo rpm. If this needs to be fixed then I > would suggest filing a bug against redhat-rpm-config, not rpm. You're off on a tangent. Read again what I wrote -- it's not about a feature that's in php (well, actually a feature of the web server) "?> ", it's about a hypothetical bug discovery process involving " From chris.stone at gmail.com Wed Jul 26 22:32:52 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 26 Jul 2006 15:32:52 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: <1153952920.27624.14.camel@localhost> References: <1153851298.2769.396.camel@localhost.localdomain> <1153942498.3004.36.camel@localhost> <1153944802.3004.59.camel@localhost> <1153952920.27624.14.camel@localhost> Message-ID: On 7/26/06, Toshio Kuratomi wrote: > Read again what I wrote -- it's not about a feature that's in php > (well, actually a feature of the web server) "?> ", it's about a > hypothetical bug discovery process involving " References: <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <20060726143305.GQ5520@anduril.unity.ncsu.edu> Message-ID: <20060726230719.GD16278@neu.nirvana> On Tue, Jul 25, 2006 at 11:31:29PM +0200, Axel Thimm wrote: > On Sun, Jul 23, 2006 at 05:13:40PM -0400, seth vidal wrote: > > On Sun, 2006-07-23 at 23:03 +0200, Axel Thimm wrote: > > > On Sun, Jul 23, 2006 at 04:38:59PM -0400, seth vidal wrote: > > > > On Sun, 2006-07-23 at 22:19 +0200, Axel Thimm wrote: > > > > > On Sun, Jul 23, 2006 at 10:32:06PM +0300, Ville Skytt? wrote: > > > > > > > rpm -U/-i will nuke or overwrite kernel modules of the running > > > > > > > kernel in a uname-r-less scheme. > > > > > > > But I thought it was already stated that we don't care about > > > > rpm used on the cli to handle these sorts of things. That > > > > we've assumed we're operating at a level above rpm for > > > > constructing the transaction set. > > > > > > A scheme were two independent EVRs are merged together into one > > > is broken and banning the tool that exhibits it and pasting it > > > away from others isn't the solution. kmod-foo-1-a just has > > > nothing to do with kmod-foo--b (in the simplified > > > notation). > > > > okay. I can take that. > > > > Here's my only complaint and it is a complaint for all sides > > equally: > > > > I would like one and final standard decided on BEFORE FC6 is > > released. We need to get the code for yum complete so we can stop > > messing around with this stuff. > > > > At this point I'm in favor of whatever gets it done. > > Would you be interested in adding support for the kmdl scheme to yum > (or a plugin) *before* a decision is made? > > I'm suggesting this because kernel module handling is for many in this > list too abstract to discuss on paper and a live demonstration using > yum and kmdls would certainly help moving on on this subject here. A > bash shell script doing it is 9 lines, so I hope for you it would be > almost trivial to pluginize. > > Even if the decision can't be made in time for FC6 (which effectively > would mean to keep the current scheme) it would not be a waste of time > as it is already in use at ATrpms, and many users want to see yum > auto-coinstalling them upon new kernels. On Wed, Jul 26, 2006 at 10:33:05AM -0400, Jack Neely wrote: > If you'd like to contribute a Yum plugin or patches to one of the > existing 2 they are in the yum-utils project. They're not hard to > write and there are a handful of good examples now. My time is > going toward the current proposal. > > Panu does have a plugin in yum-utils to support a uname-r in name > scheme for kernel modules. Looks like it needs to be updated a bit, > but perhaps that could be a starting point for your work. Thanks, I looked it up and indeed writing a yum plugin for kmdls is trivial. I really like the design of the plugin/hook mechanism. So I managed to get a fully featured kmdl plugin under 100 python lines (actually 99 ;). It even has two modes of operation: yum update: Will update/coinstall kmdl of all old and new kernels yum install: Will only do something with kmdls if a kernel is asked to be installed (and only for that kernel) I differ between the two, because I don't want the user to be surprised with kernel module installations when he yum-installs openoffice :) It also supports asynced kernel/kernel-module repo arrival. When a kernel update appears it will be installed even when the kmdls aren't yet available/built. If on the next yum update the previously missing kmdls appear, they will get installed at that time. I'm attaching the file (kmdl.py) to this mail. Seth & Jack you have a look and if approved add it to yum/yum-util sources (whatever is more appropriate)? If you don't like it let me know what needs improvement. To atrpms-devel: Please test the kmdl.py by copying it to /usr/lib/yum-plugins/kmdl.py To fedora-packaging: Now we have full support on rpm and yum level for kmdls [*], and it's rather comprehendable and maintainable code. If we can get over the ugliness or uname-r-in-name we should really adopt that scheme. [*] apt has kmdl support from lua, but during apt's time-off I think it regressed, but it can be easily resurrected, it will also be a couple of lua lines. smart support for any kernel module scheme seems to be the toughest because it's plugin scheme is not well documented and it looks like it misses some important hooks. -- Axel.Thimm at ATrpms.net -------------- next part -------------- #! /usr/bin/python # -*- coding: utf-8 mode: python -*- # kmdl.py - plugin for handling kmdls # Copyright (C) 2006 A. Thimm # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. # # $Id$ import re import rpm from yum.plugins import TYPE_CORE from rpmUtils.miscutils import compareEVR requires_api_version = '2.2' plugin_type = (TYPE_CORE,) KERNELS=["kernel", "kernel-smp", "kernel-bigmem", "kernel-hugemem", "kernel-largesmp", "kernel-xen0", "kernel-xenU", "kernel-kdump", "kernel-xen"] def uname_r(name, version, release): if name == 'kernel': return "%s-%s" % (version, release) else: (dummy, flavour) = name.split('-') return "%s-%s%s" % (version, release, flavour) def kmdls(conduit): kmdls=[] for hdr in conduit.getRpmDB().getHdrList(): m=re.match('(.*)-kmdl-.*', hdr[rpm.RPMTAG_NAME]) if m: kmdls.append(m.group(1)) tsInfo=conduit.getTsInfo() for txmbr in tsInfo.getMembers(): m=re.match('(.*)-kmdl-.*', txmbr.name) if m and txmbr.ts_state in ('i', 'u'): kmdls.append(m.group(1)) return kmdls def old_kernels(conduit): kernels=[] for hdr in conduit.getRpmDB().getHdrList(): if hdr[rpm.RPMTAG_NAME] in KERNELS: kernels.append([uname_r(hdr[rpm.RPMTAG_NAME], hdr[rpm.RPMTAG_VERSION], hdr[rpm.RPMTAG_RELEASE]), hdr[rpm.RPMTAG_ARCH]]) return kernels def new_kernels(conduit): kernels=[] tsInfo=conduit.getTsInfo() for txmbr in tsInfo.getMembers(): if txmbr.name in KERNELS and txmbr.ts_state in ('i', 'u'): kernels.append([uname_r(txmbr.name, txmbr.version, txmbr.release), txmbr.arch]) return kernels def kmdl_install(conduit, kernels, kmdls): tsInfo = conduit.getTsInfo() for kernel in kernels: for kmdl in kmdls: pkgname="%s-kmdl-%s" % (kmdl, kernel[0]) pkgfound=None for pkg in conduit.getPackages(): if pkg.name == pkgname and pkg.arch == kernel[1]: if not pkgfound or compareEVR(pkg.returnEVR(), pkgfound.returnEVR()) == 1: pkgfound=pkg if pkgfound: print "Installing " + pkgfound.name (n, a, e, v, r) = pkgfound.pkgtup conduit.info(2, '---> Package %s.%s %s:%s-%s set to be %s' % (n, a, e, v, r, 'installed')) tsInfo.addInstall(pkgfound) def postresolve_hook(conduit): opts, commands = conduit.getCmdLine() if commands[0] == 'update': kernels = old_kernels(conduit) + new_kernels(conduit) elif commands[0] == 'install': kernels = new_kernels(conduit) else: return kmdl_install(conduit, kernels, kmdls(conduit)) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Wed Jul 26 23:11:50 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 26 Jul 2006 16:11:50 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: References: <1153851298.2769.396.camel@localhost.localdomain> <1153942498.3004.36.camel@localhost> <1153944802.3004.59.camel@localhost> <1153952920.27624.14.camel@localhost> Message-ID: <1153955510.27624.21.camel@localhost> On Wed, 2006-07-26 at 15:32 -0700, Christopher Stone wrote: > On 7/26/06, Toshio Kuratomi wrote: > > Read again what I wrote -- it's not about a feature that's in php > > (well, actually a feature of the web server) "?> ", it's about a > > hypothetical bug discovery process involving " > So should we change all php source files to use " fix php to accept " files to add a %build, or should we fix redhat-rpm-config? Yep. We fix redhat-rpm-config. Then the next time we run across something unexpected happens we break packages again. Then we fix it again. Then it breaks again..... We're supposed to be promoting good packaging practice here. If we know that something as simple as including %build in your spec is a way to isolate your package from some subset of problematic special cases, then we should do that. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Wed Jul 26 23:20:38 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 26 Jul 2006 16:20:38 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: <1153955510.27624.21.camel@localhost> References: <1153851298.2769.396.camel@localhost.localdomain> <1153942498.3004.36.camel@localhost> <1153944802.3004.59.camel@localhost> <1153952920.27624.14.camel@localhost> <1153955510.27624.21.camel@localhost> Message-ID: On 7/26/06, Toshio Kuratomi wrote: > On Wed, 2006-07-26 at 15:32 -0700, Christopher Stone wrote: > > On 7/26/06, Toshio Kuratomi wrote: > > > Read again what I wrote -- it's not about a feature that's in php > > > (well, actually a feature of the web server) "?> ", it's about a > > > hypothetical bug discovery process involving " > > > So should we change all php source files to use " > fix php to accept " > files to add a %build, or should we fix redhat-rpm-config? > > Yep. We fix redhat-rpm-config. Then the next time we run across > something unexpected happens we break packages again. Then we fix it > again. Then it breaks again..... > > We're supposed to be promoting good packaging practice here. If we know > that something as simple as including %build in your spec is a way to > isolate your package from some subset of problematic special cases, then > we should do that. Okay, so you are saying it is better to hide or mask problems rather than fix them? I'm sorry, but I disagree. Probably the reason things are so hacky as they are now is because we have been hiding problems rather than fixing them. From toshio at tiki-lounge.com Wed Jul 26 23:40:41 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 26 Jul 2006 16:40:41 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: References: <1153851298.2769.396.camel@localhost.localdomain> <1153942498.3004.36.camel@localhost> <1153944802.3004.59.camel@localhost> <1153952920.27624.14.camel@localhost> <1153955510.27624.21.camel@localhost> Message-ID: <1153957241.27624.29.camel@localhost> On Wed, 2006-07-26 at 16:20 -0700, Christopher Stone wrote: > On 7/26/06, Toshio Kuratomi wrote: > > On Wed, 2006-07-26 at 15:32 -0700, Christopher Stone wrote: > > > On 7/26/06, Toshio Kuratomi wrote: > > > > Read again what I wrote -- it's not about a feature that's in php > > > > (well, actually a feature of the web server) "?> ", it's about a > > > > hypothetical bug discovery process involving " > > > > > So should we change all php source files to use " > > fix php to accept " > > files to add a %build, or should we fix redhat-rpm-config? > > > > Yep. We fix redhat-rpm-config. Then the next time we run across > > something unexpected happens we break packages again. Then we fix it > > again. Then it breaks again..... > > > > We're supposed to be promoting good packaging practice here. If we know > > that something as simple as including %build in your spec is a way to > > isolate your package from some subset of problematic special cases, then > > we should do that. > > Okay, so you are saying it is better to hide or mask problems rather > than fix them? Nope. We should try not to purposefully stick our hand in any fires. If we find a problem, it should be fixed, but promoting practices that we know risk triggering bugs when there are simple, straightforward, and clean ways to code it instead is just good sense. > I'm sorry, but I disagree. Probably the reason things > are so hacky as they are now is because we have been hiding problems > rather than fixing them. Nah. They're hacky because bugzilla allows jbj to close rpm bugs WONTFIX :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Wed Jul 26 23:50:56 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 26 Jul 2006 16:50:56 -0700 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: <1153957241.27624.29.camel@localhost> References: <1153942498.3004.36.camel@localhost> <1153944802.3004.59.camel@localhost> <1153952920.27624.14.camel@localhost> <1153955510.27624.21.camel@localhost> <1153957241.27624.29.camel@localhost> Message-ID: On 7/26/06, Toshio Kuratomi wrote: > Nope. We should try not to purposefully stick our hand in any fires. > If we find a problem, it should be fixed, but promoting practices that > we know risk triggering bugs when there are simple, straightforward, and > clean ways to code it instead is just good sense. I don't see this as sticking a hand in a fire. It is simply the fact that removing %build does not affect php-pear packages, there is no reason to add it. If not adding it causes some problem with the php-pear packages, then this should be identified. So far no one has identified such problem. We should not try to do preemptive maintenance on our spec files and add a bunch of extra cruft just because one problem occurred in a package that has binaries. If there is a problem with binary packages not using %build, then this should be fixed. You can patch this spec file temporarily with a %build until the problem is fixed, but don't start imposing standards on other spec files that do not have this issue. Until a problem is identified with php-pear packages, no %build should be added. If a problem is identified, then the problem should be noted as a bug and then we can add %build to the spec files. There has not been any indication as far as I can see that not including %build is going to cause unpredictable results in any way other than not building a debuginfo package which is not required for php-pear packages anyway. From Christian.Iseli at licr.org Thu Jul 27 08:50:13 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 27 Jul 2006 10:50:13 +0200 Subject: [Fedora-packaging] PHP guidelines In-Reply-To: Your message of "Wed, 26 Jul 2006 16:50:56 PDT." Message-ID: <200607270850.k6R8oD6N031716@ludwig-alpha.unil.ch> chris.stone at gmail.com said: > I don't see this as sticking a hand in a fire. It is simply the fact that > removing %build does not affect php-pear packages, there is no reason to add > it. If not adding it causes some problem with the php-pear packages, then > this should be identified. So far no one has identified such problem. One of the tenets of good software development is good documentation. IMHO, documenting the fact that a package doesn't need a %build step is a good thing. I'd much rather see a spec file with: %build # Nothing to build here than to see nothing at all. You know that one of the steps of rpmbuild is to perform the %build step. You can probably rightfully *guess* that if the %build isn't found, it will do nothing. But it's like when you observe nature, looking for some exotic bird: the fact you do not see it doesn't necessarily mean the bird doesn't exist... CHF 0.02... Cheers, Christian From skvidal at linux.duke.edu Thu Jul 27 22:12:39 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 27 Jul 2006 18:12:39 -0400 Subject: [Fedora-packaging] Re: yum kmdl plugin (was: atrpms kernel modules) In-Reply-To: <20060726230719.GD16278@neu.nirvana> References: <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <20060726143305.GQ5520@anduril.unity.ncsu.edu> <20060726230719.GD16278@neu.nirvana> Message-ID: <1154038360.20731.52.camel@cutter> On Thu, 2006-07-27 at 01:07 +0200, Axel Thimm wrote: > Thanks, I looked it up and indeed writing a yum plugin for kmdls is > trivial. I really like the design of the plugin/hook mechanism. > > So I managed to get a fully featured kmdl plugin under 100 python > lines (actually 99 ;). It even has two modes of operation: > Yah the plugin interface is pretty happy. I even gave a tutorial at lca on the subject: http://linux.duke.edu/~skvidal/lca-yum-tutorial/ Menno and others did some great work on the interface. > yum update: Will update/coinstall kmdl of all old and new kernels > > yum install: Will only do something with kmdls if a kernel is asked to > be installed (and only for that kernel) > > I differ between the two, because I don't want the user to be > surprised with kernel module installations when he yum-installs > openoffice :) > > It also supports asynced kernel/kernel-module repo arrival. When a > kernel update appears it will be installed even when the kmdls aren't > yet available/built. If on the next yum update the previously missing > kmdls appear, they will get installed at that time. > > I'm attaching the file (kmdl.py) to this mail. Seth & Jack you have a > look and if approved add it to yum/yum-util sources (whatever is more > appropriate)? If you don't like it let me know what needs improvement. I'll take a look shortly. thanks. The plugins are generally put in the yum-utils package and each of them broken out into their own subpackage. then adding them or not is easy for the end user. If everything looks okay is that cool for you? -sv From Axel.Thimm at ATrpms.net Fri Jul 28 12:07:57 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 28 Jul 2006 14:07:57 +0200 Subject: [Fedora-packaging] Re: yum kmdl plugin (was: atrpms kernel modules) In-Reply-To: <1154038360.20731.52.camel@cutter> References: <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <20060726143305.GQ5520@anduril.unity.ncsu.edu> <20060726230719.GD16278@neu.nirvana> <1154038360.20731.52.camel@cutter> Message-ID: <20060728120757.GA20601@neu.nirvana> On Thu, Jul 27, 2006 at 06:12:39PM -0400, seth vidal wrote: > On Thu, 2006-07-27 at 01:07 +0200, Axel Thimm wrote: > > Thanks, I looked it up and indeed writing a yum plugin for kmdls is > > trivial. I really like the design of the plugin/hook mechanism. > > > > So I managed to get a fully featured kmdl plugin under 100 python > > lines (actually 99 ;). It even has two modes of operation: > > Yah the plugin interface is pretty happy. I even gave a tutorial at lca > on the subject: > > http://linux.duke.edu/~skvidal/lca-yum-tutorial/ > > Menno and others did some great work on the interface. I see, it looks like YumBase can do everything and one mustn't (shouldn't?) resort to the rpm module directly. > > yum update: Will update/coinstall kmdl of all old and new kernels > > > > yum install: Will only do something with kmdls if a kernel is asked to > > be installed (and only for that kernel) > > > > I differ between the two, because I don't want the user to be > > surprised with kernel module installations when he yum-installs > > openoffice :) > > > > It also supports asynced kernel/kernel-module repo arrival. When a > > kernel update appears it will be installed even when the kmdls aren't > > yet available/built. If on the next yum update the previously missing > > kmdls appear, they will get installed at that time. > > > > I'm attaching the file (kmdl.py) to this mail. Seth & Jack you have a > > look and if approved add it to yum/yum-util sources (whatever is more > > appropriate)? If you don't like it let me know what needs improvement. > > I'll take a look shortly. thanks. > > The plugins are generally put in the yum-utils package and each of them > broken out into their own subpackage. > > then adding them or not is easy for the end user. > > If everything looks okay is that cool for you? Yes, thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Fri Jul 28 12:17:47 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 28 Jul 2006 08:17:47 -0400 Subject: [Fedora-packaging] Re: yum kmdl plugin (was: atrpms kernel modules) In-Reply-To: <20060728120757.GA20601@neu.nirvana> References: <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <20060726143305.GQ5520@anduril.unity.ncsu.edu> <20060726230719.GD16278@neu.nirvana> <1154038360.20731.52.camel@cutter> <20060728120757.GA20601@neu.nirvana> Message-ID: <1154089067.1935.17.camel@cutter> On Fri, 2006-07-28 at 14:07 +0200, Axel Thimm wrote: > > http://linux.duke.edu/~skvidal/lca-yum-tutorial/ > > > > Menno and others did some great work on the interface. > > I see, it looks like YumBase can do everything and one mustn't > (shouldn't?) resort to the rpm module directly. we've just tried to simplify the interface some. There's still much more room to improve and we've made some of those improvements in the 2.9.X devel branch. -sv From fedora at leemhuis.info Sun Jul 30 16:04:34 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 30 Jul 2006 18:04:34 +0200 Subject: [Fedora-packaging] Re: atrpms kernel modules In-Reply-To: <1153864835.3010.31.camel@localhost> References: <1153662172.30446.37.camel@localhost.localdomain> <20060723154517.GI17325@neu.nirvana> <1153673657.22693.11.camel@localhost.localdomain> <44C3B282.2090903@leemhuis.info> <20060723180153.GB32495@neu.nirvana> <1153683126.2769.103.camel@localhost.localdomain> <20060723201957.GE32495@neu.nirvana> <1153687139.13330.48.camel@cutter> <20060723210343.GF32495@neu.nirvana> <1153689220.13330.51.camel@cutter> <20060725213129.GR1164@neu.nirvana> <1153864835.3010.31.camel@localhost> Message-ID: <44CCD892.5060306@leemhuis.info> Toshio Kuratomi schrieb: > Apologies for posting into the wrong subthread of this monster, I > already deleted the relevant mail. > > If one of the major issues with the current kmod spec is that neither > rpm -U nor rpm -i work correctly, shouldn't that be corrected? If the > module could install into something like this: > /lib/modules/MODULE-VERSION-RELEASE/(KERNELVER|KABI)/MODULE.ko > > instead of: > /lib/modules/KERNELVER/extra/MODULE/MODULE.ko > > wouldn't that bring the behaviour of kmods inline with that of the > kernel? (Use rpm -i for normal operations, rpm -U if you don't believe > in Murphy). I like that idea -- especially when combined with the the kabi stuff. Yes, someone still could run "rpm -Uvh" and would loose older kmods, but yum and apt would do the right thing. CU thl From rdieter at math.unl.edu Mon Jul 31 13:53:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 31 Jul 2006 08:53:26 -0500 Subject: [Fedora-packaging] missing this week's IRC meeting(s) Message-ID: <44CE0B56.3030809@math.unl.edu> FYI, I'll be on vacation the latter part of this week, so I won't be able to attend this week's Packaging or FESCo meetings. -- Rex From tcallawa at redhat.com Mon Jul 31 17:21:22 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 31 Jul 2006 12:21:22 -0500 Subject: [Fedora-packaging] Re: COPYING (license) not under docdir In-Reply-To: <1153741895.22104.71.camel@mccallum.corsepiu.local> References: <20060723211739.GA6491@neu.nirvana> <1153689930.13330.54.camel@cutter> <1153718235.22104.53.camel@mccallum.corsepiu.local> <44C4AFDF.6080602@math.unl.edu> <20060724113734.GE17281@neu.nirvana> <1153741895.22104.71.camel@mccallum.corsepiu.local> Message-ID: <1154366482.3296.27.camel@localhost.localdomain> On Mon, 2006-07-24 at 13:51 +0200, Ralf Corsepius wrote: > On Mon, 2006-07-24 at 13:37 +0200, Axel Thimm wrote: > > On Mon, Jul 24, 2006 at 06:32:47AM -0500, Rex Dieter wrote: > > > While we're on the subject, what's the importance that the license file > > > under %_docdir anyway? As far as I'm concerned, as long as the license > > > is in the package somewhere, that's should be sufficient. > > > > Easier mass-review by legal? It's easier to check there than rpm > > -ql'ing the package and browsing though all file lists. > A real legal review would have to look into each and every file in any > case. No matter which kind of "detached license files" a package's > tarball is accompanied by, or an FE rpm-packager might have added. Having recently done some of this, I would have to agree with Ralf. The license in text is nice (and we should try to have it), but the source code is what is binding. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Mon Jul 31 18:05:20 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 31 Jul 2006 13:05:20 -0500 Subject: [Fedora-packaging] missing this week's meetings Message-ID: <1154369120.3296.30.camel@localhost.localdomain> Due to the fact that I will be on a plane somewhere between California and Illinois on Thursday, I will not be able to attend this week's Packaging or FESCo meetings. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Mon Jul 31 18:07:28 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 31 Jul 2006 14:07:28 -0400 Subject: [Fedora-packaging] missing this week's meetings In-Reply-To: <1154369120.3296.30.camel@localhost.localdomain> References: <1154369120.3296.30.camel@localhost.localdomain> Message-ID: <20060731180728.GA18328@jadzia.bu.edu> On Mon, Jul 31, 2006 at 01:05:20PM -0500, Tom 'spot' Callaway wrote: > Due to the fact that I will be on a plane somewhere between California > and Illinois on Thursday, I will not be able to attend this week's > Packaging or FESCo meetings. Red Hat doesn't pay for a satellite link up for you for this? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tcallawa at redhat.com Mon Jul 31 18:16:07 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 31 Jul 2006 13:16:07 -0500 Subject: [Fedora-packaging] missing this week's meetings In-Reply-To: <20060731180728.GA18328@jadzia.bu.edu> References: <1154369120.3296.30.camel@localhost.localdomain> <20060731180728.GA18328@jadzia.bu.edu> Message-ID: <1154369767.3296.34.camel@localhost.localdomain> On Mon, 2006-07-31 at 14:07 -0400, Matthew Miller wrote: > On Mon, Jul 31, 2006 at 01:05:20PM -0500, Tom 'spot' Callaway wrote: > > Due to the fact that I will be on a plane somewhere between California > > and Illinois on Thursday, I will not be able to attend this week's > > Packaging or FESCo meetings. > > Red Hat doesn't pay for a satellite link up for you for this? Even if they did (they do not), the nice people serving drinks on the airplane would likely blow a fuse if they saw me using a "wireless" connection. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jkeating at redhat.com Mon Jul 31 18:20:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 31 Jul 2006 14:20:05 -0400 Subject: [Fedora-packaging] missing this week's meetings In-Reply-To: <1154369767.3296.34.camel@localhost.localdomain> References: <1154369120.3296.30.camel@localhost.localdomain> <20060731180728.GA18328@jadzia.bu.edu> <1154369767.3296.34.camel@localhost.localdomain> Message-ID: <200607311420.05560.jkeating@redhat.com> On Monday 31 July 2006 14:16, Tom 'spot' Callaway wrote: > Even if they did (they do not), the nice people serving drinks on the > airplane would likely blow a fuse if they saw me using a "wireless" > connection. Jet Blue offers inflight wifi.... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Jul 31 18:25:40 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 31 Jul 2006 13:25:40 -0500 Subject: [Fedora-packaging] missing this week's meetings In-Reply-To: <200607311420.05560.jkeating@redhat.com> References: <1154369120.3296.30.camel@localhost.localdomain> <20060731180728.GA18328@jadzia.bu.edu> <1154369767.3296.34.camel@localhost.localdomain> <200607311420.05560.jkeating@redhat.com> Message-ID: <1154370340.3296.37.camel@localhost.localdomain> On Mon, 2006-07-31 at 14:20 -0400, Jesse Keating wrote: > On Monday 31 July 2006 14:16, Tom 'spot' Callaway wrote: > > Even if they did (they do not), the nice people serving drinks on the > > airplane would likely blow a fuse if they saw me using a "wireless" > > connection. > > Jet Blue offers inflight wifi.... And yet, Jet Blue doesn't fly into Chicago at all. Or anywhere in the midwest. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From mattdm at mattdm.org Mon Jul 31 18:27:33 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 31 Jul 2006 14:27:33 -0400 Subject: [Fedora-packaging] missing this week's meetings In-Reply-To: <1154370340.3296.37.camel@localhost.localdomain> References: <1154369120.3296.30.camel@localhost.localdomain> <20060731180728.GA18328@jadzia.bu.edu> <1154369767.3296.34.camel@localhost.localdomain> <200607311420.05560.jkeating@redhat.com> <1154370340.3296.37.camel@localhost.localdomain> Message-ID: <20060731182733.GA19395@jadzia.bu.edu> On Mon, Jul 31, 2006 at 01:25:40PM -0500, Tom 'spot' Callaway wrote: > > > Even if they did (they do not), the nice people serving drinks on the > > > airplane would likely blow a fuse if they saw me using a "wireless" > > > connection. > > Jet Blue offers inflight wifi.... > And yet, Jet Blue doesn't fly into Chicago at all. Or anywhere in the > midwest. Clearly, a private Fedora jet is in order. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at linux.duke.edu Mon Jul 31 20:11:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 31 Jul 2006 16:11:36 -0400 Subject: [Fedora-packaging] missing this week's meetings In-Reply-To: <20060731182733.GA19395@jadzia.bu.edu> References: <1154369120.3296.30.camel@localhost.localdomain> <20060731180728.GA18328@jadzia.bu.edu> <1154369767.3296.34.camel@localhost.localdomain> <200607311420.05560.jkeating@redhat.com> <1154370340.3296.37.camel@localhost.localdomain> <20060731182733.GA19395@jadzia.bu.edu> Message-ID: <1154376697.3478.42.camel@cutter> On Mon, 2006-07-31 at 14:27 -0400, Matthew Miller wrote: > On Mon, Jul 31, 2006 at 01:25:40PM -0500, Tom 'spot' Callaway wrote: > > > > Even if they did (they do not), the nice people serving drinks on the > > > > airplane would likely blow a fuse if they saw me using a "wireless" > > > > connection. > > > Jet Blue offers inflight wifi.... > > And yet, Jet Blue doesn't fly into Chicago at all. Or anywhere in the > > midwest. > > Clearly, a private Fedora jet is in order. We should get dfong working on a logo mockup on the side of a plane right away. -sv From notting at redhat.com Mon Jul 31 20:12:50 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 31 Jul 2006 16:12:50 -0400 Subject: [Fedora-packaging] missing this week's meetings In-Reply-To: <1154376697.3478.42.camel@cutter> References: <1154369120.3296.30.camel@localhost.localdomain> <20060731180728.GA18328@jadzia.bu.edu> <1154369767.3296.34.camel@localhost.localdomain> <200607311420.05560.jkeating@redhat.com> <1154370340.3296.37.camel@localhost.localdomain> <20060731182733.GA19395@jadzia.bu.edu> <1154376697.3478.42.camel@cutter> Message-ID: <20060731201250.GA13422@devserv.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > > Clearly, a private Fedora jet is in order. > > We should get dfong working on a logo mockup on the side of a plane > right away. Why a plane? Don't we already have the black helicopters? Bill From skvidal at linux.duke.edu Mon Jul 31 20:14:17 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 31 Jul 2006 16:14:17 -0400 Subject: [Fedora-packaging] missing this week's meetings In-Reply-To: <20060731201250.GA13422@devserv.devel.redhat.com> References: <1154369120.3296.30.camel@localhost.localdomain> <20060731180728.GA18328@jadzia.bu.edu> <1154369767.3296.34.camel@localhost.localdomain> <200607311420.05560.jkeating@redhat.com> <1154370340.3296.37.camel@localhost.localdomain> <20060731182733.GA19395@jadzia.bu.edu> <1154376697.3478.42.camel@cutter> <20060731201250.GA13422@devserv.devel.redhat.com> Message-ID: <1154376857.3478.44.camel@cutter> On Mon, 2006-07-31 at 16:12 -0400, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > > Clearly, a private Fedora jet is in order. > > > > We should get dfong working on a logo mockup on the side of a plane > > right away. > > Why a plane? Don't we already have the black helicopters? > The logo is blue - it doesn't look as good on a black helicopter. -sv