From tcallawa at redhat.com Tue Mar 1 00:00:32 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 28 Feb 2005 18:00:32 -0600 Subject: [Fedora-packaging] Template .spec file for conventions? In-Reply-To: <200502282227.52115.ghenry@suretecsystems.com> References: <1109627478.5520.139.camel@sukothai.pingtel.com> <200502282227.52115.ghenry@suretecsystems.com> Message-ID: <1109635232.7400.228.camel@localhost.localdomain> On Mon, 2005-02-28 at 22:27 +0000, Gavin Henry wrote: >And for specfiles: > >http://www.fedora.us/tempspecs/stable/ ^^^ I haven't even looked at this. But if it conflicts with the below Guidelines, let me know. >General ideas see: > >http://fedoraproject.org/wiki/PackagingGuidelines > ^^^ This is maybe 20% done. That doesn't mean its wrong, but I haven't finished it. >And: > >http://fedoraproject.org/wiki/PackageNamingGuidelines ^^^ This is 90% done. I'm going to make some changes to it this evening. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 1 02:01:38 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 01 Mar 2005 03:01:38 +0100 Subject: [Fedora-packaging] disttag In-Reply-To: <1109339620.13305.261.camel@localhost.localdomain> (Tom Callaway's message of "Fri, 25 Feb 2005 07:53:39 -0600") References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> Message-ID: <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> "Tom 'spot' Callaway" writes: >>An easy to way to fix this would be to have "%{?disttag}" appended to the >>"Release:" line of the spec by the build system, and have the "." returned >>by the macro > ... > I prefer the %{?disttag:.%{disttag}} syntax for use, if for no other > reason than it makes the macro a little cleaner. IMO, the opposite it true... defining the macro happens once at a central place invisible for most people, but it will be used in hundreds of .spec files (perhaps). So I would prefer a clear and simple usage. 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 Tue Mar 1 02:06:59 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 01 Mar 2005 03:06:59 +0100 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: (Elliot Lee's message of "Thu, 24 Feb 2005 13:52:58 -0500 (EST)") References: Message-ID: <87y8d8i0fw.fsf@kosh.ultra.csn.tu-chemnitz.de> Elliot Lee writes: > The stuff that could improve is eliminating "non-numeric version in > release". For the sake of keeping things sane and simple, the Version: > should normally match the upstream version. If there are versions such > as 0.1beta that compare as "greater than" 0.1, then epoch should be > used. I do not think so; non-zero epochs should be avoided. Instead of, we should fix the non-numeric version numbers once and forever by changing rpmvercmp() (this is inspired by something which I read on the upm maillist but I do not have a link to it): Introduce a smaller-than-everything delimiter like '~' so that e.g. the following relations will hold: 1.0~a < 1.0 < 1.0a Advantages are, that it has a clear semantic, it will not break the traditional rpmvercmp() and does not require addition rpm headers. Disadvantages are some uglyness in the naming, that you can not use '~' as a reqular character anymore (I am not aware of any package having this) and that it causes problems with previous rpm versions not knowing this. > That's one of the situations that epoch was created for. Epochs were acceptably with the previous behavior (missing epoch in comparision means the epoch of the other side). The current behavior (no epoch means epoch 0) makes it impossible to depend on any upstream version. Therefore, non-zero epochs should be avoided. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tcallawa at redhat.com Tue Mar 1 03:18:54 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 28 Feb 2005 21:18:54 -0600 Subject: [Fedora-packaging] PackageNamingGuidelines comments In-Reply-To: <87y8d8i0fw.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87y8d8i0fw.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1109647134.7400.258.camel@localhost.localdomain> On Tue, 2005-03-01 at 03:06 +0100, Enrico Scholz wrote: >Elliot Lee writes: > >> The stuff that could improve is eliminating "non-numeric version in >> release". For the sake of keeping things sane and simple, the Version: >> should normally match the upstream version. If there are versions such >> as 0.1beta that compare as "greater than" 0.1, then epoch should be >> used. > >I do not think so; non-zero epochs should be avoided. Instead of, we >should fix the non-numeric version numbers once and forever by changing >rpmvercmp() (this is inspired by something which I read on the upm >maillist but I do not have a link to it): I don't disagree with this, however, it will require fairly intrusive changes to rpm. You should float this idea past Jeff and see what he thinks of it. If he accepts the idea, and it is implemented in rpm, then we can revisit the Naming Guidelines. However, until that point, we're stuck with the non-numeric version case for pre-release packages. This doesn't mean that we encourage Epoch use, far from it. In fact, if followed (and enforced), the non-numeric version case guidelines help prevent the need for Epoch in the majority of cases. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Tue Mar 1 03:29:26 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 28 Feb 2005 21:29:26 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1109647767.7400.266.camel@localhost.localdomain> On Tue, 2005-03-01 at 03:01 +0100, Enrico Scholz wrote: >"Tom 'spot' Callaway" writes: > >>>An easy to way to fix this would be to have "%{?disttag}" appended to the >>>"Release:" line of the spec by the build system, and have the "." returned >>>by the macro >> ... >> I prefer the %{?disttag:.%{disttag}} syntax for use, if for no other >> reason than it makes the macro a little cleaner. > >IMO, the opposite it true... defining the macro happens once at a central >place invisible for most people, but it will be used in hundreds of .spec >files (perhaps). So I would prefer a clear and simple usage. This is really semantics. Its either: We use %{?disttag:.%{disttag}} in the Release: field, and we conditionalize like this: %if "%{disttag}" == "2.fc3" Or, we use %{?disttag:%{disttag}} in the Release: field, and we conditionalize like this: %if "%{disttag}" == ".2.fc3" It doesn't matter to me. I'd prefer the extra period in the Release field with the simplified conditionals, but if everyone else prefers the other way around, then I'll document the other way. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From bugs.michael at gmx.net Tue Mar 1 04:56:02 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Mar 2005 05:56:02 +0100 Subject: [Fedora-packaging] disttag In-Reply-To: <1109647767.7400.266.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> Message-ID: <20050301055602.5b09b2eb.bugs.michael@gmx.net> On Mon, 28 Feb 2005 21:29:26 -0600, Tom 'spot' Callaway wrote: > Its either: > We use %{?disttag:.%{disttag}} in the Release: field, and we > conditionalize like this: %if "%{disttag}" == "2.fc3" > > Or, we use %{?disttag:%{disttag}} in the Release: field, and we > conditionalize like this: %if "%{disttag}" == ".2.fc3" I hope we never conditionalise like that, where we must look up weird dist tags in a table, because we don't have an easier way how to determine the actual build target platform conditionally. If we go as far as evaluating %{disttag} instead of keeping it fully optional -- %{?disttag:...} means it can be undefined (!) -- we better define an unambiguous %{dist} or %{distribution} constant somewhere. > It doesn't matter to me. I'd prefer the extra period in the Release > field with the simplified conditionals, but if everyone else prefers the > other way around, then I'll document the other way. +1 to Enrico's view. A simple and clean %{?disttag} appended to the release field. And since it can expand to virtually everything, don't abuse it for conditionally _guessing_ build platforms. From ville.skytta at iki.fi Tue Mar 1 06:59:27 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 01 Mar 2005 08:59:27 +0200 Subject: [Fedora-packaging] Template .spec file for conventions? In-Reply-To: <1109635232.7400.228.camel@localhost.localdomain> References: <1109627478.5520.139.camel@sukothai.pingtel.com> <200502282227.52115.ghenry@suretecsystems.com> <1109635232.7400.228.camel@localhost.localdomain> Message-ID: <1109660367.15077.80.camel@bobcat.mine.nu> On Mon, 2005-02-28 at 18:00 -0600, Tom 'spot' Callaway wrote: > On Mon, 2005-02-28 at 22:27 +0000, Gavin Henry wrote: > > >And for specfiles: > > > >http://www.fedora.us/tempspecs/stable/ > > ^^^ I haven't even looked at this. But if it conflicts with the below > Guidelines, let me know. It's just a dump of all fedora.us specfiles, which is of doubtful usefulness nowadays. Warren, could you take that offline and add a pointer or a redirect to http://cvs.fedora.redhat.com/viewcvs/?root=extras there instead? From ville.skytta at iki.fi Tue Mar 1 07:21:41 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 01 Mar 2005 09:21:41 +0200 Subject: [Fedora-packaging] disttag In-Reply-To: <20050301055602.5b09b2eb.bugs.michael@gmx.net> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> Message-ID: <1109661701.15077.96.camel@bobcat.mine.nu> On Tue, 2005-03-01 at 05:56 +0100, Michael Schwendt wrote: > +1 to Enrico's view. A simple and clean %{?disttag} appended to the release > field. +1 From tcallawa at redhat.com Tue Mar 1 13:41:08 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 01 Mar 2005 07:41:08 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050301055602.5b09b2eb.bugs.michael@gmx.net> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> Message-ID: <1109684468.30463.8.camel@localhost.localdomain> On Tue, 2005-03-01 at 05:56 +0100, Michael Schwendt wrote: >> It doesn't matter to me. I'd prefer the extra period in the Release >> field with the simplified conditionals, but if everyone else prefers the >> other way around, then I'll document the other way. > >+1 to Enrico's view. A simple and clean %{?disttag} appended to the release >field. And since it can expand to virtually everything, don't abuse it for >conditionally _guessing_ build platforms. Let me reiterate. I am fundamentally opposed to a disttag that can "expand to virtually everything". Hence, the macro definition of disttag, and the limitation of the defined possiblities. With the macro, we're not guessing the build platform. redhat-release shouldn't lie in our buildroots, or we have bigger problems. I vastly oversimplified the conditional cases, obviously, when used, they should be checked for disttag existence first. But I do see the value of %{?disttag} in the release field now, thanks. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nicolas.mailhot at laposte.net Tue Mar 1 14:41:02 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 1 Mar 2005 15:41:02 +0100 (CET) Subject: [Fedora-packaging] disttag In-Reply-To: <1109684468.30463.8.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> Message-ID: <16667.192.54.193.137.1109688062.squirrel@rousalka.dyndns.org> On Mar 1 mars 2005 14:41, Tom 'spot' Callaway a ?crit : > On Tue, 2005-03-01 at 05:56 +0100, Michael Schwendt wrote: > >>> It doesn't matter to me. I'd prefer the extra period in the Release >>> field with the simplified conditionals, but if everyone else prefers >>> the >>> other way around, then I'll document the other way. >> >>+1 to Enrico's view. A simple and clean %{?disttag} appended to the >> release >>field. And since it can expand to virtually everything, don't abuse it >> for >>conditionally _guessing_ build platforms. > > Let me reiterate. I am fundamentally opposed to a disttag that can > "expand to virtually everything". Hence, the macro definition of > disttag, and the limitation of the defined possiblities. In this case do the defined possibilities take into account rawhide and test systems ? Regards, -- Nicolas Mailhot From bugs.michael at gmx.net Tue Mar 1 15:08:12 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Mar 2005 16:08:12 +0100 Subject: [Fedora-packaging] disttag In-Reply-To: <1109684468.30463.8.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> Message-ID: <20050301160812.1d29bc99.bugs.michael@gmx.net> On Tue, 01 Mar 2005 07:41:08 -0600, Tom 'spot' Callaway wrote: > Let me reiterate. I am fundamentally opposed to a disttag that can > "expand to virtually everything". Hence, the macro definition of > disttag, and the limitation of the defined possiblities. Let me expand on my comment then. We don't use the disttag for branding, do we? The purpose of appending a disttag to the package release is not in flagging a package file as being for a specific distribution environment. If you disagree, a tag like "2.el4" is a very poor choice. The purpose of a disttag postfix -- is it the primary or sole purpose? -- is in making it possible that a single src.rpm can be built for multiple distribution releases without needing to worry about EVR comparison for upgrade paths. Using this disttag postfix is transparent to the packager, except for the %{?disttag} macro that must be appended to the Release value. Whether the postfix will be ".FC2", ".fc3", ".RHEL4" or empty should not be something the package developer needs to worry about. Yes, the macro can be undefined and then would expand to nothing and would append nothing. This would be the case for every build machine which isn't updated to define %disttag somewhere. Hence I'd like to avoid a multi-purpose macro, which is not only used to append a release postfix, but which is also relied on upon finding out the build target distribution. The earlier posted dist tag list 0.el2 0.rh7 0.rh8 0.rh9 1.el3 1.fc1 1.fc2 1.fc3 2.el4 2.fc4 2.fc5 2.fc6 3.el5 is enough of a kludge already. An ugly kludge, which pretends an upgrade path which is unsupported, and which makes package file names ugly too. But it would achieve what it's supposed to achieve, provided that every package update is built and released for all newer distro releases. But please, if we go as far as defining a %disttag value somewhere in our build environments, which is also to be used for determining the target distro in conditional spec sections, better let's define a second macro. A second macro, which has the sole purpose of making it unnecessary to examine redhat-release in the spec file. That one could be everything from a generic %distribution value to a specific %{?fedora} and %{?rhel}, which expand to a numerical release version. Would also allow much more obvious rpmbuild --define "fedora 4" builds. I'd rather check for "%{?rhel}" == "4" than to check for "%{?disttag}" == ".2.el4". From skvidal at phy.duke.edu Tue Mar 1 18:34:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 01 Mar 2005 13:34:17 -0500 Subject: [Fedora-packaging] python version grabbing Message-ID: <1109702057.31304.4.camel@cutter> Hey, Do you think it'd be worth it to have a section on getting the python version for site-packages for rpm building? Maybe with the standard routines? -sv From bugs.michael at gmx.net Tue Mar 1 19:25:16 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Mar 2005 20:25:16 +0100 Subject: [Fedora-packaging] python version grabbing In-Reply-To: <1109702057.31304.4.camel@cutter> References: <1109702057.31304.4.camel@cutter> Message-ID: <20050301202516.589d0053.bugs.michael@gmx.net> On Tue, 01 Mar 2005 13:34:17 -0500, seth vidal wrote: > Hey, > Do you think it'd be worth it to have a section on getting the python > version for site-packages for rpm building? Maybe with the standard > routines? Good idea, IMO. Also a section for python-abi and perl MODULE_COMPAT stuff. From ville.skytta at iki.fi Tue Mar 1 20:04:30 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 01 Mar 2005 22:04:30 +0200 Subject: [Fedora-packaging] python version grabbing In-Reply-To: <20050301202516.589d0053.bugs.michael@gmx.net> References: <1109702057.31304.4.camel@cutter> <20050301202516.589d0053.bugs.michael@gmx.net> Message-ID: <1109707470.15077.143.camel@bobcat.mine.nu> On Tue, 2005-03-01 at 20:25 +0100, Michael Schwendt wrote: > On Tue, 01 Mar 2005 13:34:17 -0500, seth vidal wrote: > > > Hey, > > Do you think it'd be worth it to have a section on getting the python > > version for site-packages for rpm building? Maybe with the standard > > routines? > > Good idea, IMO. Also a section for python-abi and perl MODULE_COMPAT > stuff. Using the python version for the site-packages directories is unnecessary, and leads to various problems (because it sort of encourages to use manual %{_libdir} which will break noarch packages built on x86_64). Quite a few packages have required related fixes lately in Extras. It is much cleaner to ask python itself, and use the python_sitelib and python_sitearch macros present for example in /usr/share/fedora/spectemplate-python.spec (from fedora-rpmdevtools). Related RFE @ https://bugzilla.redhat.com/beta/show_bug.cgi?id=120635 python-abi is a separate beast; for that a version is clearly needed. Some of that stuff will be sometime later handled automagically by rpm. But there's at least one thing to be aware of, and if possible, it'd be good to "solve" this naming issue: - Current FC python packages provide "python-abi = $version", and that is also being used in python extension packages' Requires. - scripts/pythondeps.sh in rpm CVS generates "python(abi) = $version" provides/requires. I personally find also the method in which it does it somewhat weird but it'll probably work ok as long as only the python package shipping with a distro is installed. From dag at wieers.com Tue Mar 1 20:55:57 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 1 Mar 2005 21:55:57 +0100 (CET) Subject: [Fedora-packaging] disttag In-Reply-To: <20050301160812.1d29bc99.bugs.michael@gmx.net> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> <20050301160812.1d29bc99.bugs.michael@gmx.net> Message-ID: On Tue, 1 Mar 2005, Michael Schwendt wrote: > On Tue, 01 Mar 2005 07:41:08 -0600, Tom 'spot' Callaway wrote: > > > Let me reiterate. I am fundamentally opposed to a disttag that can > > "expand to virtually everything". Hence, the macro definition of > > disttag, and the limitation of the defined possiblities. > > Let me expand on my comment then. > > We don't use the disttag for branding, do we? The purpose of appending a > disttag to the package release is not in flagging a package file as being > for a specific distribution environment. If you disagree, a tag like > "2.el4" is a very poor choice. > > The purpose of a disttag postfix -- is it the primary or sole purpose? -- > is in making it possible that a single src.rpm can be built for multiple > distribution releases without needing to worry about EVR comparison for > upgrade paths. > > Using this disttag postfix is transparent to the packager, except for the > %{?disttag} macro that must be appended to the Release value. Whether the > postfix will be ".FC2", ".fc3", ".RHEL4" or empty should not be something > the package developer needs to worry about. Yes, the macro can be > undefined and then would expand to nothing and would append nothing. This > would be the case for every build machine which isn't updated to define > %disttag somewhere. > > Hence I'd like to avoid a multi-purpose macro, which is not only used to > append a release postfix, but which is also relied on upon finding out the > build target distribution. > > The earlier posted dist tag list > > 0.el2 0.rh7 0.rh8 0.rh9 1.el3 1.fc1 1.fc2 1.fc3 2.el4 2.fc4 2.fc5 > 2.fc6 3.el5 > > is enough of a kludge already. An ugly kludge, which pretends an upgrade > path which is unsupported, and which makes package file names ugly too. > But it would achieve what it's supposed to achieve, provided that every > package update is built and released for all newer distro releases. > > But please, if we go as far as defining a %disttag value somewhere in our > build environments, which is also to be used for determining the target > distro in conditional spec sections, better let's define a second macro. A > second macro, which has the sole purpose of making it unnecessary to > examine redhat-release in the spec file. > > That one could be everything from a generic %distribution value to a > specific %{?fedora} and %{?rhel}, which expand to a numerical release > version. Would also allow much more obvious rpmbuild --define "fedora 4" > builds. I'd rather check for "%{?rhel}" == "4" than to check for > "%{?disttag}" == ".2.el4". RPMforge uses %{dist} for providing the release, like: el2, el3, el4, rh6, rh7, rh8, rh9, fc1, fc2, fc3 We don't have a disttag, because this is appended to the Release-tag by the buildsystem (since the only real reason is to have it in the Release-tag and only in the Release-tag, it does not actually have to be inside the SPEC file anyway). The prefix dot also is no longer required. This allows us to do things like: %{?dist: %{expand: %%define %dist 1}} and %{?el2:%define _without_alsa 1} and %if %{?el2:1}%{?el3:1}%{?el4:1}0 Some of these things look ugly, I agree. But since I'm not a developer and a change in RPM is less desired anyway, it's probably the closest we can go if the functionality is required. I would like to expand the RPM language somehow to allow for constructs like: %if %{dist} in ('el2', 'el3', 'el4') or %if %{dist} matches '^el' If new things are added to RPM, we either require a backport to older rpm-build or wait wcs 7 years (el4 eol) to start using the functionality. Something FE does not have to worry about as much as I do though. So is there a reason why we have to have the disttag and cannot have the buildsystem rewrite the SPEC file ? -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From ville.skytta at iki.fi Tue Mar 1 21:36:35 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 01 Mar 2005 23:36:35 +0200 Subject: [Fedora-packaging] disttag In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> <20050301160812.1d29bc99.bugs.michael@gmx.net> Message-ID: <1109712995.15077.173.camel@bobcat.mine.nu> On Tue, 2005-03-01 at 21:55 +0100, Dag Wieers wrote: > %if %{dist} matches '^el' %if 0%(echo %{dist} | grep -q ^el && echo 1) ... From dag at wieers.com Tue Mar 1 22:04:11 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 1 Mar 2005 23:04:11 +0100 (CET) Subject: [Fedora-packaging] disttag In-Reply-To: <1109712995.15077.173.camel@bobcat.mine.nu> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> <20050301160812.1d29bc99.bugs.michael@gmx.net> <1109712995.15077.173.camel@bobcat.mine.nu> Message-ID: On Tue, 1 Mar 2005, Ville Skytt? wrote: > On Tue, 2005-03-01 at 21:55 +0100, Dag Wieers wrote: > > > %if %{dist} matches '^el' > > %if 0%(echo %{dist} | grep -q ^el && echo 1) ... Well... :) Things should still be somewhat obvious. I'd much rather have: %if %{?el2} or %{?el3} or %if not %{?el2} and not %{?el3} than %if %{?el2:1}%{?el3:1}0 or ??? Even though you have much flexibility as you just demonstrated, simplicity is important. Especially if you want to build from a single SPEC file you want to bring down the amount of 'ugly glue'. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From tcallawa at redhat.com Tue Mar 1 16:09:12 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 01 Mar 2005 10:09:12 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <16667.192.54.193.137.1109688062.squirrel@rousalka.dyndns.org> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> <16667.192.54.193.137.1109688062.squirrel@rousalka.dyndns.org> Message-ID: <1109693353.4253.4.camel@localhost.localdomain> On Tue, 2005-03-01 at 15:41 +0100, Nicolas Mailhot wrote: >In this case do the defined possibilities take into account rawhide and >test systems ? I tested, and it treats rawhide correctly (labels it as the next release), and I'm pretty sure it will do the same with test releases, since we're grabbing the package %{version} from the *-release package, not trying to parse /etc/redhat-release. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Wed Mar 2 01:37:33 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 01 Mar 2005 19:37:33 -0600 Subject: [Fedora-packaging] disttag In-Reply-To: <20050301160812.1d29bc99.bugs.michael@gmx.net> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> <20050301160812.1d29bc99.bugs.michael@gmx.net> Message-ID: <1109727453.3899.13.camel@localhost.localdomain> On Tue, 2005-03-01 at 16:08 +0100, Michael Schwendt wrote: >The purpose of a disttag postfix -- is it the primary or sole purpose? -- >is in making it possible that a single src.rpm can be built for multiple >distribution releases without needing to worry about EVR comparison for >upgrade paths. The purpose of a disttag postfix was so that a single src.rpm can be built for multiple distribution releases. There are cases in which BuildRequires: and Requires: will be different for different distribution releases. Hence, the disttag does double duty: - it differentiates multiple packages which would otherwise have the same %{name}-%{version}-%{release}, but very different dependencies. - it allows for a conditional check in the spec to deal with the differing dependencies. >But please, if we go as far as defining a %disttag value somewhere in our >build environments, which is also to be used for determining the target >distro in conditional spec sections, better let's define a second macro. A >second macro, which has the sole purpose of making it unnecessary to >examine redhat-release in the spec file. OK, I agree with this. I don't want to insult RPMForge, but I really don't think that an upgrade path between RHEL and Fedora is viable, or something that we should attempt to promote. I've been thinking about this, and it has two major downsides: 1. It implies we support it. We don't. 2. It adds an extra field to the Release to confuse people. The vast majority of people will understand why a ".fc3" or ".el4" might show up in the %{release} field, they won't understand why there is an .2 vs a .3 in front of the dist. >That one could be everything from a generic %distribution value to a >specific %{?fedora} and %{?rhel}, which expand to a numerical release >version. Would also allow much more obvious rpmbuild --define "fedora 4" >builds. I'd rather check for "%{?rhel}" == "4" than to check for >"%{?disttag}" == ".2.el4". This shouldn't be terribly difficult to do. Lets say I whip up some macros that define %{rhel}, %{fedora}, and %{rhl}, if they are relevant, with the appropriate numeric version. What would the conditionals look like? ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From dag at wieers.com Wed Mar 2 01:59:46 2005 From: dag at wieers.com (Dag Wieers) Date: Wed, 2 Mar 2005 02:59:46 +0100 (CET) Subject: [Fedora-packaging] disttag In-Reply-To: <1109727453.3899.13.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> <20050301160812.1d29bc99.bugs.michael@gmx.net> <1109727453.3899.13.camel@localhost.localdomain> Message-ID: On Tue, 1 Mar 2005, Tom 'spot' Callaway wrote: > OK, I agree with this. I don't want to insult RPMForge, but I really > don't think that an upgrade path between RHEL and Fedora is viable, or > something that we should attempt to promote. I've been thinking about > this, and it has two major downsides: > > 1. It implies we support it. We don't. > 2. It adds an extra field to the Release to confuse people. It would be insulting if you said we were morons for having it :) But as Fedora Extras goal is to limit to Fedora packages only, it makes sense. Although I do not agree that having it implies you support it per se. You allow it if people want to go there. And people have successfully upgrade from RH 7.3 and RH 9 to RHEL 3, likewise people are upgrading FC to RHEL 4 with only minor adaptations. Also, with smart package managers (that can prioritize repositories) it might become unnecessary in the future to have it. If the disttag will only contain 'rh9', 'fc1' or 'el3' and be used for conditionals, can we consider using %{dist} instead of %{disttag} ? This would be compatible with our usage, is shorter and I don't see any drawbacks. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From notting at redhat.com Wed Mar 2 04:40:59 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 Mar 2005 23:40:59 -0500 Subject: [Fedora-packaging] python version grabbing In-Reply-To: <1109707470.15077.143.camel@bobcat.mine.nu> References: <1109702057.31304.4.camel@cutter> <20050301202516.589d0053.bugs.michael@gmx.net> <1109707470.15077.143.camel@bobcat.mine.nu> Message-ID: <20050302044059.GD11155@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > Some of that stuff will be sometime later handled automagically by rpm. As I understood, the rpm bits are already there. Bill From bugs.michael at gmx.net Wed Mar 2 06:29:37 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 2 Mar 2005 07:29:37 +0100 Subject: [Fedora-packaging] disttag In-Reply-To: <1109727453.3899.13.camel@localhost.localdomain> References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> <20050301160812.1d29bc99.bugs.michael@gmx.net> <1109727453.3899.13.camel@localhost.localdomain> Message-ID: <20050302072937.1409d19e.bugs.michael@gmx.net> On Tue, 01 Mar 2005 19:37:33 -0600, Tom 'spot' Callaway wrote: > Lets say I whip up some macros that define %{rhel}, %{fedora}, and > %{rhl}, if they are relevant, with the appropriate numeric version. > > What would the conditionals look like? Examples, assuming %rhel is defined only on Red Hat Enterprise Linux, %fedora is defined only on Fedora Core, %rhl is defined only on Red Hat Linux: # Do something special for RHEL. %if 0%{?rhel} # ... %endif # Do something for FC4 and beyond. %if "%fedora" >= "4" # ... %endif # One-liners, here set a default switch. %{?fedora:%define _with_xfce --with-xfce} # Logical AND, do something for RHEL and RHL. %if 0%{?rhel} %if 0%{?rhl} # ... %endif %endif # Logical OR, do something for either RHL or Fedora. %if 0%{?rhl}%{?fedora} # ... %endif # Safer version, in case %rhl or %fedora expand to something non-numerical. %if 0%{?rhl:1}%{?fedora:1} # ... %endif # Logical NOT, don't do something for RHEL %if 0%{!?rhel} # ... %endif rpmbuild --rebuild --define "rhel 3" blubb.src.rpm From bugs.michael at gmx.net Wed Mar 2 06:33:18 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 2 Mar 2005 07:33:18 +0100 Subject: [Fedora-packaging] disttag In-Reply-To: References: <1109189890.13305.107.camel@localhost.localdomain> <1109197190.24989.56.camel@chip.laiskiainen.org> <1109287718.13305.238.camel@localhost.localdomain> <20050225115505.5840d895@python2> <1109339620.13305.261.camel@localhost.localdomain> <87zmxoi0ot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1109647767.7400.266.camel@localhost.localdomain> <20050301055602.5b09b2eb.bugs.michael@gmx.net> <1109684468.30463.8.camel@localhost.localdomain> <20050301160812.1d29bc99.bugs.michael@gmx.net> Message-ID: <20050302073318.0a49216d.bugs.michael@gmx.net> On Tue, 1 Mar 2005 21:55:57 +0100 (CET), Dag Wieers wrote: > RPMforge uses %{dist} for providing the release, like: > > el2, el3, el4, rh6, rh7, rh8, rh9, fc1, fc2, fc3 That's even more reason for Fedora Extras not to use an ugly %disttag for the same purpose. As if RPM's spec syntax were not ugly enough. From dawson at fnal.gov Wed Mar 2 16:51:41 2005 From: dawson at fnal.gov (Troy Dawson) Date: Wed, 02 Mar 2005 10:51:41 -0600 Subject: [Fedora-packaging] kernel-module rpm's - final decision? Message-ID: <4225EF1D.7090605@fnal.gov> Hello, As we are currently working on our openafs package, I want to make sure our kernel modules for it conform to what was agreed upon. But other than the naming, I didn't see a definate 'this is how to do them' list. (If I missed that, point me to it) Here's what I saw. My example will be openafs, but I am meaning this for others as well. Name: kernel-module-openafs Version: 1.3.9 Release: 2.6.9-5.0.3.EL.4 Requires: kernel = 2.6.9-5.0.3.EL Provides: kernel-module-openafs Then the discussion shifted to whether yum and apt would be able to handle this. And there seemed to be a rumble of "it can be done, but it won't be pretty" Am I missing a thread? Is this really the way we are planning on doing kernel-modules? Thanks Troy Dawson -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From tcallawa at redhat.com Wed Mar 2 19:46:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 02 Mar 2005 13:46:50 -0600 Subject: [Fedora-packaging] kernel-module rpm's - final decision? In-Reply-To: <4225EF1D.7090605@fnal.gov> References: <4225EF1D.7090605@fnal.gov> Message-ID: <1109792811.18846.12.camel@localhost.localdomain> On Wed, 2005-03-02 at 10:51 -0600, Troy Dawson wrote: >Hello, >As we are currently working on our openafs package, I want to make sure >our kernel modules for it conform to what was agreed upon. But other >than the naming, I didn't see a definate 'this is how to do them' list. > (If I missed that, point me to it) > >Here's what I saw. My example will be openafs, but I am meaning this >for others as well. > >Name: kernel-module-openafs >Version: 1.3.9 >Release: 2.6.9-5.0.3.EL.4 >Requires: kernel = 2.6.9-5.0.3.EL >Provides: kernel-module-openafs To be fair, we haven't finished the kernel-module-* naming and packaging guidelines. I've been busy. :/ I really think in order for kernel-module packages to be manageable (without disgusting yum and apt hacks), rpm needs to be able to do an "UpdateOnlyOne" operation. Right now, it can't do that, it can only "UpdateOneAndRemoveAllMatches". However, in the interim, I think the following guidelines should be good practice: Name: kernel-module-openafs (where the value in the Name field is the name of the module, prepended with "kernel-module-") Version: 1 (where the value in the Version field is equivalent to the kernel module version, NOT the kernel version we're building against) Release: %{kver}.1 (Where %{kver} is the kernel we're building against, and the .1 is a build revision, incremented if we need to make changes to the same version and kernel build) Requires: %{kver} (Do we need the additional "Provides: kernel-module-openafs", isn't that a given, since the Name: is the same?) %{kver} isn't a predefined macro, it should be passed at build time by the buildsystem (since there could presumably be multiple kernels in the build environment). Thoughts? ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Wed Mar 2 20:00:47 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 02 Mar 2005 14:00:47 -0600 Subject: [Fedora-packaging] kernel-module rpm's - final decision? In-Reply-To: <1109792811.18846.12.camel@localhost.localdomain> References: <4225EF1D.7090605@fnal.gov> <1109792811.18846.12.camel@localhost.localdomain> Message-ID: <1109793647.18846.15.camel@localhost.localdomain> On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote: >Requires: %{kver} Should be: Requires: kernel = %{kver} (This doesn't deal well with the SMP case (or arch specifics), I'm open to suggestions here. Maybe we should let RPM pick these deps up for itself?) ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Wed Mar 2 20:12:37 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 02 Mar 2005 22:12:37 +0200 Subject: [Fedora-packaging] kernel-module rpm's - final decision? In-Reply-To: <1109793647.18846.15.camel@localhost.localdomain> References: <4225EF1D.7090605@fnal.gov> <1109792811.18846.12.camel@localhost.localdomain> <1109793647.18846.15.camel@localhost.localdomain> Message-ID: <1109794357.15077.248.camel@bobcat.mine.nu> On Wed, 2005-03-02 at 14:00 -0600, Tom 'spot' Callaway wrote: > On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote: > > >Requires: %{kver} > > Should be: > > Requires: kernel = %{kver} > > (This doesn't deal well with the SMP case (or arch specifics), That won't really work, not even for the UP kernel, because it's not arch-qualified, and all variants (smp, xen*) have "Provides: kernel = $version" and would thus satisfy the dependency for a UP kernel module package. More verbose explanation and some suggestions: https://bugzilla.redhat.com/beta/show_bug.cgi?id=149249 From ville.skytta at iki.fi Wed Mar 2 20:18:45 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 02 Mar 2005 22:18:45 +0200 Subject: [Fedora-packaging] kernel-module rpm's - final decision? In-Reply-To: <1109792811.18846.12.camel@localhost.localdomain> References: <4225EF1D.7090605@fnal.gov> <1109792811.18846.12.camel@localhost.localdomain> Message-ID: <1109794725.15077.254.camel@bobcat.mine.nu> On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote: > (Do we need the additional "Provides: kernel-module-openafs", > isn't that a given, since the Name: is the same?) Right, not needed. I see there's no "Provides: kernel-modules" or somesuch, was that left out on purpose? From tcallawa at redhat.com Wed Mar 2 20:54:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 02 Mar 2005 14:54:39 -0600 Subject: [Fedora-packaging] kernel-module rpm's - final decision? In-Reply-To: <1109794725.15077.254.camel@bobcat.mine.nu> References: <4225EF1D.7090605@fnal.gov> <1109792811.18846.12.camel@localhost.localdomain> <1109794725.15077.254.camel@bobcat.mine.nu> Message-ID: <1109796879.18846.18.camel@localhost.localdomain> On Wed, 2005-03-02 at 22:18 +0200, Ville Skytt? wrote: >On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote: > >> (Do we need the additional "Provides: kernel-module-openafs", >> isn't that a given, since the Name: is the same?) > >Right, not needed. > >I see there's no "Provides: kernel-modules" or somesuch, was that left >out on purpose? If I'm not mistaken, that was used previously to flag the package as something that yum/apt/whatever needed to perform nasty hacks on. If thats all it serves, then lets not use it. I want to fix it in rpm so we don't need it. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From cra at WPI.EDU Wed Mar 2 23:32:44 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Wed, 2 Mar 2005 18:32:44 -0500 Subject: [Fedora-packaging] kernel-module rpm's - final decision? In-Reply-To: <1109794357.15077.248.camel@bobcat.mine.nu> References: <4225EF1D.7090605@fnal.gov> <1109792811.18846.12.camel@localhost.localdomain> <1109793647.18846.15.camel@localhost.localdomain> <1109794357.15077.248.camel@bobcat.mine.nu> Message-ID: <20050302233244.GP28055@angus.ind.WPI.EDU> On Wed, Mar 02, 2005 at 10:12:37PM +0200, Ville Skytt? wrote: > On Wed, 2005-03-02 at 14:00 -0600, Tom 'spot' Callaway wrote: > > On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote: > > > > >Requires: %{kver} > > > > Should be: > > > > Requires: kernel = %{kver} > > > > (This doesn't deal well with the SMP case (or arch specifics), > > That won't really work, not even for the UP kernel, because it's not > arch-qualified, and all variants (smp, xen*) have > "Provides: kernel = $version" and would thus satisfy the dependency for > a UP kernel module package. Wasn't there recent discussion about this? I thought the conclusion was that rawhide kernels Provides: kernel-%{arch} = %{version}-%{release} ? Ah, yes, here it is: On Mon, 21 Feb 2005 23:51:45 -0500, seth vidal wrote: > A couple of items to mention: > > new kernels in fc4 should have: > > Provides: kernel-%{arch} = ver-rel > > in them now. > > so kernel-modules should definitely dep on: > kernel-%{arch} so we don't get any arch mixups b/t kernels and > kernel-modules. > > -sv However, I don't see this in rawhide kernels yet: rpm -qp --provides kernel-2.6.10-1.1162_FC4.i686.rpm kernel = 2.6.10 kernel-drm = 4.3.0 kernel = 2.6.10-1.1162_FC4 rpm -qp --provides kernel-smp-2.6.10-1.1162_FC4.i686.rpm kernel = 2.6.10 kernel-drm = 4.3.0 kernel-smp = 2.6.10-1.1162_FC4 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 3 15:29:03 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Mar 2005 16:29:03 +0100 Subject: [Fedora-packaging] Removing all zero epochs from spec files in devel branch Message-ID: <20050303162903.65e86315@python2> Hi, 'nuff of all this. The subject says it all. I already asked for it *before* *any* Extras builds would start taking place. It didn't happen. But now I *want* it to happen before any FC4 Extras builds do. And I'll go through every single spec file alone if I need to. If anyone is _opposed_ to this change, please voice yourself now. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.770_FC3 Load : 0.30 0.17 0.21 From ville.skytta at iki.fi Thu Mar 3 18:02:57 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 03 Mar 2005 20:02:57 +0200 Subject: [Fedora-packaging] Removing all zero epochs from spec files in devel branch In-Reply-To: <20050303162903.65e86315@python2> References: <20050303162903.65e86315@python2> Message-ID: <1109872978.15077.291.camel@bobcat.mine.nu> On Thu, 2005-03-03 at 16:29 +0100, Matthias Saou wrote: > If anyone is _opposed_ to this change, please voice yourself now. As long as it triggers known bugs in the distro version where this action is targeted at, rpm in particular; I am. From gafton at redhat.com Thu Mar 3 18:11:44 2005 From: gafton at redhat.com (Cristian Gafton) Date: Thu, 3 Mar 2005 13:11:44 -0500 (EST) Subject: [Fedora-packaging] Removing all zero epochs from spec files in devel branch In-Reply-To: <1109872978.15077.291.camel@bobcat.mine.nu> References: <20050303162903.65e86315@python2> <1109872978.15077.291.camel@bobcat.mine.nu> Message-ID: On Thu, 3 Mar 2005, Ville [ISO-8859-1] Skytt? wrote: >> If anyone is _opposed_ to this change, please voice yourself now. > > As long as it triggers known bugs in the distro version where this > action is targeted at, rpm in particular; I am. I'd rather deal with the bugs than keep this thing around. It is embarassing to grown people that have packaged lots of stuff in their lifetimes. Plus, all current versions of rpm should deal with this issue correctly. The only stuff that breaks is the rpm --freshen on older releases of rpm. Did I mention that rpm has been security errata'd several times since? As I mentioned before, we're releasing these packages as part of a yum repository. If you download them manually from the web and use rpm --freshen instead of yum to update them, you get to keep all the broken pieces. I don't think we should care. A fringe usage gets a fringe result. So what? Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 3 18:14:09 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 3 Mar 2005 19:14:09 +0100 Subject: [Fedora-packaging] Removing all zero epochs from spec files in devel branch In-Reply-To: <1109872978.15077.291.camel@bobcat.mine.nu> References: <20050303162903.65e86315@python2> <1109872978.15077.291.camel@bobcat.mine.nu> Message-ID: <20050303191409.7985361e@python2> Ville Skytt? wrote : > On Thu, 2005-03-03 at 16:29 +0100, Matthias Saou wrote: > > > If anyone is _opposed_ to this change, please voice yourself now. > > As long as it triggers known bugs in the distro version where this > action is targeted at, rpm in particular; I am. I know jbj was still in Belgium until yesterday, but I don't know when he'll be back to check out spot's fix for that particular freshen issue, but I'll definitely be among the ones that will lobby him to push the fix into FC4. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.770_FC3 Load : 0.13 0.35 0.38 From tcallawa at redhat.com Thu Mar 3 18:11:41 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 03 Mar 2005 12:11:41 -0600 Subject: [Fedora-packaging] Removing all zero epochs from spec files in devel branch In-Reply-To: References: <20050303162903.65e86315@python2> <1109872978.15077.291.camel@bobcat.mine.nu> Message-ID: <1109873502.18846.94.camel@localhost.localdomain> On Thu, 2005-03-03 at 13:11 -0500, Cristian Gafton wrote: >Plus, all current versions of rpm should deal with this issue correctly. >The only stuff that breaks is the rpm --freshen on older releases of rpm. >Did I mention that rpm has been security errata'd several times since? No, current rpm --freshen breaks too. My patch has not been taken into rawhide rpm. I spoke to jbj about it this morning, and he responded by curling into his little "political bullshit" ball and insisting that he had to maintain existing freshen behavior for people that depend on it. Does anyone even use --freshen these days? I don't think yum/apt uses it... ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From pmatilai at welho.com Thu Mar 3 18:40:42 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 03 Mar 2005 20:40:42 +0200 Subject: [Fedora-packaging] Removing all zero epochs from spec files in devel branch In-Reply-To: <1109873502.18846.94.camel@localhost.localdomain> References: <20050303162903.65e86315@python2> <1109872978.15077.291.camel@bobcat.mine.nu> <1109873502.18846.94.camel@localhost.localdomain> Message-ID: <1109875243.13127.9.camel@chip.laiskiainen.org> On Thu, 2005-03-03 at 12:11 -0600, Tom 'spot' Callaway wrote: > On Thu, 2005-03-03 at 13:11 -0500, Cristian Gafton wrote: > > >Plus, all current versions of rpm should deal with this issue correctly. > >The only stuff that breaks is the rpm --freshen on older releases of rpm. > >Did I mention that rpm has been security errata'd several times since? > > No, current rpm --freshen breaks too. My patch has not been taken into > rawhide rpm. I spoke to jbj about it this morning, and he responded by > curling into his little "political bullshit" ball and insisting that he > had to maintain existing freshen behavior for people that depend on it. > > Does anyone even use --freshen these days? I don't think yum/apt uses > it... People using rpm --freshen to do these kind of upgrades are either nuts enough to deal with the breakage using a bit of shell-scripting or whatever or should be educated to use proper tools for the job, pick any depsolver you prefer (rpm --freshen is part of rpm cli operations, not rpmlib so none of the depsolvers are affected). Kill the damn zero epochs finally, pretty please. - Panu - From dawson at fnal.gov Thu Mar 3 19:06:20 2005 From: dawson at fnal.gov (Troy Dawson) Date: Thu, 03 Mar 2005 13:06:20 -0600 Subject: [Fedora-packaging] kernel-module rpm's - final decision? In-Reply-To: <1109794725.15077.254.camel@bobcat.mine.nu> References: <4225EF1D.7090605@fnal.gov> <1109792811.18846.12.camel@localhost.localdomain> <1109794725.15077.254.camel@bobcat.mine.nu> Message-ID: <4227602C.6060903@fnal.gov> Ville Skytt? wrote: > On Wed, 2005-03-02 at 13:46 -0600, Tom 'spot' Callaway wrote: > > >>(Do we need the additional "Provides: kernel-module-openafs", >>isn't that a given, since the Name: is the same?) > > > Right, not needed. > > I see there's no "Provides: kernel-modules" or somesuch, was that left > out on purpose? > Sorry about that. You are correct. When I was writting that I not only had up the e-mails from this list, but also a spec file from our older openafs kernel-module. I basically cut and pasted one too many. Troy p.s. Sorry for the delay, I wrote that e-mail and then got tied up in a bunch of other stuff. -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Mar 4 00:10:41 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 4 Mar 2005 01:10:41 +0100 Subject: [Fedora-packaging] Removing all zero epochs from spec files in devel branch In-Reply-To: <20050303162903.65e86315@python2> References: <20050303162903.65e86315@python2> Message-ID: <20050304011041.01e1cb91@python2> Matthias Saou wrote : > And I'll go through every single spec file alone if I need to. Checked manually _all_ spec files from "a" to "r" that contain the word "Epoch" somewhere. It's 1AM and I'm still in the office, so I'll stop for now before I start screwing too many spec files up... but I was dead serious when I wrote the above, and I should be done by tomorrow. Please don't hesitate to check some of the changes I've made, like Michael seems to be doing, as I've probably broken things here and there... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.770_FC3 Load : 0.64 0.52 0.50 From bugs.michael at gmx.net Fri Mar 4 16:12:19 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 4 Mar 2005 17:12:19 +0100 Subject: [Fedora-packaging] Conflicts Message-ID: <20050304171219.314d6026.bugs.michael@gmx.net> What is the official policy about packages in Fedora Extras which marked as conflicting with eachother? E.g. Sylpheed (dropped from Rawhide) and Sylpheed-claws share file names for main binary, manual page, pixmap file, desktop file. And since Sylpheed-claws is the feature-enhanced bleeding edge development fork of Sylpheed, there may be other conflicts. While this particular conflict could be resolved by renaming the files, this would be contrary to what upstream does. As another example, gpgme03-devel and gpgme-devel. Used to building in clean build environments where only the needed build requirements are pulled in, there was no need to relocate either package and make it possible to install both at once. I think there are other extras which conflict because they provide same or similar functionality, not limited to "leafnode" and "suck", "oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core). Where do we go from here? From tcallawa at redhat.com Fri Mar 4 16:45:56 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 04 Mar 2005 10:45:56 -0600 Subject: [Fedora-packaging] Conflicts In-Reply-To: <20050304171219.314d6026.bugs.michael@gmx.net> References: <20050304171219.314d6026.bugs.michael@gmx.net> Message-ID: <1109954756.17038.119.camel@localhost.localdomain> On Fri, 2005-03-04 at 17:12 +0100, Michael Schwendt wrote: >What is the official policy about packages in Fedora Extras which >marked as conflicting with eachother? > >E.g. Sylpheed (dropped from Rawhide) and Sylpheed-claws share file names >for main binary, manual page, pixmap file, desktop file. And since >Sylpheed-claws is the feature-enhanced bleeding edge development fork of >Sylpheed, there may be other conflicts. While this particular conflict >could be resolved by renaming the files, this would be contrary to what >upstream does. Packages in Extras should not conflict with packages in Core, when we're effectively talking about the same package. If foo-bar is just a newer version of foo, then it needs to be updated in Core (or moved to extras, where it can be foo-bar). >As another example, gpgme03-devel and gpgme-devel. Used to building >in clean build environments where only the needed build requirements >are pulled in, there was no need to relocate either package and make >it possible to install both at once. Hmm. I think in the case of foo3 and foo, if they need to be installed at the same time, they need to follow the openssl example, and not conflict. >I think there are other extras which conflict because they provide same >or similar functionality, not limited to "leafnode" and "suck", >"oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core). In some cases, we might be able to use the alternatives system, so that "identd" and "ftpd" are what we actually use, and have the rpms "Provide" the alternatives name. Then, the user can use alternatives to switch between the options. As usual, I'm open to suggestions on this. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From notting at redhat.com Fri Mar 4 17:29:45 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 4 Mar 2005 12:29:45 -0500 Subject: [Fedora-packaging] Conflicts In-Reply-To: <20050304171219.314d6026.bugs.michael@gmx.net> References: <20050304171219.314d6026.bugs.michael@gmx.net> Message-ID: <20050304172945.GB8420@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > What is the official policy about packages in Fedora Extras which > marked as conflicting with eachother? Conflicting packages are bad, period. Makes writing installers messy, as conflicts are done at the last stage of resolution. They really should be avoided if at all possible. > I think there are other extras which conflict because they provide same > or similar functionality, not limited to "leafnode" and "suck", > "oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core). Are these real physical conflicts, or merely things that provide similar functionality? Bill From ville.skytta at iki.fi Fri Mar 4 17:52:34 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 04 Mar 2005 19:52:34 +0200 Subject: [Fedora-packaging] Conflicts In-Reply-To: <1109954756.17038.119.camel@localhost.localdomain> References: <20050304171219.314d6026.bugs.michael@gmx.net> <1109954756.17038.119.camel@localhost.localdomain> Message-ID: <1109958754.15077.356.camel@bobcat.mine.nu> On Fri, 2005-03-04 at 10:45 -0600, Tom 'spot' Callaway wrote: > >As another example, gpgme03-devel and gpgme-devel. Used to building > >in clean build environments where only the needed build requirements > >are pulled in, there was no need to relocate either package and make > >it possible to install both at once. > > Hmm. I think in the case of foo3 and foo, if they need to be installed > at the same time, they need to follow the openssl example, and not > conflict. openssl is somewhat different, there's no -devel for the older one. Usually providing two different versions of lib packages without conflicts is fairly trivial, but a bit less so for their -devel subpackages. From bugs.michael at gmx.net Fri Mar 4 20:18:53 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 4 Mar 2005 21:18:53 +0100 Subject: [Fedora-packaging] Conflicts In-Reply-To: <20050304172945.GB8420@nostromo.devel.redhat.com> References: <20050304171219.314d6026.bugs.michael@gmx.net> <20050304172945.GB8420@nostromo.devel.redhat.com> Message-ID: <20050304211853.59a8c87c.bugs.michael@gmx.net> On Fri, 4 Mar 2005 12:29:45 -0500, Bill Nottingham wrote: > > What is the official policy about packages in Fedora Extras which > > marked as conflicting with eachother? > > Conflicting packages are bad, period. Makes writing installers > messy, as conflicts are done at the last stage of resolution. > > They really should be avoided if at all possible. > > > I think there are other extras which conflict because they provide same > > or similar functionality, not limited to "leafnode" and "suck", > > "oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core). > > Are these real physical conflicts, or merely things that provide > similar functionality? Either. To be investigated. I just ran grep on the devel tree in CVS. proftpd package listing looks like it conflicts physically, also with old wuftpd. gpgme-devel and gpgme03-devel (as well as sylpheed-claws and sylpheed) are physical conflicts. $ rpmlsv gpgme-devel -rwxr-xr-x root root 2755 /usr/bin/gpgme-config -rw-r--r-- root root 47745 /usr/include/gpgme.h -rw-r--r-- root root 264428 /usr/lib/libgpgme-pth.a lrwxrwxrwx root root 22 /usr/lib/libgpgme-pth.so -rw-r--r-- root root 264290 /usr/lib/libgpgme-pthread.a lrwxrwxrwx root root 26 /usr/lib/libgpgme-pthread.so -rw-r--r-- root root 268276 /usr/lib/libgpgme.a lrwxrwxrwx root root 18 /usr/lib/libgpgme.so -rw-r--r-- root root 8034 /usr/share/aclocal/gpgme.m4 -rw-r--r-- root root 55012 /usr/share/info/gpgme.info.gz As you can imagine, it could get ugly to relocate files like this and still make sure, API users still find them. gpgme03's only API/ABI user left is sylpheed-claws, which might catch up with main sylpheed GPGME 1.0 support soon. And then old gpgme03 can go for good. From bugs.michael at gmx.net Fri Mar 4 20:38:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 4 Mar 2005 21:38:30 +0100 Subject: [Fedora-packaging] NewPackageProcess, comment on Patch0 vs Patch Message-ID: <20050304213830.28887fc7.bugs.michael@gmx.net> http://fedoraproject.org/wiki/NewPackageProcess says: > Patches should start at Patch0, don't use Patch, even if you only have one > right now, because inevitably, you'll need another one at some point > before the sun explodes. What is the rationale? Patch: foo.patch Patch1: bar.patch # ... %patch -p1 -b .foo %patch1 -p1 -b .bar work just fine. 'Patch' == 'Patch0' is true. From notting at redhat.com Fri Mar 4 20:47:43 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 4 Mar 2005 15:47:43 -0500 Subject: [Fedora-packaging] Conflicts In-Reply-To: <20050304211853.59a8c87c.bugs.michael@gmx.net> References: <20050304171219.314d6026.bugs.michael@gmx.net> <20050304172945.GB8420@nostromo.devel.redhat.com> <20050304211853.59a8c87c.bugs.michael@gmx.net> Message-ID: <20050304204743.GA12456@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > As you can imagine, it could get ugly to relocate files like this and > still make sure, API users still find them. gpgme03's only API/ABI user > left is sylpheed-claws, which might catch up with main sylpheed GPGME 1.0 > support soon. And then old gpgme03 can go for good. The feature enhanced development version only supports the old library? That's funny. Frankly, I'm not sure what the point of having both in extras is; I would think just the main sylpheed package is enough. Bill From bugs.michael at gmx.net Fri Mar 4 20:59:13 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 4 Mar 2005 21:59:13 +0100 Subject: [Fedora-packaging] Conflicts In-Reply-To: <20050304204743.GA12456@nostromo.devel.redhat.com> References: <20050304171219.314d6026.bugs.michael@gmx.net> <20050304172945.GB8420@nostromo.devel.redhat.com> <20050304211853.59a8c87c.bugs.michael@gmx.net> <20050304204743.GA12456@nostromo.devel.redhat.com> Message-ID: <20050304215913.739d3a66.bugs.michael@gmx.net> On Fri, 4 Mar 2005 15:47:43 -0500, Bill Nottingham wrote: > > As you can imagine, it could get ugly to relocate files like this and > > still make sure, API users still find them. gpgme03's only API/ABI user > > left is sylpheed-claws, which might catch up with main sylpheed GPGME 1.0 > > support soon. And then old gpgme03 can go for good. > > The feature enhanced development version only supports the old > library? That's funny. > > Frankly, I'm not sure what the point of having both in extras is; > I would think just the main sylpheed package is enough. Extra features like support for Clamav, SpamAssassin, spell checking via aspell, many internal additions. I'd rather suggest renaming the few files in sylpheed-claws package, so it can coexist with stable sylpheed. Using Alternatives is overhead. And why should sylpheed-claws become /usr/bin/sylpheed? That is misleading if both packages can be installed at once. From gafton at redhat.com Fri Mar 4 21:11:16 2005 From: gafton at redhat.com (Cristian Gafton) Date: Fri, 4 Mar 2005 16:11:16 -0500 (EST) Subject: [Fedora-packaging] NewPackageProcess, comment on Patch0 vs Patch In-Reply-To: <20050304213830.28887fc7.bugs.michael@gmx.net> References: <20050304213830.28887fc7.bugs.michael@gmx.net> Message-ID: On Fri, 4 Mar 2005, Michael Schwendt wrote: >> Patches should start at Patch0, don't use Patch, even if you only have one >> right now, because inevitably, you'll need another one at some point >> before the sun explodes. > > What is the rationale? > > Patch: foo.patch > Patch1: bar.patch > # ... > %patch -p1 -b .foo > %patch1 -p1 -b .bar > > work just fine. 'Patch' == 'Patch0' is true. I am not sure what the rationale is. I always used just "Patch" and "%patch" when I only have one patch and later on I rename those to "Patch0" and "%patch0" when new patches are added. Having "Patch" and "Patch1" mixed up is unsightly, I agree. I would not mandate the usage of "Patch0" instead of "Patch" for packages with a single patch, but I would mandate that all patch lines be numbered for those with multiple patches. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From tcallawa at redhat.com Fri Mar 4 21:08:51 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 04 Mar 2005 15:08:51 -0600 Subject: [Fedora-packaging] NewPackageProcess, comment on Patch0 vs Patch In-Reply-To: <20050304213830.28887fc7.bugs.michael@gmx.net> References: <20050304213830.28887fc7.bugs.michael@gmx.net> Message-ID: <1109970532.17038.133.camel@localhost.localdomain> On Fri, 2005-03-04 at 21:38 +0100, Michael Schwendt wrote: >What is the rationale? > >Patch: foo.patch >Patch1: bar.patch ># ... >%patch -p1 -b .foo >%patch1 -p1 -b .bar > >work just fine. 'Patch' == 'Patch0' is true. It's stylistic. I think %patch0 is cleaner than %patch, and won't confuse new packagers who can assume that they can just do: Patch: foo Patch: bar %patch -p1 And to be honest, the NewPackageProcess apparently got created while I was asleep, from my "ExtrasPackageChecklist", which I wrote not as a standard, but as a cheat sheet for me. Don't assume it's a standards document worth following (yet). ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From toshio at tiki-lounge.com Fri Mar 4 21:13:49 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 4 Mar 2005 13:13:49 -0800 Subject: [Fedora-packaging] Conflicts In-Reply-To: <20050304204743.GA12456@nostromo.devel.redhat.com>; from notting@redhat.com on Fri, Mar 04, 2005 at 03:47:43PM -0500 References: <20050304171219.314d6026.bugs.michael@gmx.net> <20050304172945.GB8420@nostromo.devel.redhat.com> <20050304211853.59a8c87c.bugs.michael@gmx.net> <20050304204743.GA12456@nostromo.devel.redhat.com> Message-ID: <20050304131349.A16775@tiki-lounge.com> On Fri, Mar 04, 2005 at 03:47:43PM -0500, Bill Nottingham wrote: > Michael Schwendt (bugs.michael at gmx.net) said: > > As you can imagine, it could get ugly to relocate files like this and > > still make sure, API users still find them. gpgme03's only API/ABI user > > left is sylpheed-claws, which might catch up with main sylpheed GPGME 1.0 > > support soon. And then old gpgme03 can go for good. > > The feature enhanced development version only supports the old > library? That's funny. > Mea culpa. Sylpheed was in Core and I wanted gpgme-1.0 in Core so I patched it to use the newer gpgme and it was accepted upstream. Now sylpheed's out and we still don't have gpgme-1.0 in Core. (kmail uses it...) > Frankly, I'm not sure what the point of having both in extras is; > I would think just the main sylpheed package is enough. > claws and sylpeed are a little further apart than branches, a bit closer than an actual fork. Someone might find it worthwhile to package each one separately. Right now, I don't think anyone's picked up the main sylpheed. If someone does, I think the right thing to do is rename files in sylpheed-claws to not conflict. -Toshio From bugs.michael at gmx.net Fri Mar 4 21:42:18 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 4 Mar 2005 22:42:18 +0100 Subject: [Fedora-packaging] Conflicts In-Reply-To: <20050304131349.A16775@tiki-lounge.com> References: <20050304171219.314d6026.bugs.michael@gmx.net> <20050304172945.GB8420@nostromo.devel.redhat.com> <20050304211853.59a8c87c.bugs.michael@gmx.net> <20050304204743.GA12456@nostromo.devel.redhat.com> <20050304131349.A16775@tiki-lounge.com> Message-ID: <20050304224218.463c903f.bugs.michael@gmx.net> On Fri, 4 Mar 2005 13:13:49 -0800, Toshio Kuratomi wrote: > Mea culpa. Sylpheed was in Core and I wanted gpgme-1.0 in Core so I patched > it to use the newer gpgme and it was accepted upstream. Now sylpheed's out > and we still don't have gpgme-1.0 in Core. (kmail uses it...) GnuPG 2 is not ready. Hence GPGME 1.0.x could not be built with the S/MIME part (aka GPGSM). From bugs.michael at gmx.net Fri Mar 4 21:44:19 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 4 Mar 2005 22:44:19 +0100 Subject: [Fedora-packaging] NewPackageProcess, comment on Patch0 vs Patch In-Reply-To: <1109970532.17038.133.camel@localhost.localdomain> References: <20050304213830.28887fc7.bugs.michael@gmx.net> <1109970532.17038.133.camel@localhost.localdomain> Message-ID: <20050304224419.53711a8e.bugs.michael@gmx.net> On Fri, 04 Mar 2005 15:08:51 -0600, Tom 'spot' Callaway wrote: > >What is the rationale? > > > >Patch: foo.patch > >Patch1: bar.patch > ># ... > >%patch -p1 -b .foo > >%patch1 -p1 -b .bar > > > >work just fine. 'Patch' == 'Patch0' is true. > > It's stylistic. Okay, that's all I wanted to know. From toshio at tiki-lounge.com Sat Mar 5 00:52:40 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 4 Mar 2005 16:52:40 -0800 Subject: [Fedora-packaging] Conflicts In-Reply-To: <20050304224218.463c903f.bugs.michael@gmx.net>; from bugs.michael@gmx.net on Fri, Mar 04, 2005 at 10:42:18PM +0100 References: <20050304171219.314d6026.bugs.michael@gmx.net> <20050304172945.GB8420@nostromo.devel.redhat.com> <20050304211853.59a8c87c.bugs.michael@gmx.net> <20050304204743.GA12456@nostromo.devel.redhat.com> <20050304131349.A16775@tiki-lounge.com> <20050304224218.463c903f.bugs.michael@gmx.net> Message-ID: <20050304165240.A25484@tiki-lounge.com> On Fri, Mar 04, 2005 at 10:42:18PM +0100, Michael Schwendt wrote: > On Fri, 4 Mar 2005 13:13:49 -0800, Toshio Kuratomi wrote: > > > Mea culpa. Sylpheed was in Core and I wanted gpgme-1.0 in Core so I patched > > it to use the newer gpgme and it was accepted upstream. Now sylpheed's out > > and we still don't have gpgme-1.0 in Core. (kmail uses it...) > > GnuPG 2 is not ready. Hence GPGME 1.0.x could not be built with the S/MIME > part (aka GPGSM). > True. But gpgme doesn't have a hard requirement on gnupg 2. In line with the two steps forward, one step backwards philosophy, I'd be happy with a gpgme-1 that only uses gnupg-1 and add S/Mime features when gnupg 2 is ready. This gets us a kmail with some signing support. OTOH, I mainly want to use gpgme in my code, not for any mailer. So for me, Extras is good enough. -Toshio From bugs.michael at gmx.net Sat Mar 5 02:02:18 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 5 Mar 2005 03:02:18 +0100 Subject: [Fedora-packaging] Conflicts In-Reply-To: <20050304165240.A25484@tiki-lounge.com> References: <20050304171219.314d6026.bugs.michael@gmx.net> <20050304172945.GB8420@nostromo.devel.redhat.com> <20050304211853.59a8c87c.bugs.michael@gmx.net> <20050304204743.GA12456@nostromo.devel.redhat.com> <20050304131349.A16775@tiki-lounge.com> <20050304224218.463c903f.bugs.michael@gmx.net> <20050304165240.A25484@tiki-lounge.com> Message-ID: <20050305030218.5bb7f629.bugs.michael@gmx.net> On Fri, 4 Mar 2005 16:52:40 -0800, Toshio Kuratomi wrote: > > > Mea culpa. Sylpheed was in Core and I wanted gpgme-1.0 in Core so I patched > > > it to use the newer gpgme and it was accepted upstream. Now sylpheed's out > > > and we still don't have gpgme-1.0 in Core. (kmail uses it...) > > > > GnuPG 2 is not ready. Hence GPGME 1.0.x could not be built with the S/MIME > > part (aka GPGSM). > > > True. But gpgme doesn't have a hard requirement on gnupg 2. In line with > the two steps forward, one step backwards philosophy, I'd be happy with a > gpgme-1 that only uses gnupg-1 and add S/Mime features when gnupg 2 is > ready. This gets us a kmail with some signing support. OTOH, I mainly > want to use gpgme in my code, not for any mailer. So for me, Extras > is good enough. Last time I looked, kmail was built with an internal GPGME 0.4.4 copy, and its OpenPGP features worked for me. $ rpmlsv kdepim |grep -i gpgme -rwxr-xr-x root root 787 /usr/lib/libgpgme++.la lrwxrwxrwx root root 19 /usr/lib/libgpgme++.so.0 -rwxr-xr-x root root 228304 /usr/lib/libgpgme++.so.0.0.0 -rwxr-xr-x root root 906 /usr/lib/libqgpgme.la lrwxrwxrwx root root 18 /usr/lib/libqgpgme.so.0 -rwxr-xr-x root root 20048 /usr/lib/libqgpgme.so.0.0.0 drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme/html From toshio at tiki-lounge.com Sat Mar 5 15:50:34 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 5 Mar 2005 07:50:34 -0800 Subject: local internal libraries (Was Re: [Fedora-packaging] Conflicts) In-Reply-To: <20050305030218.5bb7f629.bugs.michael@gmx.net>; from bugs.michael@gmx.net on Sat, Mar 05, 2005 at 03:02:18AM +0100 References: <20050304171219.314d6026.bugs.michael@gmx.net> <20050304172945.GB8420@nostromo.devel.redhat.com> <20050304211853.59a8c87c.bugs.michael@gmx.net> <20050304204743.GA12456@nostromo.devel.redhat.com> <20050304131349.A16775@tiki-lounge.com> <20050304224218.463c903f.bugs.michael@gmx.net> <20050304165240.A25484@tiki-lounge.com> <20050305030218.5bb7f629.bugs.michael@gmx.net> Message-ID: <20050305075034.A4787@tiki-lounge.com> On Sat, Mar 05, 2005 at 03:02:18AM +0100, Michael Schwendt wrote: > > Last time I looked, kmail was built with an internal GPGME 0.4.4 copy, > and its OpenPGP features worked for me. > > $ rpmlsv kdepim |grep -i gpgme > -rwxr-xr-x root root 787 /usr/lib/libgpgme++.la > lrwxrwxrwx root root 19 /usr/lib/libgpgme++.so.0 > -rwxr-xr-x root root 228304 /usr/lib/libgpgme++.so.0.0.0 > -rwxr-xr-x root root 906 /usr/lib/libqgpgme.la > lrwxrwxrwx root root 18 /usr/lib/libqgpgme.so.0 > -rwxr-xr-x root root 20048 /usr/lib/libqgpgme.so.0.0.0 > drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme > drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme/html Oops. I've been misreading bug number 136533, which is actually asking only for Certificate Handling, not all OpenPGP support. This brings up a new question, though. What are good justifications for using an internal library vs creating a system one? In this case, I think the internal library solves these problems: 1) Allows Core to be updated with a feature enhanced (gnuPG2) version from Extras. 2) Brings gpgme support to kmail without fussing with another package that is presently only needed by kmail. A) Doesn't apply in this case, but could help resolve version conflicts. (Example is sylpheed/claws gpgme requirements. Because claws requires gpgme03 to compile, creating a gpgme03 package is not enough; we also need the -devel package which conflicts with gpgme-1.0. Compiling against an internal gpgme03 would solve this.) But it has these problems: 1) Increased size for someone who installs gpgme from Extras. A) Extras packages can use gpgme. Mixed bag as Core's gpgme would be built without S/MIME. 2) kmail does not get S/MIME features when gpgme from Extras is installed. 3) kmail does not get updated bugfixes/security fixes unless the kdepim packager updates to new gpgme versions (In this case, gpgme is version 1.0.2 and kmail is using 0.9.. only four versions out of date.) Here are some ideas for guidelines: Applications should have local, internal copies of libraries if: 1) It is the best way to resolve a version conflict with a libary update that requires API changes because the two versions do not have parallel installable devel files (sylpheed-claws). 2) The application is in Core and the library would conflict with another library package in Extras that cannot move to Core. Reasons for this could include: A) Library in Extras is deemed unstable for inclusion in Core but a feature reduced version/other version will work. (kdepim/kmail) When a package uses a local, internal library it should: 1) Be listed somewhere (fedoraproject.org/wiki page?) as using a local, internal version of the library with version and reason. Open question: How much burden does the maintainer of the package with a local, internal library carry for updating the internal library? Who else would carry it if not the maintainer of the package? Can automated tools to tell of updates to the main library package help the package maintainer? -Toshio From herrold at owlriver.com Mon Mar 7 19:00:35 2005 From: herrold at owlriver.com (R P Herrold) Date: Mon, 7 Mar 2005 14:00:35 -0500 (EST) Subject: [Fedora-packaging] Removing all zero epochs from spec files in devel branch In-Reply-To: <1109873502.18846.94.camel@localhost.localdomain> References: <20050303162903.65e86315@python2> <1109872978.15077.291.camel@bobcat.mine.nu> <1109873502.18846.94.camel@localhost.localdomain> Message-ID: On Thu, 3 Mar 2005, Tom 'spot' Callaway wrote: > Does anyone even use --freshen these days? I don't think yum/apt uses > it... yes - some of my scripting does, without significant incident -- Russ Herrold From bugs.michael at gmx.net Mon Mar 7 19:19:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 7 Mar 2005 20:19:22 +0100 Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras Message-ID: <20050307201922.3629845e.bugs.michael@gmx.net> X-Fedora : most packages imported from fedora.us use this in the desktop files X-Fedora-Extra : a dozen packages switched to it X-Fedora-Extras : package "logjam" uses it Which one do we use from now on? I would assume X-Red-Hat-Extras => X-Fedora-Extra, but it would sound dumb. From bugs.michael at gmx.net Mon Mar 7 19:31:57 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 7 Mar 2005 20:31:57 +0100 Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: <20050307201922.3629845e.bugs.michael@gmx.net> References: <20050307201922.3629845e.bugs.michael@gmx.net> Message-ID: <20050307203157.5e176974.bugs.michael@gmx.net> On Mon, 7 Mar 2005 20:19:22 +0100, Michael Schwendt wrote: > X-Fedora : most packages imported from fedora.us use this in the > desktop files > > X-Fedora-Extra : a dozen packages switched to it > > X-Fedora-Extras : package "logjam" uses it > > > Which one do we use from now on? > > I would assume X-Red-Hat-Extras => X-Fedora-Extra, but it would > sound dumb. Damn typos. Meant to write: ... X-Red-Hat-Extra => X-Fedora-Extra ... From tcallawa at redhat.com Tue Mar 8 02:59:39 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 07 Mar 2005 20:59:39 -0600 Subject: [Fedora-packaging] Removing all zero epochs from spec files in devel branch In-Reply-To: References: <20050303162903.65e86315@python2> <1109872978.15077.291.camel@bobcat.mine.nu> <1109873502.18846.94.camel@localhost.localdomain> Message-ID: <1110250779.4350.27.camel@localhost.localdomain> On Mon, 2005-03-07 at 14:00 -0500, R P Herrold wrote: >On Thu, 3 Mar 2005, Tom 'spot' Callaway wrote: > >> Does anyone even use --freshen these days? I don't think yum/apt uses >> it... > >yes - some of my scripting does, without significant incident Then you should lean hard on jbj to take my patchfix for freshening in an epoch corner case (https://bugzilla.redhat.com/beta/show_bug.cgi?id=143301). Since we've removed all the Epoch: 0 references in Extras, you will almost definitely hit this bug. I tried already. If it affects you, you should try. :) ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Tue Mar 8 03:03:54 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 07 Mar 2005 21:03:54 -0600 Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: <20050307203157.5e176974.bugs.michael@gmx.net> References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> Message-ID: <1110251035.4350.32.camel@localhost.localdomain> On Mon, 2005-03-07 at 20:31 +0100, Michael Schwendt wrote: >On Mon, 7 Mar 2005 20:19:22 +0100, Michael Schwendt wrote: > >> X-Fedora : most packages imported from fedora.us use this in the >> desktop files >> >> X-Fedora-Extra : a dozen packages switched to it >> >> X-Fedora-Extras : package "logjam" uses it logjam is mine, I must be right! Seriously though, I don't care. We should pick one and be done with it. If we don't want to draw any distinction, then "X-Fedora" is fine for everyone, and I think that should be the standard for both Core and Extras. Anyone opposed? ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From dag at wieers.com Tue Mar 8 03:29:29 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 8 Mar 2005 04:29:29 +0100 (CET) Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: <1110251035.4350.32.camel@localhost.localdomain> References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> Message-ID: On Mon, 7 Mar 2005, Tom 'spot' Callaway wrote: > On Mon, 2005-03-07 at 20:31 +0100, Michael Schwendt wrote: > >On Mon, 7 Mar 2005 20:19:22 +0100, Michael Schwendt wrote: > > > >> X-Fedora : most packages imported from fedora.us use this in the > >> desktop files > >> > >> X-Fedora-Extra : a dozen packages switched to it > >> > >> X-Fedora-Extras : package "logjam" uses it > > logjam is mine, I must be right! > > Seriously though, I don't care. We should pick one and be done with it. > > If we don't want to draw any distinction, then "X-Fedora" is fine for > everyone, and I think that should be the standard for both Core and > Extras. Anyone opposed? RPMforge uses X-Red-Hat-Base everywhere. Should we be worried ? :) What's the effect of changing the category, what is it used for ? Or are there any plans to use this in the future ? It may make a difference. If it's a branding kind of thing, we might want to make a macro out of it. RPMforge uses %{desktop_vendor} already when using desktop-file-utils so people can rebrand packages if they care. Any opinions about both ? -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From bugs.michael at gmx.net Tue Mar 8 04:29:24 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 8 Mar 2005 05:29:24 +0100 Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> Message-ID: <20050308052924.505d7214.bugs.michael@gmx.net> On Tue, 8 Mar 2005 04:29:29 +0100 (CET), Dag Wieers wrote: > RPMforge uses X-Red-Hat-Base everywhere. Should we be worried ? :) > What's the effect of changing the category, what is it used for ? X-Red-Hat-Base puts a desktop menu entry into the top menu, while X-Red-Hat-Extra marks desktop menu entries which appear in the "More ..." sub-menus. X-Fedora is just a placeholder. From dag at wieers.com Tue Mar 8 04:45:39 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 8 Mar 2005 05:45:39 +0100 (CET) Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: <20050308052924.505d7214.bugs.michael@gmx.net> References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> <20050308052924.505d7214.bugs.michael@gmx.net> Message-ID: On Tue, 8 Mar 2005, Michael Schwendt wrote: > On Tue, 8 Mar 2005 04:29:29 +0100 (CET), Dag Wieers wrote: > > > RPMforge uses X-Red-Hat-Base everywhere. Should we be worried ? :) > > What's the effect of changing the category, what is it used for ? > > X-Red-Hat-Base puts a desktop menu entry into the top menu, while > X-Red-Hat-Extra marks desktop menu entries which appear in the > "More ..." sub-menus. X-Fedora is just a placeholder. I don't like a meaningless placeholder. Either we anticipate a change in the future and we should define that use (having a single identifier for all packages makes no sense). Or we drop it. X-Red-Hat-Base and X-Red-Hat-Extra has a meaning, although I'm not sure why it includes 'Red-Hat'. Maybe we need a policy of what is expected in the first level menu, and what in the second. (Or another scheme). PS I don't have any 'More...' submenus on my FC3 even though some of the desktop-files do use X-Red-Hat-Extra. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From wtogami at redhat.com Tue Mar 8 05:05:20 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 07 Mar 2005 19:05:20 -1000 Subject: [Fedora-packaging] No modifying %{SOURCE} during rpmbuild Message-ID: <422D3290.3010703@redhat.com> No modifying %{SOURCE*} during rpmbuild. Stuff included in %{SOURCE*} must not be modified during rpmbuild because the resulting .src.rpm will contain the modified version, not original. You should instead make a copy, then modify that copy. Example from gaim.spec: # If not using gnome-open, then default to htmlview +cp %{SOURCE1} prefs.xml if [ "%{gnome_open_integration}" == "0" ]; then - sed -i "s/gnome-open/custom/g" %{SOURCE1} - sed -i "s/pref name='command' type='string' value=''/pref name='command' type='string' value='htmlview'/" %{SOURCE1} + sed -i "s/gnome-open/custom/g" prefs.xml + sed -i "s/pref name='command' type='string' value=''/pref name='command' type='string' value='htmlview'/" prefs.xml fi Warren Togami wtogami at redhat.com From gafton at redhat.com Tue Mar 8 05:49:08 2005 From: gafton at redhat.com (Cristian Gafton) Date: Tue, 8 Mar 2005 00:49:08 -0500 (EST) Subject: [Fedora-packaging] No modifying %{SOURCE} during rpmbuild In-Reply-To: <422D3290.3010703@redhat.com> References: <422D3290.3010703@redhat.com> Message-ID: On Mon, 7 Mar 2005, Warren Togami wrote: > No modifying %{SOURCE*} during rpmbuild. Well, DUH! > > Stuff included in %{SOURCE*} must not be modified during rpmbuild > because the resulting .src.rpm will contain the modified version, not > original. You should instead make a copy, then modify that copy. > > Example from gaim.spec: > # If not using gnome-open, then default to htmlview > +cp %{SOURCE1} prefs.xml > if [ "%{gnome_open_integration}" == "0" ]; then > - sed -i "s/gnome-open/custom/g" %{SOURCE1} > - sed -i "s/pref name='command' type='string' value=''/pref > name='command' type='string' value='htmlview'/" %{SOURCE1} > + sed -i "s/gnome-open/custom/g" prefs.xml > + sed -i "s/pref name='command' type='string' value=''/pref > name='command' type='string' value='htmlview'/" prefs.xml > fi > > Warren Togami > wtogami at redhat.com > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From bugs.michael at gmx.net Tue Mar 8 07:56:06 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 8 Mar 2005 08:56:06 +0100 Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> <20050308052924.505d7214.bugs.michael@gmx.net> Message-ID: <20050308085606.09cba857.bugs.michael@gmx.net> On Tue, 8 Mar 2005 05:45:39 +0100 (CET), Dag Wieers wrote: > > > RPMforge uses X-Red-Hat-Base everywhere. Should we be worried ? :) > > > What's the effect of changing the category, what is it used for ? > > > > X-Red-Hat-Base puts a desktop menu entry into the top menu, while > > X-Red-Hat-Extra marks desktop menu entries which appear in the > > "More ..." sub-menus. X-Fedora is just a placeholder. > > I don't like a meaningless placeholder. It's not meaningless. X-Fedora has been used to mark menu entries as coming from Fedora Linux. Whether it is evaluated somewhere is implementation dependent. X-Red-Hat-Extra is not evaluated either, I think. Only X-Red-Hat-Base provides the special function of placing menu entries in the top-level menu. X-Fedora-Extra or X-Fedora-Extras would mark menu entries as coming from Fedora Extras and would distinguish them from manually installed ones. A desktop menu editor might put such markers to good effect. > Either we anticipate a change in > the future and we should define that use (having a single identifier for > all packages makes no sense). Or we drop it. > > X-Red-Hat-Base and X-Red-Hat-Extra has a meaning, although I'm not sure > why it includes 'Red-Hat'. Maybe we need a policy of what is expected in > the first level menu, and what in the second. (Or another scheme). > > PS I don't have any 'More...' submenus on my FC3 even though some of the > desktop-files do use X-Red-Hat-Extra. FC3 KDE has "Preferences > More Preferences" here, where the categorisation works, too. I think X-Red-Hat-Extra is from older times, such as Red Hat Linux 8.0, where real "Extras" submenus existed. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 8 08:26:22 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 8 Mar 2005 09:26:22 +0100 Subject: [Fedora-packaging] No modifying %{SOURCE} during rpmbuild In-Reply-To: <422D3290.3010703@redhat.com> References: <422D3290.3010703@redhat.com> Message-ID: <20050308092622.1d3ca330@python2> Warren Togami wrote : > No modifying %{SOURCE*} during rpmbuild. Same as gafton ;-) > if [ "%{gnome_open_integration}" == "0" ]; then And the test command should be used properly : - String comparison should use the equal sign and others - Integer comparison should use -eq and others - AFAIK "==" isn't documented for the test command, it's definitely a "programmer-ism" :-D Strange, though, I just noticed that on my FC3 system, [ is no longer a symlink to test as it used to be, and both files have the same timestamp but different sized. Yet another minor detail anyway ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.770_FC3 Load : 0.24 0.26 0.66 From dag at wieers.com Tue Mar 8 14:28:11 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 8 Mar 2005 15:28:11 +0100 (CET) Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: <20050308085606.09cba857.bugs.michael@gmx.net> References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> <20050308052924.505d7214.bugs.michael@gmx.net> <20050308085606.09cba857.bugs.michael@gmx.net> Message-ID: On Tue, 8 Mar 2005, Michael Schwendt wrote: > On Tue, 8 Mar 2005 05:45:39 +0100 (CET), Dag Wieers wrote: > > > > > RPMforge uses X-Red-Hat-Base everywhere. Should we be worried ? :) > > > > What's the effect of changing the category, what is it used for ? > > > > > > X-Red-Hat-Base puts a desktop menu entry into the top menu, while > > > X-Red-Hat-Extra marks desktop menu entries which appear in the > > > "More ..." sub-menus. X-Fedora is just a placeholder. > > > > I don't like a meaningless placeholder. > > It's not meaningless. X-Fedora has been used to mark menu entries as > coming from Fedora Linux. Whether it is evaluated somewhere is > implementation dependent. X-Red-Hat-Extra is not evaluated either, I > think. Only X-Red-Hat-Base provides the special function of placing menu > entries in the top-level menu. > > X-Fedora-Extra or X-Fedora-Extras would mark menu entries as coming from > Fedora Extras and would distinguish them from manually installed ones. > A desktop menu editor might put such markers to good effect. I understand that. With meaningless I meant that I don't see good use for users to distinguish a Fedora Extras and a non-Fedora-Extras package. What do you think would people do with this information ? I'd like to implement something that has a direct benefit, which I do not see here. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From bugs.michael at gmx.net Tue Mar 8 16:25:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 8 Mar 2005 17:25:40 +0100 Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> <20050308052924.505d7214.bugs.michael@gmx.net> <20050308085606.09cba857.bugs.michael@gmx.net> Message-ID: <20050308172540.6701f303.bugs.michael@gmx.net> On Tue, 8 Mar 2005 15:28:11 +0100 (CET), Dag Wieers wrote: > > X-Fedora-Extra or X-Fedora-Extras would mark menu entries as coming from > > Fedora Extras and would distinguish them from manually installed ones. > > A desktop menu editor might put such markers to good effect. > > I understand that. With meaningless I meant that I don't see good use for > users to distinguish a Fedora Extras and a non-Fedora-Extras package. What > do you think would people do with this information ? I'd like to implement > something that has a direct benefit, which I do not see here. X-Red-Hat-Extra has no direct benefit either. Still it adds a special category to menu entries, which are not considered the base distribution's preferred/primary applications. Wether it is the default to put all menu entries, which are not categorised as X-Red-Hat-Base, into submenus [if implemented] or if this is done explicitly based on a special X-category, is not the point of discussion IMO. The availability of the extra category allows for such operations, whether implemented today or in the future. As I tried to point out above, in a powerful menu editor, you could say "also put Extras into the top-level menu", or "move all extras into 'More...' submenus" or "move all extras into a separate 'Extras' menu hierarchy" to clean up overloaded menus. From dag at wieers.com Tue Mar 8 17:01:06 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 8 Mar 2005 18:01:06 +0100 (CET) Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: <20050308172540.6701f303.bugs.michael@gmx.net> References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> <20050308052924.505d7214.bugs.michael@gmx.net> <20050308085606.09cba857.bugs.michael@gmx.net> <20050308172540.6701f303.bugs.michael@gmx.net> Message-ID: On Tue, 8 Mar 2005, Michael Schwendt wrote: > On Tue, 8 Mar 2005 15:28:11 +0100 (CET), Dag Wieers wrote: > > > > X-Fedora-Extra or X-Fedora-Extras would mark menu entries as coming from > > > Fedora Extras and would distinguish them from manually installed ones. > > > A desktop menu editor might put such markers to good effect. > > > > I understand that. With meaningless I meant that I don't see good use for > > users to distinguish a Fedora Extras and a non-Fedora-Extras package. What > > do you think would people do with this information ? I'd like to implement > > something that has a direct benefit, which I do not see here. > > X-Red-Hat-Extra has no direct benefit either. Still it adds a special > category to menu entries, which are not considered the base distribution's > preferred/primary applications. Wether it is the default to put all menu > entries, which are not categorised as X-Red-Hat-Base, into submenus [if > implemented] or if this is done explicitly based on a special X-category, > is not the point of discussion IMO. The availability of the extra category > allows for such operations, whether implemented today or in the future. > As I tried to point out above, in a powerful menu editor, you could say > "also put Extras into the top-level menu", or "move all extras into > 'More...' submenus" or "move all extras into a separate 'Extras' menu > hierarchy" to clean up overloaded menus. Michael, my point is, if almost everything will be in Extras, what use does it have to tag them the same way ? I'd much rather have something explicit for that purpose, like: TopLevel SubLevel Than something that you will use as a default tag but has no practical use other than this. In fact, if there are other uses besides the TopLevel/SubLevel and the real category, I'd much rather have those explicitly defined and named now too :) Maybe: Novice Advanced Expert would be a useful tag to put on applications. Or Stable Unstable (or Beta) I don't know. I bet people can come up with other tags that may be useful. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From pnasrat at redhat.com Tue Mar 8 17:03:05 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 08 Mar 2005 17:03:05 +0000 Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> <20050308052924.505d7214.bugs.michael@gmx.net> <20050308085606.09cba857.bugs.michael@gmx.net> <20050308172540.6701f303.bugs.michael@gmx.net> Message-ID: <1110301385.5739.5.camel@anu.eridu> On Tue, 2005-03-08 at 18:01 +0100, Dag Wieers wrote: > On Tue, 8 Mar 2005, Michael Schwendt wrote: > > > On Tue, 8 Mar 2005 15:28:11 +0100 (CET), Dag Wieers wrote: > > > Michael, my point is, if almost everything will be in Extras, what use > does it have to tag them the same way ? I'd much rather have something > explicit for that purpose, like: > > TopLevel > SubLevel > > Than something that you will use as a default tag but has no practical > use other than this. In fact, if there are other uses besides the > TopLevel/SubLevel and the real category, I'd much rather have those > explicitly defined and named now too :) > > Maybe: > > Novice > Advanced > Expert > > would be a useful tag to put on applications. Or > > Stable > Unstable (or Beta) This sounds like freedesktop.org discussion. Lobbying for stuff should happen there IMHO. Paul From Nicolas.Mailhot at laPoste.net Tue Mar 8 18:28:16 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 08 Mar 2005 19:28:16 +0100 Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> <20050308052924.505d7214.bugs.michael@gmx.net> <20050308085606.09cba857.bugs.michael@gmx.net> <20050308172540.6701f303.bugs.michael@gmx.net> Message-ID: <1110306496.25559.24.camel@rousalka.dyndns.org> Le mardi 08 mars 2005 ? 18:01 +0100, Dag Wieers a ?crit : > Michael, my point is, if almost everything will be in Extras, what use > does it have to tag them the same way ? I'd much rather have something > explicit for that purpose, like: > > TopLevel > SubLevel > > Than something that you will use as a default tag but has no practical > use other than this. In fact, if there are other uses besides the > TopLevel/SubLevel and the real category, I'd much rather have those > explicitly defined and named now too :) I disagree. If you put very explicit stuff like this in each menu entry you spread policy over a large number of packages. That makes it real hard to change it later. Much better to put informative stuff here and have the centralised menu logic decide what to do with it (and I hope someday each individual system user will be able to decide things like "I want all entries with this tag in a separate menu" or "I want all stuff with this tag to be hidden" etc) Regards, -- Nicolas Mailhot -------------- 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 dag at wieers.com Tue Mar 8 18:38:04 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 8 Mar 2005 19:38:04 +0100 (CET) Subject: [Fedora-packaging] X-Fedora vs. X-Fedora-Extra vs. X-Fedora-Extras In-Reply-To: <1110306496.25559.24.camel@rousalka.dyndns.org> References: <20050307201922.3629845e.bugs.michael@gmx.net> <20050307203157.5e176974.bugs.michael@gmx.net> <1110251035.4350.32.camel@localhost.localdomain> <20050308052924.505d7214.bugs.michael@gmx.net> <20050308085606.09cba857.bugs.michael@gmx.net> <20050308172540.6701f303.bugs.michael@gmx.net> <1110306496.25559.24.camel@rousalka.dyndns.org> Message-ID: On Tue, 8 Mar 2005, Nicolas Mailhot wrote: > Le mardi 08 mars 2005 ? 18:01 +0100, Dag Wieers a ?crit : > > > Michael, my point is, if almost everything will be in Extras, what use > > does it have to tag them the same way ? I'd much rather have something > > explicit for that purpose, like: > > > > TopLevel > > SubLevel > > > > Than something that you will use as a default tag but has no practical > > use other than this. In fact, if there are other uses besides the > > TopLevel/SubLevel and the real category, I'd much rather have those > > explicitly defined and named now too :) > > I disagree. If you put very explicit stuff like this in each menu entry > you spread policy over a large number of packages. That makes it real > hard to change it later. Policy is decided later based on the tags. I don't put policy inside of the packages. But you have to have something to hold on to. > Much better to put informative stuff here and have the centralised menu > logic decide what to do with it (and I hope someday each individual > system user will be able to decide things like "I want all entries with > this tag in a separate menu" or "I want all stuff with this tag to be > hidden" etc) Sure, that's the aim. But you won't be able to do that with a generic X-Fedora-Extra tag that matches 95% of your packages. You have to have descriptive tags to base a policy on, what else do you have ? But as Paul said, maybe this discussion belongs to freedesktop.org. The question remains, what is the use of X-Fedora-Extra if all packages are tagged with it. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From skvidal at phy.duke.edu Thu Mar 10 19:45:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 10 Mar 2005 14:45:08 -0500 Subject: [Fedora-packaging] Re: note about packaging init scripts In-Reply-To: <20050310194258.GA5034@nostromo.devel.redhat.com> References: <20050310194258.GA5034@nostromo.devel.redhat.com> Message-ID: <1110483908.19164.23.camel@opus.phy.duke.edu> On Thu, 2005-03-10 at 14:42 -0500, Bill Nottingham wrote: > If you are packaging init scripts with a file path of > /etc/init.d/your_script > you *need* to either: > > a) prereq chkconfig (even if you don't call it) > b) package it in /etc/rc.d/init.d/your_script > > As /etc/init.d is a symlink, if you don't do one of > these, your package may be installed first, and this > will cause chkconfig to fail to install later. Thanks Bill, CCing this over to fedora-packaging to let Tom roll it into his docs. -sv From toshio at tiki-lounge.com Tue Mar 15 13:42:59 2005 From: toshio at tiki-lounge.com (Toshio) Date: Tue, 15 Mar 2005 08:42:59 -0500 Subject: [Fedora-packaging] Re: GConf schema packaging guidelines In-Reply-To: <1110636689.31593.19.camel@gruyere> References: <1109706164.23341.7.camel@cassandra.boston.redhat.com> <1110636689.31593.19.camel@gruyere> Message-ID: <1110894180.4432.18.camel@Madison.badger.com> From rom the Fedora-maintainers list Code in question: > Le mardi 01 mars 2005 ? 14:42 -0500, David Malcolm a ?crit : > > Some spec files try to uninstall the schema e.g. from > > evolution-connector: > > %preun > > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > > gconftool-2 --makefile-uninstall-rule \ > > %{_sysconfdir}/gconf/schemas/apps_evolution_exchange.schemas > > >/dev/null || : The problem: > On Sat, 2005-03-12 at 15:11 +0100, Dams wrote: > This is a packaging bug if you dont test the upgrade case. > If you uninstall schemas you just *must* have an `if' statement > surrounding the gconf schema un-installation in %preun, to test if we're > being upgraded or un-installed. > > Remember that, when upgrading, %preun of the old package is ran after > the new package %post. > I think the intent is to remove the old schema from gconf before installing the new schema. So I think this %pre script would work:: %pre # For GConf apps if [ "$1" -gt 1]; then export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-uninstall-rule \ %{_sysconfdir}/gconf/schemas/%{name}.schemas >/dev/null || : fi Is that wrong (or my assumption that we're trying to clean up the old schema?) If it's good, then maybe the scriptlets in the spectemplates (fedora-rpmdevtools) should be changed. > And anyway, we have a problem in cases like: > > * foo-1 which has foo.schema is installed > * you upgrade to foo-2 which has foo2.schema, but has no > foo.schema. > > foo.schema will never be uninstalled, as foo-2 knows nothing about it. > (Yes, that sort of things has already happened). The packager should know about foo.schema... So one inelegant solution would be to put uninstall rules for both foo.schema and foo2.schema with discarded error conditions into the %pre. -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 Mar 15 15:00:29 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 15 Mar 2005 17:00:29 +0200 Subject: [Fedora-packaging] Re: GConf schema packaging guidelines In-Reply-To: <1110894180.4432.18.camel@Madison.badger.com> References: <1109706164.23341.7.camel@cassandra.boston.redhat.com> <1110636689.31593.19.camel@gruyere> <1110894180.4432.18.camel@Madison.badger.com> Message-ID: <1110898829.26174.22.camel@bobcat.mine.nu> On Tue, 2005-03-15 at 08:42 -0500, Toshio wrote: > I think the intent is to remove the old schema from gconf before > installing the new schema. So I think this %pre script would work:: > %pre > # For GConf apps > if [ "$1" -gt 1]; then Missing space between "1" and "]" :) > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > gconftool-2 --makefile-uninstall-rule \ > %{_sysconfdir}/gconf/schemas/%{name}.schemas >/dev/null || : > fi > > Is that wrong (or my assumption that we're trying to clean up the old > schema?) If it's good, then maybe the scriptlets in the spectemplates > (fedora-rpmdevtools) should be changed. Based on a brief look, the above would fail if the schema filename has changed (or if the package has been renamed: %{name} is the name of the new package, not old). From toshio at tiki-lounge.com Tue Mar 15 16:52:39 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 15 Mar 2005 08:52:39 -0800 Subject: [Fedora-packaging] Re: GConf schema packaging guidelines In-Reply-To: <1110898829.26174.22.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Tue, Mar 15, 2005 at 05:00:29PM +0200 References: <1109706164.23341.7.camel@cassandra.boston.redhat.com> <1110636689.31593.19.camel@gruyere> <1110894180.4432.18.camel@Madison.badger.com> <1110898829.26174.22.camel@bobcat.mine.nu> Message-ID: <20050315085239.A24355@tiki-lounge.com> On Tue, Mar 15, 2005 at 05:00:29PM +0200, Ville Skytt? wrote: > On Tue, 2005-03-15 at 08:42 -0500, Toshio wrote: > > > I think the intent is to remove the old schema from gconf before > > installing the new schema. So I think this %pre script would work:: > > %pre > > # For GConf apps > > if [ "$1" -gt 1]; then > > Missing space between "1" and "]" :) > Noticed that when I started testing :-) > > export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` > > gconftool-2 --makefile-uninstall-rule \ > > %{_sysconfdir}/gconf/schemas/%{name}.schemas >/dev/null || : > > fi > > > > Is that wrong (or my assumption that we're trying to clean up the old > > schema?) If it's good, then maybe the scriptlets in the spectemplates > > (fedora-rpmdevtools) should be changed. > > Based on a brief look, the above would fail if the schema filename has > changed (or if the package has been renamed: %{name} is the name of the > new package, not old). > Good point. So schema names would need to be hardcoded in. (This is related to the second point raised in anvil's email, yes?) Testing has also revealed that the %preun will still need to have a gconf uninstall only rule to handle the uninstall case... %pre will only handle the upgrade case. -Toshio From cra at WPI.EDU Tue Mar 15 23:08:06 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Tue, 15 Mar 2005 18:08:06 -0500 Subject: [Fedora-packaging] Running scriptlets only in certain situations Message-ID: <20050315230806.GD1036@angus.ind.WPI.EDU> On http://fedoraproject.org/wiki/PackagingGuidelines under "Running scriptlets only in certain situations" it gives an example: This means that for example a package that installs an init script with the chkconfig command should uninstall it only on erase and not upgrade with the following snippet: %postun if [ $1 -eq 0 ]; then /sbin/chkconfig --del %{name} fi However, that example is incorrect. By the time %postun is run, the /etc/init.d/%{name} file is already gone. This needs to be run instead in %preun. From toshio at tiki-lounge.com Wed Mar 16 01:03:46 2005 From: toshio at tiki-lounge.com (Toshio) Date: Tue, 15 Mar 2005 20:03:46 -0500 Subject: [Fedora-packaging] Re: GConf schema packaging guidelines In-Reply-To: <20050315085239.A24355@tiki-lounge.com> References: <1109706164.23341.7.camel@cassandra.boston.redhat.com> <1110636689.31593.19.camel@gruyere> <1110894180.4432.18.camel@Madison.badger.com> <1110898829.26174.22.camel@bobcat.mine.nu> <20050315085239.A24355@tiki-lounge.com> Message-ID: <1110935027.6537.19.camel@Madison.badger.com> Okay -- this set of scripts seems to work and has the added benefit of sending a HUP to have gconfd-2 reload per Mark McLoughlin's suggestion on fedora-maintainers. (I don't know how gcond responded to HUP prior to 2.7.3 FC2 and earlier though.) I don't know if there's anyway to work around the previous broken scripts, though.... %pre if [ "$1" -gt 1 ]; then export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-uninstall-rule \ %{_syscondir}/gconf/schemas/CURRENTSCHEMA.schemas > /dev/null || : # If applicable: # gconftool-2 --makefile-uninstall-rule \ # %{_sysconfdir}/gconf/schemas/OLDSCHEMA.schemas > /dev/null || : killall -HUP gconfd-2 fi %post export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule \ /etc/gconf/schemas/CURRENTSCHEMA.schemas > /dev/null || : killall -HUP gconfd-2 %preun if [ "$1" -eq 0 ]; then export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-uninstall-rule \ /etc/gconf/schemas/CURRENTSCHEMA.schemas > /dev/null || : killall -HUP gconfd-2 fi -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 Sat Mar 19 19:58:29 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 19 Mar 2005 21:58:29 +0200 Subject: [Fedora-packaging] Device node packaging question Message-ID: <1111262309.8997.156.camel@bobcat.mine.nu> tpb from Extras fails to build on FC4 due to rpmbuild 4.4 not liking the way the device node is created. https://bugzilla.redhat.com/151527 tpb needs the /dev/nvram node in order to function, and the users using tpb will need to be able to read from /dev/nvram. Opinions how to create the device node and ensure the correct permissions? Some approaches: Place the device node in /etc/udev/devices, own it in the package, use udev permissions.d for the permissions. This is what is currently done, but it fails due to rpmbuild no longer liking that (see the above bug report). And it's not that pretty anyway. I could %ghost the node and create it in %post, but that's even a bit uglier IMO. How about using the /etc/udev/makedev.d functionality for creating the node? This has the problem that stuff in /etc/udev/permissions.d doesn't apply to /etc/udev/makedev.d nodes (is this a bug?); instead the node is being created with the too restrictive 0600,root,root permissions from /etc/makedev.d/{00macros,linux-2.6.x}. A workaround would be to place an override in /etc/makedev.d/$something, overriding the permissions for the nvram node in linux-2.6.x. The MAKEDEV man page doesn't describe how to accomplish that override or if it's possible, but I guess naming the file something like 01-tpb-nvram would work. The ideal way would be to create the node with restrictive permissions as in the above, and use console.perms for granting users logged on to the console access to the device. However, I'm not going to do that in the tpb package by sed'ing /etc/security/console.perms, because doing so could have "effects" when later upgrading pam. Instructing users to make that modification would have essentially the same drawback. And console.perms.d doesn't exist :( https://bugzilla.redhat.com/135093 So, maybe suggest adding nvram to the console.perms shipped with pam? Comments, other solutions? From dag at wieers.com Mon Mar 21 21:21:37 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 21 Mar 2005 22:21:37 +0100 (CET) Subject: [Fedora-packaging] Re: APPROVED: clearlooks In-Reply-To: <1111437035.1810.3.camel@ignacio.ignacio.lan> References: <1111432975.4045.75.camel@ignacio.ignacio.lan> <1111437035.1810.3.camel@ignacio.ignacio.lan> Message-ID: On Mon, 21 Mar 2005, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-03-21 at 21:24 +0100, Dag Wieers wrote: > > On Mon, 21 Mar 2005, Ignacio Vazquez-Abrams wrote: > > > > > clearlooks: An attractive GTK+ 2 engine with a focus on usability > > > > > > Clearlooks will transform your GNOME desktop into an attractive looking > > > and usable environment. > > > > > > Reviewers: Jeremy Katz, Michael Schwendt, Ralf Corsepius, Adrian Reber > > > Maintainer: Ignacio Vazquez-Abrams > > > > Is it ok to package a Gnome theme as 'clearlooks' when it > > will become the default theme in Gnome ? If so, wouldn't > > gnome-themes-clearlooks not be a better name ? Like gnome-themes and > > gnome-themes-extras already set a precedent. > > https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00317.html > https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00453.html > https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00569.html Ok, I've only subscribed this weekend to fedora-extras. (For some reason I thought I was already subscribed to every fedora mailinglist, but I noticed today I'm still missing the buildsystem mailinglist, sigh) None of these mails seem conclusive on the subject and since I was subscribed to fedora-packaging I would have expected such a discussion/decision there probably. I think package naming is an important (and the first) part of good packaging and I would hate to see a Gnome theme be packaged like an application or library. The current guidelines already have some policy for plugins and extras, so I think this is an obvious extension to that. The same is true for Gnome (or other) applets. foo-applet could be an applet for a lot of things, so gnome-applet-foo seems a much better scheme. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Mon Mar 21 23:12:53 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 22 Mar 2005 00:12:53 +0100 (CET) Subject: [Fedora-packaging] Re: gnome-theme-clearlooks please Re: APPROVED: clearlooks In-Reply-To: <423F440E.6040801@redhat.com> References: <1111432975.4045.75.camel@ignacio.ignacio.lan> <1111437035.1810.3.camel@ignacio.ignacio.lan> <423F3CD3.7050100@redhat.com> <1111440965.1810.6.camel@ignacio.ignacio.lan> <20050321133803.B27195@tiki-lounge.com> <1111442146.1810.11.camel@ignacio.ignacio.lan> <423F440E.6040801@redhat.com> Message-ID: On Mon, 21 Mar 2005, Warren Togami wrote: > Ignacio Vazquez-Abrams wrote: > > Sounds like a plan. Anyone have any complaints with the name? > > > > Also, I'd like to add "Obsoletes: clearlooks <= 0.5" to both packages > > temporarily for a couple of releases just to clean out packages that > > people may have been using from either my repo or self-builds from CVS. > > Any complaints? > > I would advise against it. We need to move forward with FC and FE as the > canonical package set. Whoever is using the old package name must manually > move. This is only a small number of people right? > > Plus this cancels the benefit of renaming this package in the first place, > because it already pollutes the namespace. Actually I would allow for something like this for eg. 1 release cycle. You can't take the userbase as a objective measurement because what is a big userbase ? Fact is, I have been using 'wrong' package names (to my liking) because I had to follow the naming scheme most likely to be adopted either by Red Hat or by fedora.us. So I had to try to be forward compatible. For this reason, the only possibility to have an upgrade path to Fedora Extras, 3rd party repositories rely on Obsolete tags. It would be a wrong signal if only an upgrade path from fedora.us to Fedora Extras is allowed, especially because 3rd party repositories have been the only alternative users had to turn to for extra packages. Since we have a more strict naming policy in place now, new naming mismatches are very limited so namespace pollution will slow down. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From jpo at di.uminho.pt Wed Mar 23 23:29:37 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Wed, 23 Mar 2005 23:29:37 +0000 Subject: [Fedora-packaging] Importing tetex packages question Message-ID: <4241FBE1.7030002@di.uminho.pt> Hi, Before importing the following tetex packages SRPMS - tetex-bytefield, tetex-xcolor, tetex-pgf. tetex-beamer - I would like to pose a question regarding the source file version control done by/in the CVS side cache (make upload FILES=...): Description of the problem: The source tarballs for the above tetex packages are all created on the fly by the DANTE CTAN master mirror. The main problem is that CTAN only has the latest version of every package and that the tarball generated has no version in its name (see for example: http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-bytefield.spec). Although there is a possibility of finding versioned tarballs for some of the above packages, the problem remains for other CTAN Latex packages - no author homepage with versioned tarballs. Question: Should I manually had a version to the DANTE generated tarball? Or can the CVS accept a new tarball with the same name when a package update occurs (check thread below). Review request thread: https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00869.html Thanks in advance, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From bugs.michael at gmx.net Thu Mar 24 00:22:42 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 24 Mar 2005 01:22:42 +0100 Subject: [Fedora-packaging] Importing tetex packages question In-Reply-To: <4241FBE1.7030002@di.uminho.pt> References: <4241FBE1.7030002@di.uminho.pt> Message-ID: <20050324012242.1879c081.bugs.michael@gmx.net> On Wed, 23 Mar 2005 23:29:37 +0000, Jos? Pedro Oliveira wrote: > Before importing the following tetex packages SRPMS - tetex-bytefield, > tetex-xcolor, tetex-pgf. tetex-beamer - I would like to pose a question > regarding the source file version control done by/in the CVS side cache > (make upload FILES=...): > > Description of the problem: > The source tarballs for the above tetex packages are all created on the > fly by the DANTE CTAN master mirror. The main problem is that CTAN only > has the latest version of every package and that the tarball generated > has no version in its name (see for example: > http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-bytefield.spec). > > Although there is a possibility of finding versioned tarballs for > some of the above packages, the problem remains for other CTAN Latex > packages - no author homepage with versioned tarballs. > > Question: > Should I manually had a version to the DANTE generated tarball? Or > can the CVS accept a new tarball with the same name when a package > update occurs The lookaside cache can accept file changes which result in a changed MD5 fingerprint. I recommened, however, that you be more explicit with file naming and insert the date of download into the otherwise non-versioned tarball file name, e.g. bytefield-20030523.tar.gz instead of just bytefield.tar.gz From jpo at di.uminho.pt Thu Mar 24 00:32:47 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 24 Mar 2005 00:32:47 +0000 Subject: [Fedora-packaging] Importing tetex packages question In-Reply-To: <20050324012242.1879c081.bugs.michael@gmx.net> References: <4241FBE1.7030002@di.uminho.pt> <20050324012242.1879c081.bugs.michael@gmx.net> Message-ID: <42420AAF.7070907@di.uminho.pt> Michael Schwendt wrote: > > The lookaside cache can accept file changes which result in a changed MD5 > fingerprint. I recommened, however, that you be more explicit with file > naming and insert the date of download into the otherwise non-versioned > tarball file name, e.g. bytefield-20030523.tar.gz instead of just > bytefield.tar.gz Any objections if I also had the LaTeX package version e.g bytefield-1.2-20030523.tar.gz ? jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From jpo at di.uminho.pt Thu Mar 24 01:44:04 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 24 Mar 2005 01:44:04 +0000 Subject: [Fedora-packaging] Importing tetex packages question In-Reply-To: <42420AAF.7070907@di.uminho.pt> References: <4241FBE1.7030002@di.uminho.pt> <20050324012242.1879c081.bugs.michael@gmx.net> <42420AAF.7070907@di.uminho.pt> Message-ID: <42421B64.9030206@di.uminho.pt> Jos? Pedro Oliveira wrote: > Michael Schwendt wrote: > >> >> The lookaside cache can accept file changes which result in a changed MD5 >> fingerprint. I recommened, however, that you be more explicit with file >> naming and insert the date of download into the otherwise non-versioned >> tarball file name, e.g. bytefield-20030523.tar.gz instead of just >> bytefield.tar.gz > > > Any objections if I also had the LaTeX package version > e.g bytefield-1.2-20030523.tar.gz ? Arghhh! s/had/add/ jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From bugs.michael at gmx.net Thu Mar 24 02:26:37 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 24 Mar 2005 03:26:37 +0100 Subject: [Fedora-packaging] Importing tetex packages question In-Reply-To: <42421B64.9030206@di.uminho.pt> References: <4241FBE1.7030002@di.uminho.pt> <20050324012242.1879c081.bugs.michael@gmx.net> <42420AAF.7070907@di.uminho.pt> <42421B64.9030206@di.uminho.pt> Message-ID: <20050324032637.763fe571.bugs.michael@gmx.net> On Thu, 24 Mar 2005 00:32:47 +0000, Jos? Pedro Oliveira wrote: > Michael Schwendt wrote: > > > > The lookaside cache can accept file changes which result in a changed MD5 > > fingerprint. I recommened, however, that you be more explicit with file > > naming and insert the date of download into the otherwise non-versioned > > tarball file name, e.g. bytefield-20030523.tar.gz instead of just > > bytefield.tar.gz > > Any objections if I also had the LaTeX package version > e.g bytefield-1.2-20030523.tar.gz ? If you think you need that version in order to distinguish the tarballs even further, use it. ;) From tcallawa at redhat.com Thu Mar 24 20:42:01 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Mar 2005 14:42:01 -0600 Subject: [Fedora-packaging] dist tag revisited Message-ID: <1111696922.3698.93.camel@localhost.localdomain> I had an insightful discussion with Sopwith this afternoon, and we discussed the idea of dist tags, and some important discussion arose: Elliot pointed out that for any given .src.rpm, the name-version-release needs to stay fixed for all builds of that .src.rpm. Otherwise it becomes impossible to track packages back to their source, keep an audit trail, etc. The problem with using the macros is that if a maintainer does 'make build' on an fc3 box, then they get the dist tag value from that machine in the n-v-r. When they go to check this into CVS (say, into the fc4 branch), its wrong. We don't want someone doing 'make tag' on the FC-4 branch and having n-v-r = foo-1.2-3.fc3. But at the same time, we also want to avoid forcing the packagers to have to put the dist value into the spec manually. This defeats the entire reason for dist tags, which is to have a single spec that can be used for multiple distributions. We discussed a lot of options, but Elliot came up with a good idea, which is best explained by giving an example of a new package commit: - I'm a maintainer, of package logjam. - I make a single spec for all possible fc builds using the documented "approved" dist macros - I set Release: 1 (note, no %{dist}) - I make my src.rpm. - I then run ./cvs-import.sh --use-dist --branch=fc4 logjam-1.0.0-1.src.rpm - The cvs-import script does the following: - Checks my spec to make sure that n-v-r doesn't have %{dist} in it already - Notes the value of the branch that I'm checking this package into - Uses that value and adds the following lines to the top of my spec %define fedora 4 %define dist .fc4 - Appends %{?dist} to the end of Release (so it becomes Release: 1%{?dist} ) - Commits the spec with the added defines into the branch. Now, with this mechanism, if I want to do multiple branches for a single spec, its easy, cvs-import.sh does the work for me. We keep a single n-v-r per branch, and there is no naming conflicts between branches. The branch-copy operations would just change the values of the macros, or add the macros near the top if they're not already in the .spec file. We'd want to add a check in the buildsystem to make sure that people haven't polluted the %{dist} defines, but that shouldn't be terribly difficult. Now, for people wanting to take their original spec and build it somewhere else, say for RHEL, we could use a set of rpm macros. Elliot and I worked on a simple shell script that parses /etc/redhat-release and returns (depending on the flag chosen): The version of RHEL for %{_el} (if on RHEL) The version of Fedora for %{_fedora} (if on Fedora) The version of RHL for %{_rhel} (if on RHL) The number of the distro for %{_distnum} The type of the distro for %{_disttype} The dist tag value for %{_dist} The macros then become as simple as: %_dist %{expand:%%(/usr/lib/rpm/redhat/dist.sh --dist)} %_distnum %{expand:%%(/usr/lib/rpm/redhat/dist.sh --distnum)} %_disttype %{expand:%%(/usr/lib/rpm/redhat/dist.sh --disttype)} %_rhel %{expand:%%(/usr/lib/rpm/redhat/dist.sh --el)} %_fedora %{expand:%%(/usr/lib/rpm/redhat/dist.sh --fc)} %_rhl %{expand:%%(/usr/lib/rpm/redhat/dist.sh --rhl)} The script is already checked into CVS for redhat-rpm-config. If you wanted to build off that spec for RHEL, you'd just need to add these 7 lines to your local .rpmmacros file. This provides a standardized, easy way to do single-spec, multiple distribution packaging. But of course, there are bound to be complications. Please ponder this implementation, and offer feedback. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From orion at cora.nwra.com Thu Mar 24 22:14:21 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 24 Mar 2005 15:14:21 -0700 Subject: [Fedora-packaging] Alternative kernel packages Message-ID: <42433BBD.7010502@cora.nwra.com> I'm starting to build alternative kernel packages based on the -ck patchsets, and am looking for some feedback/suggestions. My current spec changes from the kernel-2.6.spec (besides changing patches and configs) are: 32c34 < %define release %(R="$Revision: 1.1177 $"; RR="${R##: }"; echo ${RR%%?})_FC4%{rhbsys} --- > %define release %(R="$Revision: 1.1176 $"; RR="${R##: }"; echo ${RR%%?})_FC4%{rhbsys}.ck2 ^ add the version of the ck patch to the release. 155c157 < Name: kernel --- > Name: kernel-ck ^ change the name of the package to kernel-ck The goal here is to be able to completely remove all of the stock fedora kernels and only leave kernel-ck (much like I do on smp machines and leave only kernel-smp), and have a "desktop" kernel choice. Any other gotchas? The pipe dream would be to have a kickstart file tell anaconda to install the kernel-ck set. -- 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 tcallawa at redhat.com Thu Mar 24 22:14:07 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 24 Mar 2005 16:14:07 -0600 Subject: [Fedora-packaging] Alternative kernel packages In-Reply-To: <42433BBD.7010502@cora.nwra.com> References: <42433BBD.7010502@cora.nwra.com> Message-ID: <1111702447.3698.120.camel@localhost.localdomain> On Thu, 2005-03-24 at 15:14 -0700, Orion Poplawski wrote: > I'm starting to build alternative kernel packages based on the -ck > patchsets, and am looking for some feedback/suggestions. My current spec > changes from the kernel-2.6.spec (besides changing patches and configs) are: Your changes look sane for making a custom kernel rpm. You should even be able to install this custom rpm in the %post section of the kickstart without much difficulty. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ville.skytta at iki.fi Sun Mar 27 10:17:00 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 27 Mar 2005 13:17:00 +0300 Subject: [Fedora-packaging] Running scriptlets only in certain situations In-Reply-To: <20050315230806.GD1036@angus.ind.WPI.EDU> References: <20050315230806.GD1036@angus.ind.WPI.EDU> Message-ID: <1111918620.12235.123.camel@bobcat.mine.nu> On Tue, 2005-03-15 at 18:08 -0500, Chuck R. Anderson wrote: > On http://fedoraproject.org/wiki/PackagingGuidelines under "Running > scriptlets only in certain situations" it gives an example: [...] > However, that example is incorrect. By the time %postun is run, the > /etc/init.d/%{name} file is already gone. This needs to be run > instead in %preun. Fixed, thanks for the heads up. From jspaleta at gmail.com Mon Mar 28 01:12:17 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 27 Mar 2005 20:12:17 -0500 Subject: [Fedora-packaging] questions regarding kernel-devel and kernel-smp-devel packages Message-ID: <604aa79105032717126170b399@mail.gmail.com> Currently in rawhide at the moment yum treats kernel-devel as installonly but kernel-smp-devel package is treated as a normal package when doing updates. Which is the more correct befault behavior? Do we want multiple versions of kernel-devel and kernel-smp-devel packages to be installed by default or do we want these packages to update? If we want multiple versions to install, as default behavior, do we want to use a different mechanism then the package name? Like using a common provides statement that yum can see and act on.. similar to how kernel and kernel-module packages are sensed? -jef From wtogami at redhat.com Mon Mar 28 01:21:41 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 27 Mar 2005 15:21:41 -1000 Subject: [Fedora-packaging] questions regarding kernel-devel and kernel-smp-devel packages In-Reply-To: <604aa79105032717126170b399@mail.gmail.com> References: <604aa79105032717126170b399@mail.gmail.com> Message-ID: <42475C25.4020707@redhat.com> Jeff Spaleta wrote: > Currently in rawhide at the moment yum treats kernel-devel as installonly > but kernel-smp-devel package is treated as a normal package when doing updates. > > Which is the more correct befault behavior? Do we want multiple > versions of kernel-devel and kernel-smp-devel packages to be installed > by default or do we want these packages to update? We need the ability to install any or multiple kernel-*devel packages in order to build modules against any target kernel version and arch. Upgrade is never desired with kernel-*devel. > If we want multiple versions to install, as default behavior, do we > want to use a different mechanism then the package name? Like using a > common provides statement that yum can see and act on.. similar to how > kernel and kernel-module packages are sensed? > Yes. Modifying a list of names in yum is bad. The packages themselves should tell the dep resolver "Do not upgrade me!" Warren Togami wtogami at redhat.com From aoliva at redhat.com Mon Mar 28 18:36:14 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 28 Mar 2005 15:36:14 -0300 Subject: [Fedora-packaging] questions regarding kernel-devel and kernel-smp-devel packages In-Reply-To: <42475C25.4020707@redhat.com> References: <604aa79105032717126170b399@mail.gmail.com> <42475C25.4020707@redhat.com> Message-ID: On Mar 27, 2005, Warren Togami wrote: > We need the ability to install any or multiple kernel-*devel packages > in order to build modules against any target kernel version and > arch. Upgrade is never desired with kernel-*devel. I disagree. Having to clean up for up2date/yum/whatever because multiple kernels pile up as updates are released is already bad enough, but it's desirable because, if you removed the old kernel and the new one happened to break on your box, you're toast. I can't think of any such strong rationale for kernel*-devel. Sure, it may be convenient for a small fraction of the developer base, which is significantly smaller than the user base. IMHO kernel*-devel should upgrade just like any other package. The few people who would rather keep multiple kernel-devel packages are probably skilled enough to make the small configuration change needed to achieve their goal. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From enrico.scholz at informatik.tu-chemnitz.de Mon Mar 28 21:47:01 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 28 Mar 2005 23:47:01 +0200 Subject: [Fedora-packaging] questions regarding kernel-devel and kernel-smp-devel packages In-Reply-To: <42475C25.4020707@redhat.com> (Warren Togami's message of "Sun, 27 Mar 2005 15:21:41 -1000") References: <604aa79105032717126170b399@mail.gmail.com> <42475C25.4020707@redhat.com> Message-ID: <87r7hza1ey.fsf@kosh.ultra.csn.tu-chemnitz.de> wtogami at redhat.com (Warren Togami) writes: >> Currently in rawhide at the moment yum treats kernel-devel as >> installonly but kernel-smp-devel package is treated as a normal >> package when doing updates. Which is the more correct befault >> behavior? Do we want multiple versions of kernel-devel and >> kernel-smp-devel packages to be installed by default or do we >> want these packages to update? > > We need the ability to install any or multiple kernel-*devel packages > in order to build modules against any target kernel version and > arch. Upgrade is never desired with kernel-*devel. Never say 'never'... Although 'install' will be the right choice for a lot of systems, there are other ones where 'upgrade' is desired (not only for 'kernel*devel', but for 'kernel' also). E.g. for vservers it does not make much sense to install a second kernel. >> If we want multiple versions to install, as default behavior, do we >> want to use a different mechanism then the package name? Like using a >> common provides statement that yum can see and act on.. similar to how >> kernel and kernel-module packages are sensed? >> > > Yes. Modifying a list of names in yum is bad. The packages > themselves should tell the dep resolver "Do not upgrade me!" Whichever solution will be applied, adding yet more black magic to the depsolver (which can not be overridden) must be prevented. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From wtogami at redhat.com Tue Mar 29 03:56:16 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 28 Mar 2005 17:56:16 -1000 Subject: [Fedora-packaging] questions regarding kernel-devel and kernel-smp-devel packages In-Reply-To: <87r7hza1ey.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <604aa79105032717126170b399@mail.gmail.com> <42475C25.4020707@redhat.com> <87r7hza1ey.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <4248D1E0.7010303@redhat.com> Enrico Scholz wrote: > > Never say 'never'... Although 'install' will be the right choice for a > lot of systems, there are other ones where 'upgrade' is desired (not > only for 'kernel*devel', but for 'kernel' also). E.g. for vservers it > does not make much sense to install a second kernel. For corner cases like vservers or buildroots, we should have a kernel-999 fake package. It wont ever change. Simple. Warren Togami wtogami at redhat.com From enrico.scholz at informatik.tu-chemnitz.de Tue Mar 29 13:02:27 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 29 Mar 2005 15:02:27 +0200 Subject: [Fedora-packaging] questions regarding kernel-devel and kernel-smp-devel packages In-Reply-To: <4248D1E0.7010303@redhat.com> (Warren Togami's message of "Mon, 28 Mar 2005 17:56:16 -1000") References: <604aa79105032717126170b399@mail.gmail.com> <42475C25.4020707@redhat.com> <87r7hza1ey.fsf@kosh.ultra.csn.tu-chemnitz.de> <4248D1E0.7010303@redhat.com> Message-ID: <87is3aa9lo.fsf@kosh.ultra.csn.tu-chemnitz.de> wtogami at redhat.com (Warren Togami) writes: >> Never say 'never'... Although 'install' will be the right choice for a >> lot of systems, there are other ones where 'upgrade' is desired (not >> only for 'kernel*devel', but for 'kernel' also). E.g. for vservers it >> does not make much sense to install a second kernel. > > For corner cases like vservers or buildroots, we should have a > kernel-999 fake package. It will give only trouble... you will need yet more special magic in the depsolver to differ between the regular kernel packages and faked ones. A simple and better solution would be the removal of any exception (e.g. implicit and unoverridable 'installonlypkg' for 'kernel') or other automatism (e.g. guessing of repo- or cachedir) in the depsolver. Such paternalism will strike back -- at least with vservers or buildroots. Instead of, provide reasonable defaults (e.g. write 'installonlypkg = kernel' in the shipped yum.conf) which can be overridden by the user. > It wont ever change. Simple. What is, when next xorg-x11 requires kernel-drm >= 4.4.0? Enrico From wtogami at redhat.com Tue Mar 29 21:07:36 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 29 Mar 2005 11:07:36 -1000 Subject: [Fedora-packaging] %{_libdir}/rpm/brp-compress for perl modules Message-ID: <4249C398.3030901@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127988 [ -x %{_libdir}/rpm/brp-compress ] && %{_libdir}/rpm/brp-compress There are several packages like this, and similar perl modules with /usr/lib instead of %{_libdir}. This fails to build on x86_64 for obvious reasons. While this isn't a problem for FC's build system (everything is built on 32bit), we should fix these packages. [ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress While doing this would work, this may confuse people because our packaging docs say to macroize everything. Are there other cases where macroizing directories is NOT the right thing to do? And... any idea why these packages are running brp-compress anyway? Doesn't this happen automatically without it? Warren Togami wtogami at redhat.com From ville.skytta at iki.fi Wed Mar 30 21:51:48 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 31 Mar 2005 00:51:48 +0300 Subject: [Fedora-packaging] %{_libdir}/rpm/brp-compress for perl modules In-Reply-To: <4249C398.3030901@redhat.com> References: <4249C398.3030901@redhat.com> Message-ID: <1112219508.31596.38.camel@bobcat.mine.nu> On Tue, 2005-03-29 at 11:07 -1000, Warren Togami wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127988 > > [ -x %{_libdir}/rpm/brp-compress ] && %{_libdir}/rpm/brp-compress > There are several packages like this, and similar perl modules with > /usr/lib instead of %{_libdir}. This fails to build on x86_64 for > obvious reasons. While this isn't a problem for FC's build system > (everything is built on 32bit), we should fix these packages. > > [ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress > While doing this would work, Yeah, but it ignores the system's other rpmbuild configuration, eg. redhat-rpm-config, which uses /usr/lib/rpm/redhat/brp-compress. Not that there would be too big differences between them nowadays, but to illustrate. > this may confuse people because our > packaging docs say to macroize everything. Are there other cases where > macroizing directories is NOT the right thing to do? All cases where it doesn't make sense? I don't think it's possible to give an exhaustive answer to that. Packagers just have to know when to use macros, and what macros, and when not to. If packaging docs say macroize everything, then I think the docs should be improved. BTW, if one wants to keep the above explicit brp-compress's in, it'd be better to change them to %{_prefix}/lib/rpm/..., see rpm.spec. > And... any idea why these packages are running brp-compress anyway? > Doesn't this happen automatically without it? It does, and I think those should be just removed from all specfiles. They're probably initially from cpanflute2 which creates a lot of cruft no longer needed in non-ancient RH(EL)/FC distro versions. From wtogami at redhat.com Thu Mar 31 07:42:51 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 30 Mar 2005 21:42:51 -1000 Subject: [Fedora-packaging] %{_libdir}/rpm/brp-compress for perl modules In-Reply-To: <1112219508.31596.38.camel@bobcat.mine.nu> References: <4249C398.3030901@redhat.com> <1112219508.31596.38.camel@bobcat.mine.nu> Message-ID: <424BA9FB.1030104@redhat.com> Ville Skytt? wrote: > >>And... any idea why these packages are running brp-compress anyway? >>Doesn't this happen automatically without it? > > > It does, and I think those should be just removed from all specfiles. > They're probably initially from cpanflute2 which creates a lot of cruft > no longer needed in non-ancient RH(EL)/FC distro versions. > Some of these are probably false positives... will attempt to fix. Any simple way of scripting a way of comparing the versions of perl modules in rawhide to CPAN to see which need to be upgraded? Warren Togami wtogami at redhat.com [wtogami at devserv devel]$ grep --files-with-matches brp-compress perl*/*.spec perl-Archive-Tar/perl-Archive-Tar.spec perl-Bit-Vector/perl-Bit-Vector.spec perl-BSD-Resource/perl-BSD-Resource.spec perl-Compress-Zlib/perl-Compress-Zlib.spec perl-Convert-ASN1/perl-Convert-ASN1.spec perl-Crypt-SSLeay/perl-Crypt-SSLeay.spec perl-Date-Calc/perl-Date-Calc.spec perl-DateManip/perl-DateManip.spec perl-DBD-MySQL/perl-DBD-MySQL.spec perl-DBD-Pg/perl-DBD-Pg.spec perl-DBI/perl-DBI.spec perl-Devel-Symdump/perl-Devel-Symdump.spec perl-Digest-HMAC/perl-Digest-HMAC.spec perl-Digest-SHA1/perl-Digest-SHA1.spec perl-File-MMagic/perl-File-MMagic.spec perl-Filter/perl-Filter.spec perl-Filter-Simple/perl-Filter-Simple.spec perl-Frontier-RPC/perl-Frontier-RPC.spec perl-HTML-Parser/perl-HTML-Parser.spec perl-HTML-Tagset/perl-HTML-Tagset.spec perl-Inline/perl-Inline.spec perl-LDAP/perl-LDAP.spec perl-libwww-perl/perl-libwww-perl.spec perl-libxml-enno/perl-libxml-enno.spec perl-libxml-perl/perl-libxml-perl.spec perl-Net-DNS/perl-Net-DNS.spec perl-Parse-RecDescent/perl-Parse-RecDescent.spec perl-Parse-Yapp/perl-Parse-Yapp.spec perl-PDL/perl-PDL.spec perl/perl.spec perl-RPM2/perl-RPM2.spec perl-RPM-Specfile/perl-RPM-Specfile.spec perl-TermReadKey/perl-TermReadKey.spec perl-TimeDate/perl-TimeDate.spec perl-Time-HiRes/perl-Time-HiRes.spec perl-URI/perl-URI.spec perl-XML-Dumper/perl-XML-Dumper.spec perl-XML-Encoding/perl-XML-Encoding.spec perl-XML-Grove/perl-XML-Grove.spec perl-XML-LibXML-Common/perl-XML-LibXML-Common.spec perl-XML-NamespaceSupport/perl-XML-NamespaceSupport.spec perl-XML-Parser/perl-XML-Parser.spec perl-XML-Twig/perl-XML-Twig.spec [wtogami at devserv devel]$ vim perl/perl.spec [wtogami at devserv devel]$ grep --files-with-matches brp-compress perl*/*.spec perl-Archive-Tar/perl-Archive-Tar.spec perl-Bit-Vector/perl-Bit-Vector.spec perl-BSD-Resource/perl-BSD-Resource.spec perl-Compress-Zlib/perl-Compress-Zlib.spec perl-Convert-ASN1/perl-Convert-ASN1.spec perl-Crypt-SSLeay/perl-Crypt-SSLeay.spec perl-Date-Calc/perl-Date-Calc.spec perl-DateManip/perl-DateManip.spec perl-DBD-MySQL/perl-DBD-MySQL.spec perl-DBD-Pg/perl-DBD-Pg.spec perl-DBI/perl-DBI.spec perl-Devel-Symdump/perl-Devel-Symdump.spec perl-Digest-HMAC/perl-Digest-HMAC.spec perl-Digest-SHA1/perl-Digest-SHA1.spec perl-File-MMagic/perl-File-MMagic.spec perl-Filter/perl-Filter.spec perl-Filter-Simple/perl-Filter-Simple.spec perl-Frontier-RPC/perl-Frontier-RPC.spec perl-HTML-Parser/perl-HTML-Parser.spec perl-HTML-Tagset/perl-HTML-Tagset.spec perl-Inline/perl-Inline.spec perl-LDAP/perl-LDAP.spec perl-libwww-perl/perl-libwww-perl.spec perl-libxml-enno/perl-libxml-enno.spec perl-libxml-perl/perl-libxml-perl.spec perl-Net-DNS/perl-Net-DNS.spec perl-Parse-RecDescent/perl-Parse-RecDescent.spec perl-Parse-Yapp/perl-Parse-Yapp.spec perl-PDL/perl-PDL.spec perl/perl.spec perl-RPM2/perl-RPM2.spec perl-RPM-Specfile/perl-RPM-Specfile.spec perl-TermReadKey/perl-TermReadKey.spec perl-TimeDate/perl-TimeDate.spec perl-Time-HiRes/perl-Time-HiRes.spec perl-URI/perl-URI.spec perl-XML-Dumper/perl-XML-Dumper.spec perl-XML-Encoding/perl-XML-Encoding.spec perl-XML-Grove/perl-XML-Grove.spec perl-XML-LibXML-Common/perl-XML-LibXML-Common.spec perl-XML-NamespaceSupport/perl-XML-NamespaceSupport.spec perl-XML-Parser/perl-XML-Parser.spec perl-XML-Twig/perl-XML-Twig.spec From wtogami at redhat.com Thu Mar 31 09:07:55 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 30 Mar 2005 23:07:55 -1000 Subject: [Fedora-packaging] perl module MODULE_COMPAT Message-ID: <424BBDEB.5070907@redhat.com> Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) As long as we're going through all FC4 perl modules, we might as well add this to all packages too. Just confirming, is this wanted in *ALL* packages that need perl, both regular arch and noarch? Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Thu Mar 31 11:29:59 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 31 Mar 2005 13:29:59 +0200 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <424BBDEB.5070907@redhat.com> References: <424BBDEB.5070907@redhat.com> Message-ID: <20050331132959.79acc1ea.bugs.michael@gmx.net> On Wed, 30 Mar 2005 23:07:55 -1000, Warren Togami wrote: > Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo > $version)) > > As long as we're going through all FC4 perl modules, we might as well > add this to all packages too. Just confirming, is this wanted in *ALL* > packages that need perl, both regular arch and noarch? Certainly for all Perl module packages which install files into versioned Perl vendor lib locations (or site lib, although that should not be done). That's the only way to ensure that the main "perl" actually supports loading from those versioned directories. From dag at wieers.com Thu Mar 31 13:02:19 2005 From: dag at wieers.com (Dag Wieers) Date: Thu, 31 Mar 2005 15:02:19 +0200 (CEST) Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <20050331132959.79acc1ea.bugs.michael@gmx.net> References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> Message-ID: On Thu, 31 Mar 2005, Michael Schwendt wrote: > On Wed, 30 Mar 2005 23:07:55 -1000, Warren Togami wrote: > > > Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo > > $version)) > > > > As long as we're going through all FC4 perl modules, we might as well > > add this to all packages too. Just confirming, is this wanted in *ALL* > > packages that need perl, both regular arch and noarch? > > Certainly for all Perl module packages which install files into versioned > Perl vendor lib locations (or site lib, although that should not be done). > That's the only way to ensure that the main "perl" actually supports loading > from those versioned directories. One important point, you are (or have been) effectively dropping support for every distro prior to FC1. Also perl offers compatibility with multiple versions, I guess that's why you want this (so a perl security bug allows you to ship a newer perl instead of backporting the fix). I'm not sure if the advantage of this strict/loose dependency weighs up against the disadvantage of dropping everything that came before FC1. I don't see a problem with no versioned dependency, since the only case where this really is a problem is when people install a package from another place (you don't have control over that anyway) or Fedora Extras ships suddenly without some perl module. If there was no disadvantage I would probably embrace this as much as the next guy. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From bugs.michael at gmx.net Thu Mar 31 13:12:13 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 31 Mar 2005 15:12:13 +0200 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> Message-ID: <20050331151213.12383119.bugs.michael@gmx.net> On Thu, 31 Mar 2005 15:02:19 +0200 (CEST), Dag Wieers wrote: > On Thu, 31 Mar 2005, Michael Schwendt wrote: > > > On Wed, 30 Mar 2005 23:07:55 -1000, Warren Togami wrote: > > > > > Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo > > > $version)) > > > > > > As long as we're going through all FC4 perl modules, we might as well > > > add this to all packages too. Just confirming, is this wanted in *ALL* > > > packages that need perl, both regular arch and noarch? > > > > Certainly for all Perl module packages which install files into versioned > > Perl vendor lib locations (or site lib, although that should not be done). > > That's the only way to ensure that the main "perl" actually supports loading > > from those versioned directories. > > One important point, you are (or have been) effectively dropping support > for every distro prior to FC1. No. That's what the perl-forward-compat package has been for: http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-compat-5.8.0-0.fdr.2.i386.rpm From alan at balclutha.org Thu Mar 31 17:14:20 2005 From: alan at balclutha.org (Alan Milligan) Date: Fri, 01 Apr 2005 03:14:20 +1000 Subject: [Fedora-packaging] %{_libdir}/rpm/brp-compress for perl modules Message-ID: <424C2FEC.7070808@balclutha.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warren, Check out the Perl CPAN module, it knows all about how to query CPAN. There's also something called CPANPLUS, but I'm not sure if it evolved past CPAN or not. Also, can we consider NOT putting the perl modules into the 'vendor' directory - clearly they are vanilla ;) Cheers, Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCTC/sCfroLk4EZpkRAoqPAKCTEydWfON/gIbK63wmy54wf/Ms+ACgxhQI IGXpozBu2+ov9lackZ+6oFw= =sKJw -----END PGP SIGNATURE----- From ville.skytta at iki.fi Thu Mar 31 17:54:38 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 31 Mar 2005 20:54:38 +0300 Subject: [Fedora-packaging] %{_libdir}/rpm/brp-compress for perl modules In-Reply-To: <424C2FEC.7070808@balclutha.org> References: <424C2FEC.7070808@balclutha.org> Message-ID: <1112291678.31596.94.camel@bobcat.mine.nu> On Fri, 2005-04-01 at 03:14 +1000, Alan Milligan wrote: > Also, can we consider NOT putting the perl modules into the 'vendor' > directory - clearly they are vanilla ;) Why not? That's why vendor install dirs exist: for stuff distributed by a vendor, such as RH/FC/FE. http://search.cpan.org/dist/perl/pod/perl561delta.pod#Enhanced_Installation_Directories http://search.cpan.org/dist/perl/INSTALL#Installation_Directories From ville.skytta at iki.fi Thu Mar 31 17:02:49 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 31 Mar 2005 20:02:49 +0300 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <20050331151213.12383119.bugs.michael@gmx.net> References: <424BBDEB.5070907@redhat.com> <20050331132959.79acc1ea.bugs.michael@gmx.net> <20050331151213.12383119.bugs.michael@gmx.net> Message-ID: <1112288569.31596.76.camel@bobcat.mine.nu> On Thu, 2005-03-31 at 15:12 +0200, Michael Schwendt wrote: > On Thu, 31 Mar 2005 15:02:19 +0200 (CEST), Dag Wieers wrote: > > One important point, you are (or have been) effectively dropping support > > for every distro prior to FC1. > > No. That's what the perl-forward-compat package has been for: > http://download.fedora.us/fedora/redhat/8.0/i386/RPMS.stable/perl-forward-compat-5.8.0-0.fdr.2.i386.rpm There's also http://bugzilla.fedora.us/show_bug.cgi?id=1498 for RH 7.3, but nobody has been interested enough to import it to Legacy. From symbiont at berlios.de Thu Mar 31 19:02:49 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 1 Apr 2005 03:02:49 +0800 Subject: [Fedora-packaging] perl module MODULE_COMPAT In-Reply-To: <424BBDEB.5070907@redhat.com> References: <424BBDEB.5070907@redhat.com> Message-ID: <200504010302.49909.symbiont@berlios.de> On Thursday 31 March 2005 17:07, Warren Togami wrote: > Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo > $version)) What about Requires: perl(abi) = 5.8 or whatever? Similar in the vein of how Python packages are being put together. :MODULE_COMPAT_ seems a bit overkill. Maybe I'm not seeing the whole picture, but it'd be nice to have some consistency even between different module-based interpreted languages. -- -jeff