From rc040203 at freenet.de Thu Feb 1 00:37:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 01:37:53 +0100 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> Message-ID: <1170290273.5838.533.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote: > >> The Java packages in Fedora which originally come from the JPackage > >> repo are the only packages which fall under this exception. And > >> those packages will always fall under this exception, forever and > >> ever, amen (or until something dramatic changes). > > RC> So Fedora will never have java packages of its own and depend on > RC> jpp? > > I'm having trouble understanding how you get from spot's statement > above to your conclusion. > > There are some packages which come from jpackage and there are some > that don't. Then you might be able to explain why * compatibility to packages from a 3rd party repo such as jpackage are of any importance to Fedora. Except that people ARE mixing jpp-packages with Fedora, just like they do with freshrpms, atrpms, livna, dribble and many others I don't see any difference. * why the origin of a package is of any importance to Fedora? > Has it been stated otherwise somewhere? Yes, e.g. his sentence above. I read this as "we will always continue to use jpp packages, and do not package java on our own". Ralf From Axel.Thimm at ATrpms.net Thu Feb 1 06:30:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Feb 2007 07:30:22 +0100 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170290273.5838.533.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> <1170290273.5838.533.camel@mccallum.corsepiu.local> Message-ID: <20070201063022.GA7169@neu.nirvana> On Thu, Feb 01, 2007 at 01:37:53AM +0100, Ralf Corsepius wrote: > On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote: > > >>>>> "RC" == Ralf Corsepius writes: > > > > RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote: > > >> The Java packages in Fedora which originally come from the JPackage > > >> repo are the only packages which fall under this exception. And > > >> those packages will always fall under this exception, forever and > > >> ever, amen (or until something dramatic changes). > > > > RC> So Fedora will never have java packages of its own and depend on > > RC> jpp? > > > > I'm having trouble understanding how you get from spot's statement > > above to your conclusion. > > > > There are some packages which come from jpackage and there are some > > that don't. > Then you might be able to explain why > * compatibility to packages from a 3rd party repo such as jpackage are > of any importance to Fedora. > > Except that people ARE mixing jpp-packages with Fedora, just like they > do with freshrpms, atrpms, livna, dribble and many others I don't see > any difference. I don't think it's bad that Fedora cares about compatibility with 3rd party repos, in fact I wish that this kind of mutual cooperation rather extends. As a general rule of thumb I would say that o cooperation enlarges the community and that's one of Fedora's strength, o if it's cheaper for Fedora to cater for compatibility than reinvent the wheel, then why not? o if compatibility obstructs otherwise something and is not worth it can always be dumped, i.e. it is not the highest goal -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Feb 1 06:52:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Feb 2007 07:52:51 +0100 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170189972.31747.32.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> Message-ID: <20070201065251.GB7169@neu.nirvana> On Tue, Jan 30, 2007 at 02:46:12PM -0600, Tom 'spot' Callaway wrote: > OK guys, here's the item that I've been working on with the JPackage > folks for a while: > > http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage > > This exception documents how Java packages which come from JPackage are > to be handled, and paves the way for the eventual removal of the jpp > tag. > > Fernando Nasser, Jesse Keating, and many others helped me put this > together, and they all seem pretty happy with what we've got in this > final draft. > > FPC members: Please vote on this item. > > Thanks, > > ~spot > I think we can get both the upgrade paths sane and the guidelines non-violated (and in no need for exceptions) by using the proposed scheme, but drop the jpp part, e.g. from the example || '''JPackage''' || '''Fedora Package''' || '''Status''' || '''Highest RPMver''' || || javacc-4.0-3jpp.src.rpm || javacc-4.0-3.1.fc7.src.rpm || Package merged from JPackage into Fedora devel || Fedora || || javacc-4.0-3jpp.src.rpm || javacc-4.0-3.2.fc7.src.rpm || Fedora package has a bug fixed, bump subrelease || Fedora || || javacc-4.0-3jpp.src.rpm || javacc-4.0-3.3.fc7.src.rpm || Fedora package is rebuilt for new gcc, bump subrel || Fedora || || javacc-4.0-4jpp.src.rpm || javacc-4.0-3.3.fc7.src.rpm || JPackage is updated to fix a bug, bumps major release || JPackage || || javacc-4.0-4jpp.src.rpm || javacc-4.0-4.1.fc7.src.rpm || Fedora package is merged from new JPackage || Fedora || || javacc-5.0-1jpp.src.rpm || javacc-4.0-4.1.fc7.src.rpm || JPackage releases new version of package || JPackage || || javacc-5.0-1jpp.src.rpm || javacc-5.0-1.1.fc7.src.rpm || Fedora package is merged from new JPackage || Fedora || || javacc-5.0-1jpp.src.rpm || javacc-5.0-1.1.fc7.src.rpm || FC-7 is released, package is no longer in devel || Fedora || || javacc-5.0-1jpp.src.rpm || javacc-5.0-1.1.fc7.1.src.rpm || A bug is fixed in the FC-7 package. || Fedora || If s/o wants to visually emphasize the hierarchical structure in the above one could use the "_" separator, e.g. javacc-4.0-3_1.fc7.src.rpm. Remember: numbers win over alpha in rpm, so we have ensure upgrade paths, e.g. jpp < ..blah < jpp Furthermore I think that | Once the Fedora package is out of the devel branch and into a | released branch, the release and subrelease fields are frozen. These | packages are now subject to the Minor release bumps for old branches | rule. is very bad, we often explored that the space after the %{?dist} is harmful to use, and it's not neccessary either. Why not continue to use the second integer and freezing it? In the example above javacc-5.0-1.1.fc7.1.src.rpm should become javacc-5.0-1.2.fc7.src.rpm and if the bug is worth it it would even get rebuilt for FC6 (or RHEL etc). There are still different optinions on whether using the space after the %{?dist} should be allowed or not (otherwise we'd have a part in the guidelines), but in any case the java/jpackage packages don't need it more or less than other packages, so that's not the use case to bring this up again. Since neither of the two exceptions are really needed, I'd say -1 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Feb 1 07:01:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Feb 2007 08:01:42 +0100 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <20070201065251.GB7169@neu.nirvana> References: <1170189972.31747.32.camel@localhost.localdomain> <20070201065251.GB7169@neu.nirvana> Message-ID: <20070201070142.GC7169@neu.nirvana> On Thu, Feb 01, 2007 at 07:52:51AM +0100, Axel Thimm wrote: > There are still different optinions on whether using the space after > the %{?dist} should be allowed or not (otherwise we'd have a part in > the guidelines) I meant we'd have this disallowed in the guidelines, currently we do have this with a big warning. Anyway as written before it doesn't apply more to jpackage packages than any other package, so we don't even need to discuss whether it's sane or not in general (it isn't ;). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Thu Feb 1 07:39:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 08:39:38 +0100 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <20070201063022.GA7169@neu.nirvana> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> <1170290273.5838.533.camel@mccallum.corsepiu.local> <20070201063022.GA7169@neu.nirvana> Message-ID: <1170315578.2588.99.camel@mccallum.corsepiu.local> On Thu, 2007-02-01 at 07:30 +0100, Axel Thimm wrote: > On Thu, Feb 01, 2007 at 01:37:53AM +0100, Ralf Corsepius wrote: > > On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote: > > > >>>>> "RC" == Ralf Corsepius writes: > > > > > > RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote: > > > >> The Java packages in Fedora which originally come from the JPackage > > > >> repo are the only packages which fall under this exception. And > > > >> those packages will always fall under this exception, forever and > > > >> ever, amen (or until something dramatic changes). > > > > > > RC> So Fedora will never have java packages of its own and depend on > > > RC> jpp? > > > > > > I'm having trouble understanding how you get from spot's statement > > > above to your conclusion. > > > > > > There are some packages which come from jpackage and there are some > > > that don't. > > Then you might be able to explain why > > * compatibility to packages from a 3rd party repo such as jpackage are > > of any importance to Fedora. > > > > Except that people ARE mixing jpp-packages with Fedora, just like they > > do with freshrpms, atrpms, livna, dribble and many others I don't see > > any difference. > > I don't think it's bad that Fedora cares about compatibility with 3rd > party repos, Neither do I. > in fact I wish that this kind of mutual cooperation > rather extends. Exactly this is the point, I am asking: Why explicitly care about jpp? Ralf From ville.skytta at iki.fi Thu Feb 1 07:48:10 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 1 Feb 2007 09:48:10 +0200 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170189972.31747.32.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> Message-ID: <200702010948.10362.ville.skytta@iki.fi> On Tuesday 30 January 2007 22:46, Tom 'spot' Callaway wrote: > http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage "According to Fernando Nasser, JPackage RPMS only use integers in the Release: field, in the format Xjpp. If this is the case, then the following format will ensure clean upgrades from Fedora to JPackage and so forth: [...]" JPackage's pre-release Release: tags are not Xjpp only. Was this considered in the draft? Some random examples: classpathx-jaxp-1.0-0.beta1.10jpp cpptasks-1.0-0.b4.1jpp cryptix-asn1-0.1.12-0.cvs20011119.7jpp activemq3-3.2.5-0.r1125.2jpp radeox-0.9-0.beta.2jpp More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/ From Axel.Thimm at ATrpms.net Thu Feb 1 07:48:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Feb 2007 08:48:38 +0100 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170315578.2588.99.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> <1170290273.5838.533.camel@mccallum.corsepiu.local> <20070201063022.GA7169@neu.nirvana> <1170315578.2588.99.camel@mccallum.corsepiu.local> Message-ID: <20070201074838.GE7169@neu.nirvana> On Thu, Feb 01, 2007 at 08:39:38AM +0100, Ralf Corsepius wrote: > On Thu, 2007-02-01 at 07:30 +0100, Axel Thimm wrote: > > On Thu, Feb 01, 2007 at 01:37:53AM +0100, Ralf Corsepius wrote: > > > On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote: > > > > >>>>> "RC" == Ralf Corsepius writes: > > > > > > > > RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote: > > > > >> The Java packages in Fedora which originally come from the JPackage > > > > >> repo are the only packages which fall under this exception. And > > > > >> those packages will always fall under this exception, forever and > > > > >> ever, amen (or until something dramatic changes). > > > > > > > > RC> So Fedora will never have java packages of its own and depend on > > > > RC> jpp? > > > > > > > > I'm having trouble understanding how you get from spot's statement > > > > above to your conclusion. > > > > > > > > There are some packages which come from jpackage and there are some > > > > that don't. > > > Then you might be able to explain why > > > * compatibility to packages from a 3rd party repo such as jpackage are > > > of any importance to Fedora. > > > > > > Except that people ARE mixing jpp-packages with Fedora, just like they > > > do with freshrpms, atrpms, livna, dribble and many others I don't see > > > any difference. > > > > I don't think it's bad that Fedora cares about compatibility with 3rd > > party repos, > Neither do I. > > > in fact I wish that this kind of mutual cooperation > > rather extends. > > Exactly this is the point, I am asking: Why explicitly care about jpp? OK, sorry I misunderstood you completely, I read your comments like criticism for cooperation. I can only guess about why jpp is treated "better" than other repos: o one needs to start somewhere o java is a key technology also required for RHEL, so there is vital interest in RH for it. o less patent encumbered/closed source parts than other repos o good quality packaging If I didn't knew better I'd add o good cooperation with the 3rd party maintainers but according to some of Jesse's comments this seems to be less the case (or was, it may have improved since). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Feb 1 09:18:06 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 1 Feb 2007 10:18:06 +0100 (CET) Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170315578.2588.99.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> <1170290273.5838.533.camel@mccallum.corsepiu.local> <20070201063022.GA7169@neu.nirvana> <1170315578.2588.99.camel@mccallum.corsepiu.local> Message-ID: <40499.192.54.193.51.1170321486.squirrel@rousalka.dyndns.org> Le Jeu 1 f?vrier 2007 08:39, Ralf Corsepius a ?crit : > On Thu, 2007-02-01 at 07:30 +0100, Axel Thimm wrote: >> in fact I wish that this kind of mutual cooperation >> rather extends. > > Exactly this is the point, I am asking: Why explicitly care about jpp? Because as far as I know that's the only 3rd-party repository that managed: - to get community packagers from different distros working together - to get paid distro packagers work with the community packagers - to create a common rpm namespace accross rpm distros (unfortunately debian got its own affort on rails at about the same time so you still have a rpm/deb disconnect) - to have packaging work flow both to and from fedora (and other distros) I don't know if the jpp model could be extended. It was successful largely because there was no in-distro java packaging when jpp was created, vendor java packaging was awful, so there was no competing packagesets and NIH attitudes to work against. You'll note when jpp is involved @rh people argue for 3rd-party cooperation and "community" fedora people against it. -- Nicolas Mailhot From rc040203 at freenet.de Thu Feb 1 09:21:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 10:21:35 +0100 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <20070201074838.GE7169@neu.nirvana> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> <1170290273.5838.533.camel@mccallum.corsepiu.local> <20070201063022.GA7169@neu.nirvana> <1170315578.2588.99.camel@mccallum.corsepiu.local> <20070201074838.GE7169@neu.nirvana> Message-ID: <1170321695.2588.152.camel@mccallum.corsepiu.local> On Thu, 2007-02-01 at 08:48 +0100, Axel Thimm wrote: > On Thu, Feb 01, 2007 at 08:39:38AM +0100, Ralf Corsepius wrote: > > On Thu, 2007-02-01 at 07:30 +0100, Axel Thimm wrote: > > > On Thu, Feb 01, 2007 at 01:37:53AM +0100, Ralf Corsepius wrote: > > > > On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote: > > > > > >>>>> "RC" == Ralf Corsepius writes: > > > > > > > > > > RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway wrote: > > > > > >> The Java packages in Fedora which originally come from the JPackage > > > > > >> repo are the only packages which fall under this exception. And > > > > > >> those packages will always fall under this exception, forever and > > > > > >> ever, amen (or until something dramatic changes). > > > > > > > > > > RC> So Fedora will never have java packages of its own and depend on > > > > > RC> jpp? > > > > > > > > > > I'm having trouble understanding how you get from spot's statement > > > > > above to your conclusion. > > > > > > > > > > There are some packages which come from jpackage and there are some > > > > > that don't. > > > > Then you might be able to explain why > > > > * compatibility to packages from a 3rd party repo such as jpackage are > > > > of any importance to Fedora. > > > > > > > > Except that people ARE mixing jpp-packages with Fedora, just like they > > > > do with freshrpms, atrpms, livna, dribble and many others I don't see > > > > any difference. > > > > > > I don't think it's bad that Fedora cares about compatibility with 3rd > > > party repos, > > Neither do I. > > > > > in fact I wish that this kind of mutual cooperation > > > rather extends. > > > > Exactly this is the point, I am asking: Why explicitly care about jpp? > > OK, sorry I misunderstood you completely, I read your comments like > criticism for cooperation. Let me put it this way: To me, it is a bit bewildering to see a project initially being launched as "integration platform for 3rd parties" to explicitly take one of its "rivals" into consideration as a "special exception" that someone labeled "forever, ... amen". If "Fedora integration" really works out, then we should see "integrated packages" and external 3rd party providing add-on packages, which should be treated as private pleasures of those implementing it. If Fedora wants to take external repos into account, then I'd prefer not to see a singular exception for jpp, but generally applicable rules. Unfortunately, I don't see how this can be implemented nor am I expecting much interest from inside Fedora to address this any time soon. > I can only guess about why jpp is treated "better" than other repos: > > o one needs to start somewhere > o java is a key technology also required for RHEL, so there is vital > interest in RH for it. Probably, only somebody @redcom.com can answer this, but I would not deny this thought. > o less patent encumbered/closed source parts than other repos Patents yes. Wrt. "non-free" I don't see that jpp is substantially different from how livna and other 3rd parties shipping "non-free"/non-OSI compliant package. Wrt. voting, I am undecided, because, to me, the proposal boils down to deciding between two "mediocre compromises": a) Accepting it would mean catering a pragmatical compromise, which isn't necessarily in the Fedora community's long-term interests and which might weaken OpenSource in longer terms. b) Rejecting it would mean insisting on a position that isn't necessarily in RH's nor Fedora's interest wrt. java, technically is hardly resolvable, but would help the "wider community" (3rd parties). I would have voted +1 if I'd sense this proposal to be a short-term compromise and precedence aiming at systematic integration of 3rd parties. Spot's comment lets me think this doesn't apply. Ralf From Axel.Thimm at ATrpms.net Thu Feb 1 09:33:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Feb 2007 10:33:06 +0100 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170321695.2588.152.camel@mccallum.corsepiu.local> References: <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> <1170290273.5838.533.camel@mccallum.corsepiu.local> <20070201063022.GA7169@neu.nirvana> <1170315578.2588.99.camel@mccallum.corsepiu.local> <20070201074838.GE7169@neu.nirvana> <1170321695.2588.152.camel@mccallum.corsepiu.local> Message-ID: <20070201093306.GA12195@neu.nirvana> On Thu, Feb 01, 2007 at 10:21:35AM +0100, Ralf Corsepius wrote: > technically is hardly resolvable, I'm not sure it's really that hard unless I'm overseeing something. See my other post on how we can import jpp packages w/o sacrificing guideline sanity, e.g. by using {.|-} hierarchy (e.g. removing the jpp string) and not endorsing any post-disttag tagging than we already do. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Feb 1 09:52:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 1 Feb 2007 10:52:32 +0100 (CET) Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170321695.2588.152.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> <1170290273.5838.533.camel@mccallum.corsepiu.local> <20070201063022.GA7169@neu.nirvana> <1170315578.2588.99.camel@mccallum.corsepiu.local> <20070201074838.GE7169@neu.nirvana> <1170321695.2588.152.camel@mccallum.corsepiu.local> Message-ID: <44627.192.54.193.51.1170323552.squirrel@rousalka.dyndns.org> Le Jeu 1 f?vrier 2007 10:21, Ralf Corsepius a ?crit : > a) Accepting it would mean catering a pragmatical compromise, which > isn't necessarily in the Fedora community's long-term interests and > which might weaken OpenSource in longer terms. Could the Don Quichottes that are objecting to peaceful jpp cooperation provide documented examples when working with jpp has been harmful to Fedora (aside from the "harm" of three letters in versions?) Could we have more concrete arguments than it "isn't necessarily in the Fedora community's long-term interests" ? Do you realise the only reason we have a packaged FLOSS java stack today (and not in two years) is it was bootstraped on closed jpp jvm packages ? Is breaking ties with other entities for the sake of not having to think about them in the Fedora community's long-term interest ? /me is getting mad about all the FUDing on this issue. -- Nicolas Mailhot From paskalis at di.uoa.gr Thu Feb 1 11:18:52 2007 From: paskalis at di.uoa.gr (Sarantis Paskalis) Date: Thu, 1 Feb 2007 13:18:52 +0200 Subject: [Fedora-packaging] User IDs in Core packages? Message-ID: <20070201111852.GA29690@gallagher.di.uoa.gr> Hello, Is there any recommendation for mandating/enforcing/changing etc. user IDs in (previously) Core packages? There are some rpm packages in the upcomming merge that hardcode a specific UID in the specfile to use (I was looking at privoxy, which hardcodes the number 73). The documentation at http://fedoraproject.org/wiki/PackageUserCreation recommends fedora-usermgmt but the text seemed to imply that it were for Extras packages only. Is it implied that the default /etc/passwd file should contain the predefined values for the most important packages and the rest should find an alternative way? What is the procedure of allocating UIDs/GIDs to those system users (examples are haldaemon, apache, dbus, sshd, rpc to name a few). Should the packages to be reviewed maintain their existing UIDs/GIDs hardcoded and document it somewhere? The default values in /etc/passwd and /etc/group are the following (taken from setup-2.6.2-1.fc7.src.rpm in rawhide): #/etc/passwd root:*:0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin:/sbin/nologin daemon:*:2:2:daemon:/sbin:/sbin/nologin adm:*:3:4:adm:/var/adm:/sbin/nologin lp:*:4:7:lp:/var/spool/lpd:/sbin/nologin sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail:/sbin/nologin news:*:9:13:news:/etc/news: uucp:*:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:*:11:0:operator:/root:/sbin/nologin games:*:12:100:games:/usr/games:/sbin/nologin gopher:*:13:30:gopher:/var/gopher:/sbin/nologin ftp:*:14:50:FTP User:/var/ftp:/sbin/nologin nobody:*:99:99:Nobody:/:/sbin/nologin #/etc/group root::0:root bin::1:root,bin,daemon daemon::2:root,bin,daemon sys::3:root,bin,adm adm::4:root,adm,daemon tty::5: disk::6:root lp::7:daemon,lp mem::8: kmem::9: wheel::10:root mail::12:mail news::13:news uucp::14:uucp man::15: games::20: gopher::30: dip::40: ftp::50: lock::54: nobody::99: users::100: Thanks, -- Sarantis From Axel.Thimm at ATrpms.net Thu Feb 1 12:03:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Feb 2007 13:03:19 +0100 Subject: [Fedora-packaging] Re: User IDs in Core packages? In-Reply-To: <20070201111852.GA29690@gallagher.di.uoa.gr> References: <20070201111852.GA29690@gallagher.di.uoa.gr> Message-ID: <20070201120319.GC12195@neu.nirvana> On Thu, Feb 01, 2007 at 01:18:52PM +0200, Sarantis Paskalis wrote: > Is there any recommendation for mandating/enforcing/changing etc. user > IDs in (previously) Core packages? There are some rpm packages in the > upcomming merge that hardcode a specific UID in the specfile to use (I > was looking at privoxy, which hardcodes the number 73). Hardcoding is OK, if the user/group has made it into the official list which is /usr/share/doc/setup-*/uidgid. In there privoxy has indeed the uid/gid of 73. > Is it implied that the default /etc/passwd file should contain the > predefined values for the most important packages and the rest should > find an alternative way? What is the procedure of allocating UIDs/GIDs > to those system users (examples are haldaemon, apache, dbus, sshd, rpc > to name a few). First check if they aren't already allocated in the list above. If you really, really need a fixed reservation for a new uid/gid you would have to get the owner (group) of "setup" to concur. I think this is mostly in the hands of the former "cabal" group, e.g. ask one of Bill Nottingham, Jesse Keating or Phil Knirsch, or directly the fesco committee. Theoretically it could belong to the PC's job to assign these, but it hasn't been until now, and it needs someone barking back louder than the PC is able to when someone tries to change the list :) But we should note somewhere in the guidelines who the gatekeeper for these uids/gids is. > Should the packages to be reviewed maintain their existing UIDs/GIDs > hardcoded and document it somewhere? If they are in the list, they should silently pass, if they are not, it should be raised as an issue, perhaps the list is missing some, or others don't need to reserve fixed uids/gids.. > The default values in /etc/passwd and /etc/group are the following > (taken from setup-2.6.2-1.fc7.src.rpm in rawhide): For reference and archival puposes here is the current list in FC6 (/usr/share/doc/setup-2.6.1.1/uidgid). Packages using these uid/gid should be OK. NAME UID GID HOME SHELL PACKAGES root 0 0 /root /bin/bash setup bin 1 1 /bin /sbin/nologin setup daemon 2 2 /sbin /sbin/nologin setup sys - 3 - - setup adm 3 4 /var/adm /bin/bash setup tty - 5 - - setup disk - 6 - - setup lp 4 7 /var/spool/lpd /sbin/nologin setup mem - 8 - - setup kmem - 9 - - setup wheel - 10 - - setup sync 5 (0) /sbin /bin/sync setup shutdown 6 (0) /sbin /sbin/shutdown setup halt 7 (0) /sbin /sbin/halt setup mail 8 12 /var/spool/mail /sbin/nologin setup news 9 13 /var/spool/news - setup uucp 10 14 /var/spool/uucp /sbin/nologin setup operator 11 (0) /root /sbin/nologin setup games 12 (100) /usr/games /sbin/nologin setup gopher 13 30 /usr/lib/gopher-data /sbin/nologin setup ftp 14 50 /var/ftp /sbin/nologin setup man - 15 - - setup floppy - 19 - - dev,MAKEDEV games - 20 - - setup slocate - 21 - - slocate utmp - 22 - - initscripts,libutempter squid 23 23 /var/spool/squid /dev/null squid pvm 24 24 /usr/share/pvm3 /bin/bash pvm named 25 25 /var/named /bin/false bind postgres 26 26 /var/lib/pgsql /bin/bash postgresql-server mysql 27 27 /var/lib/mysql /bin/bash mysql nscd 28 28 / /bin/false nscd rpcuser 29 29 /var/lib/nfs /bin/false nfs-utils console - 31 - - dev rpc 32 32 / /bin/false portmap amanda 33 (6) /var/lib/amanda /bin/false amanda netdump 34 34 /var/crash /bin/bash netdump-client, netdump-server utempter - 35 - - libutempter rpm 37 37 /var/lib/rpm /bin/bash rpm ntp 38 38 /etc/ntp /sbin/nologin ntp dip - 40 - - setup mailman 41 41 /var/mailman /bin/false mailman gdm 42 42 /var/gdm /bin/bash gdm xfs 43 43 /etc/X11/fs /bin/false XFree86-xfs pppusers - 44 - - linuxconf popusers - 45 - - linuxconf slipusers - 46 - - linuxconf mailnull 47 47 /var/spool/mqueue /dev/null sendmail apache 48 48 /var/www /bin/false apache wnn 49 49 /home/wnn /bin/bash FreeWnn smmsp 51 51 /var/spool/mqueue /dev/null sendmail tomcat 53 53 /var/lib/tomcat /sbin/nologin tomcat lock - 54 - - lockdev ldap 55 55 /var/lib/ldap /bin/false openldap-servers frontpage 56 56 /var/www /bin/false mod_frontpage nut 57 57 /var/lib/ups /bin/false nut beagleindex 58 58 /var/cache/beagle /bin/false beagle piranha 60 60 /etc/sysconfig/ha /dev/null piranha wine - 66 - - wine pegasus 66 65 /var/lib/Pegasus /sbin/nologin tog-pegasus webalizer 67 67 /var/www/html/usage /sbin/nologin webalizer haldaemon 68 68 / /sbin/nologin hal vcsa 69 69 - /sbin/nologin dev,MAKEDEV avahi 70 70 / /sbin/nologin avahi privoxy 73 73 /etc/privoxy /bin/bash privoxy sshd 74 74 /var/empty/sshd /sbin/nologin openssh-server radvd 75 75 / /bin/false radvd cyrus 76 (12) /var/imap /bin/bash cyrus-imapd shadow - 76 - - cyrus-imapd pcap 77 77 /var/arpwatch /sbin/nologin arpwatch fax 78 78 /var/spool/fax /sbin/nologin mgetty nocpulse 79 79 /etc/sysconfig/nocpulse /bin/bash nocpulse desktop 80 80 - /sbin/nologin desktop-file-utils dbus 81 81 / /sbin/nologin dbus jonas 82 82 /var/lib/jonas /sbin/nologin jonas clamav 83 83 /tmp /sbin/nologin clamav screen - 84 - - screen quaggavt - 85 - - quagga sabayon 86 86 - /sbin/nologin sabayon winbind_auth - 88 - - samba-common postfix 89 89 /var/spool/postfix /bin/true postfix postdrop - 90 - - postfix majordomo 91 91 /usr/lib/majordomo /bin/bash majordomo quagga 92 92 / /sbin/nologin quagga exim 93 93 /var/spool/exim /sbin/nologin exim distcache 94 94 / /sbin/nologin distcache radiusd 95 95 / /bin/false freeradius hsqldb 96 96 /var/lib/hsqldb /sbin/nologin hsqldb dovecot 97 97 /usr/libexec/dovecot /sbin/nologin dovecot ident 98 98 / /sbin/nologin ident nobody 99 99 / /sbin/nologin setup users - 100 - - setup gnats ? ? ? ? gnats, gnats-db listar ? ? ? ? listar nfsnobody 65534 65534 /var/lib/nfs /sbin/nologin nfs-utils # Note: nfsnobdy is 4294967294 on 64-bit platforms (-2) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Thu Feb 1 12:30:41 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 13:30:41 +0100 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <44627.192.54.193.51.1170323552.squirrel@rousalka.dyndns.org> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> <1170290273.5838.533.camel@mccallum.corsepiu.local> <20070201063022.GA7169@neu.nirvana> <1170315578.2588.99.camel@mccallum.corsepiu.local> <20070201074838.GE7169@neu.nirvana> <1170321695.2588.152.camel@mccallum.corsepiu.local> <44627.192.54.193.51.1170323552.squirrel@rousalka.dyndns.org> Message-ID: <1170333042.2588.249.camel@mccallum.corsepiu.local> On Thu, 2007-02-01 at 10:52 +0100, Nicolas Mailhot wrote: > Le Jeu 1 f?vrier 2007 10:21, Ralf Corsepius a ?crit : > > > a) Accepting it would mean catering a pragmatical compromise, which > > isn't necessarily in the Fedora community's long-term interests and > > which might weaken OpenSource in longer terms. > > Could the Don Quichottes that are objecting to peaceful jpp cooperation > provide documented examples when working with jpp has been harmful to > Fedora (aside from the "harm" of three letters in versions?) > > Could we have more concrete arguments than it "isn't necessarily in the > Fedora community's long-term interests" ? IMO, if Fedora was gradually approaching it's initial objectives, we would have FLOSS java packages inside of FE and would not have to resort to using jpp - That's why I was asking if Fedora was failing on java. > Do you realise the only reason we have a packaged FLOSS java stack > today > (and not in two years) is it was bootstraped on closed jpp jvm packages ? I do - But do you realize that the only reason I am able to run Fedora in reasonable manners at all is using non-free packages from livna, jpp and other sources? It's the reason why I am all for implementing ways to allow better integration of 3rd party repos. But pushing jpp into a special exception, to me means "measuring by double standards". > Is breaking ties with other entities for the sake of not having to think > about them in the Fedora community's long-term interest? What makes you think this? Firstly, I am not the FPC, I am just an individual with an opinion, who happens to have a vote within the FPC. And I hope to have been clear enough, on not having made up my mind, yet but to be considering the trade-offs. In a nutshell, the question is quite simple: Why should jpp put into a special position and other 3rd parties be ignored, which (at least for my way of using Fedora) are equally vitally important? We would not have this discussion if Spot was "giving a deadline and was talking about a transitional limited period of time" or if this all was about "using jpp as precedence on 3rd party integration". Or differently: * Empower me with arguments why Fedora's java needs the jpp suffix? * Empower me with arguments why jpp package can't be merge into Fedora? Don't get me wrong, I am seriously asking and want to know. Ralf From jkeating at redhat.com Thu Feb 1 13:12:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Feb 2007 08:12:21 -0500 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170315578.2588.99.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <20070201063022.GA7169@neu.nirvana> <1170315578.2588.99.camel@mccallum.corsepiu.local> Message-ID: <200702010812.21465.jkeating@redhat.com> On Thursday 01 February 2007 02:39, Ralf Corsepius wrote: > Exactly this is the point, I am asking: Why explicitly care about jpp? The reason we explicitly care about jpackage is because our (Red Hat's) java folks do _all_ of their packaging upstream at jpackage, and just import the results downstream within RHEL and Fedora. This workflow allows them to manage far more java packages than if they were to do it on their own within RH/Fedora. We would like to enable them to continue this, with jpackage being the defacto standard for java packaging, we just import what they do as other distributions can and do. There isn't much that prevents other packagers from doing this with their upstreams, so long as they adhere to the guidelines. We had to create some special cases for jpackage due to how their upstream works and a somewhat unresolvable clash with our guidelines. We'd rather not have to do this, but in this case it seemed unavoidable. Personally I don't like it, and I'll fight tooth/nail against any further exceptions like this, but I did see the need for us to have java packages in Fedora. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Feb 1 13:16:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Feb 2007 08:16:19 -0500 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170333042.2588.249.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <44627.192.54.193.51.1170323552.squirrel@rousalka.dyndns.org> <1170333042.2588.249.camel@mccallum.corsepiu.local> Message-ID: <200702010816.19407.jkeating@redhat.com> On Thursday 01 February 2007 07:30, Ralf Corsepius wrote: > In a nutshell, the question is quite simple: Why should jpp put into a > special position and other 3rd parties be ignored, which (at least for > my way of using Fedora) are equally vitally important? We only allow importing of the free jpp packages. We have our own java compiler and runtime (gcj) that is used for our jpp packages rather than the non-free jvm. If the jvm was free, the answer for java on Fedora might actually be "use jpackage, here is a repo file" but that isn't the case. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paskalis at di.uoa.gr Thu Feb 1 13:17:50 2007 From: paskalis at di.uoa.gr (Sarantis Paskalis) Date: Thu, 1 Feb 2007 15:17:50 +0200 Subject: [Fedora-packaging] Re: User IDs in Core packages? In-Reply-To: <20070201120319.GC12195@neu.nirvana> References: <20070201111852.GA29690@gallagher.di.uoa.gr> <20070201120319.GC12195@neu.nirvana> Message-ID: <20070201131750.GA31815@gallagher.di.uoa.gr> On Thu, Feb 01, 2007 at 01:03:19PM +0100, Axel Thimm wrote: > On Thu, Feb 01, 2007 at 01:18:52PM +0200, Sarantis Paskalis wrote: > > Is there any recommendation for mandating/enforcing/changing etc. user > > IDs in (previously) Core packages? There are some rpm packages in the > > upcomming merge that hardcode a specific UID in the specfile to use (I > > was looking at privoxy, which hardcodes the number 73). > > Hardcoding is OK, if the user/group has made it into the official list > which is /usr/share/doc/setup-*/uidgid. In there privoxy has indeed > the uid/gid of 73. Thanks for the pointer. I didn't know its existence. One issue that arises now is whether a merge of http://fedoraproject.org/wiki/PackageUserRegistry and this file (/usr/share/doc/setup-*/uidgid) is to be considered. Thanks, -- Sarantis From jkeating at redhat.com Thu Feb 1 13:20:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Feb 2007 08:20:10 -0500 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170333042.2588.249.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <44627.192.54.193.51.1170323552.squirrel@rousalka.dyndns.org> <1170333042.2588.249.camel@mccallum.corsepiu.local> Message-ID: <200702010820.10627.jkeating@redhat.com> On Thursday 01 February 2007 07:30, Ralf Corsepius wrote: > Or differently: > * Empower me with arguments why Fedora's java needs the jpp suffix? These are in the wiki. Please point out what you don't understand. > * Empower me with arguments why jpp package can't be merge into Fedora? jpp in this case is considered an upstream. The upstream isn't where the jar files and such live, jpp is, and jpp happens to release things in (s)rpm form. This makes it very easy to import the srpms, as jpackage is striving to follow _our_ guidelines so that this can happen. There are some folks what work in jpackage that have very strong desires to _not_ sign CLAs or not contribute directly to Fedora/Red Hat. I respect these desires, and continue to see jpackage is a vibrant package upstream for java users. Our java team chooses to do their packaging work within the jpackage upstream, benefiting all users of jpackage, not just Fedora. Not every distribution wants gcj compiled java, that's just something Fedora has to do for legal/oss reasons. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Feb 1 13:20:48 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 1 Feb 2007 14:20:48 +0100 (CET) Subject: [Fedora-packaging] Re: Exception for JPackage Message-ID: <52358.192.54.193.51.1170336048.squirrel@rousalka.dyndns.org> Le Jeu 1 f?vrier 2007 13:30, Ralf Corsepius a ?crit : > * Empower me with arguments why Fedora's java needs the jpp suffix? > * Empower me with arguments why jpp package can't be merge into Fedora? This has been answered many times already. 1. There is already a bidirectionnal merge process between Fedora and JPP (Fedora gets the results of JPP work, JPP gets the results of Fedora work, and everyone cross-checks the other). 2. The java team can "fix" a jpp package at the jpp level any time they need to. Any other Fedora contributor can get jpp access now by demontrating packaging skills, if he doesn't want to rely on Fernando Nasser 3. JPP is not a drag - it will go as fast and do as strict packaging as its contributors (including the fedora java team) allow. The "worst" scenarii that can happen are : - the Fedora Java team doing all the work there, at which point JPP policy would effectively be Fedora policy - the Fedora Java team offloading all the work @jpp, at which point JPP policy may not be aligned with Fedora policy at all but Fedora would get all its java packaging for free 4. Pulling packages in-Fedora without the back-merging means losing the packaging & review work that happens @jpp, and getting cross-distro namespace divergence for zero wins The jpp suffix is there to help the workflow of the java team by identifying packages participating to this process (because we've refused to fix rpm groups and only provided a comps alternative the anaconda guys do not want to share) -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Thu Feb 1 13:28:31 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Feb 2007 14:28:31 +0100 Subject: [Fedora-packaging] Re: User IDs in Core packages? In-Reply-To: <20070201131750.GA31815@gallagher.di.uoa.gr> References: <20070201111852.GA29690@gallagher.di.uoa.gr> <20070201120319.GC12195@neu.nirvana> <20070201131750.GA31815@gallagher.di.uoa.gr> Message-ID: <20070201132831.GH12195@neu.nirvana> On Thu, Feb 01, 2007 at 03:17:50PM +0200, Sarantis Paskalis wrote: > On Thu, Feb 01, 2007 at 01:03:19PM +0100, Axel Thimm wrote: > > On Thu, Feb 01, 2007 at 01:18:52PM +0200, Sarantis Paskalis wrote: > > > Is there any recommendation for mandating/enforcing/changing etc. user > > > IDs in (previously) Core packages? There are some rpm packages in the > > > upcomming merge that hardcode a specific UID in the specfile to use (I > > > was looking at privoxy, which hardcodes the number 73). > > > > Hardcoding is OK, if the user/group has made it into the official list > > which is /usr/share/doc/setup-*/uidgid. In there privoxy has indeed > > the uid/gid of 73. > > Thanks for the pointer. I didn't know its existence. One issue that > arises now is whether a merge of > http://fedoraproject.org/wiki/PackageUserRegistry and this file > (/usr/share/doc/setup-*/uidgid) is to be considered. These are very different objects, the uidgid are fixed, absolute uids/gids, while the wiki URL above is for the floating model of adding uids/gids (e.g. there is some per-machine settable value that is added). Personally I strongly recommend against using the floating model, because a) the added base value is arbitrary b) any change after the first install of the helper tool of this base value will break all previous installs using this method c) it isn't transparent to the user (admin) that some upper part of his uid/gid space is reserved for this method, so he may be accidentially using it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paskalis at di.uoa.gr Thu Feb 1 13:57:59 2007 From: paskalis at di.uoa.gr (Sarantis Paskalis) Date: Thu, 1 Feb 2007 15:57:59 +0200 Subject: [Fedora-packaging] Re: User IDs in Core packages? In-Reply-To: <20070201132831.GH12195@neu.nirvana> References: <20070201111852.GA29690@gallagher.di.uoa.gr> <20070201120319.GC12195@neu.nirvana> <20070201131750.GA31815@gallagher.di.uoa.gr> <20070201132831.GH12195@neu.nirvana> Message-ID: <20070201135759.GA31947@gallagher.di.uoa.gr> On Thu, Feb 01, 2007 at 02:28:31PM +0100, Axel Thimm wrote: > > Thanks for the pointer. I didn't know its existence. One issue > > that arises now is whether a merge of > > http://fedoraproject.org/wiki/PackageUserRegistry and this file > > (/usr/share/doc/setup-*/uidgid) is to be considered. > > These are very different objects, the uidgid are fixed, absolute > uids/gids, while the wiki URL above is for the floating model of > adding uids/gids (e.g. there is some per-machine settable value that > is added). > > Personally I strongly recommend against using the floating model, > because > > a) the added base value is arbitrary > b) any change after the first install of the helper tool of this base > value will break all previous installs using this method > c) it isn't transparent to the user (admin) that some upper part of > his uid/gid space is reserved for this method, so he may be > accidentially using it. I understand that and I recall some heated exchange between proponents of different models. My impression was that this model was born because it was impossible/very difficult to fix uidgids in core for extras packages due to the division between core and extras, and that it would be preferable to maintain a fixed uidgid for all applications/programs that needed it. My impression was also that those programs listed in the wiki actually wanted/needed a fixed uidgid, but could not get one because of this difficulty. Now that there should be no distinction between core and extras, the fixed uidgid possibility should become available to former extras packages, starting from those that probably needed it most (the ones in the wiki). That was my point really. If my understanding of the situation was not correct, please accept my apologies. Thanks, -- Sarantis From Axel.Thimm at ATrpms.net Thu Feb 1 14:06:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Feb 2007 15:06:06 +0100 Subject: [Fedora-packaging] Re: User IDs in Core packages? In-Reply-To: <20070201135759.GA31947@gallagher.di.uoa.gr> References: <20070201111852.GA29690@gallagher.di.uoa.gr> <20070201120319.GC12195@neu.nirvana> <20070201131750.GA31815@gallagher.di.uoa.gr> <20070201132831.GH12195@neu.nirvana> <20070201135759.GA31947@gallagher.di.uoa.gr> Message-ID: <20070201140606.GA19948@neu.nirvana> On Thu, Feb 01, 2007 at 03:57:59PM +0200, Sarantis Paskalis wrote: > On Thu, Feb 01, 2007 at 02:28:31PM +0100, Axel Thimm wrote: > > > Thanks for the pointer. I didn't know its existence. One issue > > > that arises now is whether a merge of > > > http://fedoraproject.org/wiki/PackageUserRegistry and this file > > > (/usr/share/doc/setup-*/uidgid) is to be considered. > > > > These are very different objects, the uidgid are fixed, absolute > > uids/gids, while the wiki URL above is for the floating model of > > adding uids/gids (e.g. there is some per-machine settable value that > > is added). > > > > Personally I strongly recommend against using the floating model, > > because > > > > a) the added base value is arbitrary > > b) any change after the first install of the helper tool of this base > > value will break all previous installs using this method > > c) it isn't transparent to the user (admin) that some upper part of > > his uid/gid space is reserved for this method, so he may be > > accidentially using it. > > I understand that and I recall some heated exchange between proponents > of different models. My impression was that this model was born because > it was impossible/very difficult to fix uidgids in core for extras > packages due to the division between core and extras, I think that's not really the reason, it's just too few of them available, e.g. just < 100 and all are used up. > and that it would be preferable to maintain a fixed uidgid for all > applications/programs that needed it. My impression was also that > those programs listed in the wiki actually wanted/needed a fixed > uidgid, but could not get one because of this difficulty. > > Now that there should be no distinction between core and extras, the > fixed uidgid possibility should become available to former extras > packages, starting from those that probably needed it most (the ones in > the wiki). Indeed, but there are none left. > That was my point really. If my understanding of the situation was not > correct, please accept my apologies. There are not enough fixed uids/gids left for merging in the floating uids/gids. What really needs to be done is to reserve 100-500 to the system uid/gid space, something not really possibly anymore for F7. E.g. any reshuffling of uids/gids will happen post-F7 if at all, but the good news is that the Core packages are already on the safe side since they used the fixed area, so this is not blocking the merger in any way. Perhaps the new statistics gathering system should check for how many systems have non-system users below 500. Hopefully very close to zero. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fnasser at redhat.com Thu Feb 1 14:50:28 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 01 Feb 2007 09:50:28 -0500 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <200702010948.10362.ville.skytta@iki.fi> References: <1170189972.31747.32.camel@localhost.localdomain> <200702010948.10362.ville.skytta@iki.fi> Message-ID: <45C1FE34.90904@redhat.com> Ville Skytt? wrote: > On Tuesday 30 January 2007 22:46, Tom 'spot' Callaway wrote: > >> http://fedoraproject.org/wiki/PackagingDrafts/ExceptionJPackage > > "According to Fernando Nasser, JPackage RPMS only use integers in the Release: > field, in the format Xjpp. If this is the case, then the following format > will ensure clean upgrades from Fedora to JPackage and so forth: [...]" > > JPackage's pre-release Release: tags are not Xjpp only. Was this considered > in the draft? Some random examples: > > classpathx-jaxp-1.0-0.beta1.10jpp > cpptasks-1.0-0.b4.1jpp > cryptix-asn1-0.1.12-0.cvs20011119.7jpp > activemq3-3.2.5-0.r1125.2jpp > radeox-0.9-0.beta.2jpp > > More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/ > These are old style tags, before Nicolas brought up the possible problems with upgrade paths. There is a guideline proposal on the list currently, so people choose between two (Fedora-like) numbering schemes. You've been away for too long ;-) From tcallawa at redhat.com Thu Feb 1 21:08:56 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 01 Feb 2007 15:08:56 -0600 Subject: [Fedora-packaging] Re: Exception for JPackage In-Reply-To: <1170321695.2588.152.camel@mccallum.corsepiu.local> References: <1170189972.31747.32.camel@localhost.localdomain> <1170204009.2961.15.camel@localhost.localdomain> <1170207030.18675.219.camel@localhost.localdomain> <1170259947.2961.38.camel@localhost.localdomain> <1170264447.5838.508.camel@mccallum.corsepiu.local> <1170290273.5838.533.camel@mccallum.corsepiu.local> <20070201063022.GA7169@neu.nirvana> <1170315578.2588.99.camel@mccallum.corsepiu.local> <20070201074838.GE7169@neu.nirvana> <1170321695.2588.152.camel@mccallum.corsepiu.local> Message-ID: <1170364136.16199.11.camel@localhost.localdomain> On Thu, 2007-02-01 at 10:21 +0100, Ralf Corsepius wrote: > Wrt. voting, I am undecided, because, to me, the proposal boils down to > deciding between two "mediocre compromises": > > a) Accepting it would mean catering a pragmatical compromise, which > isn't necessarily in the Fedora community's long-term interests and > which might weaken OpenSource in longer terms. > > b) Rejecting it would mean insisting on a position that isn't > necessarily in RH's nor Fedora's interest wrt. java, technically is > hardly resolvable, but would help the "wider community" (3rd parties). > > I would have voted +1 if I'd sense this proposal to be a short-term > compromise and precedence aiming at systematic integration of 3rd > parties. Spot's comment lets me think this doesn't apply. I am treating this very much as a compromise with limited scope aiming at assisting in the integration and compatibility with 3rd party repositories. However, in order to limit the scope, it is currently only valid for JPackage. If another repo comes forward which would wish to leverage the same guideline set, I'm more than willing to amend it for them. ~spot From ville.skytta at iki.fi Thu Feb 1 21:30:10 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 1 Feb 2007 23:30:10 +0200 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <45C1FE34.90904@redhat.com> References: <1170189972.31747.32.camel@localhost.localdomain> <200702010948.10362.ville.skytta@iki.fi> <45C1FE34.90904@redhat.com> Message-ID: <200702012330.11045.ville.skytta@iki.fi> On Thursday 01 February 2007 16:50, Fernando Nasser wrote: > Ville Skytt? wrote: > > > JPackage's pre-release Release: tags are not Xjpp only. Was this > > considered in the draft? Some random examples: > > > > classpathx-jaxp-1.0-0.beta1.10jpp > > cpptasks-1.0-0.b4.1jpp > > cryptix-asn1-0.1.12-0.cvs20011119.7jpp > > activemq3-3.2.5-0.r1125.2jpp > > radeox-0.9-0.beta.2jpp > > > > More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/ > > These are old style tags, before Nicolas brought up the possible > problems with upgrade paths. My point wasn't about whether they're 0.foo.Xjpp or 0.1.foo.Xjpp, but that the draft says: "JPackage RPMS only use integers in the Release: field, in the format Xjpp" Note: 0.foo.Xjpp is not in the Xjpp format, neither is 0.X.foo.Yjpp. For example, 1jpp and 15jpp are. The draft goes on and says "If this is the case, then ..." and discusses how to take care of stuff. I just want to make sure the discussion is not based on a false assumption. I *guess* pre-release names like that are not a problem, but haven't read the draft too thoroughly to be able to tell at the moment. Quite frankly, I'm a bit surprised about how much discussion and documentation and migration plans do three little "jpp" letters in the release tag really need... shrug, I really don't have an opinion beyond "if it works for and makes lifes of people working with JPackage considerably easier, and works for Fedora end users, no objections here". Dunno whether that's a +1 or 0, maybe the former. From tcallawa at redhat.com Sun Feb 4 16:20:56 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 04 Feb 2007 10:20:56 -0600 Subject: [Fedora-packaging] Draft: Perl packages don't need -devel for .h headers Message-ID: <1170606056.9171.6.camel@localhost.localdomain> Since perl is special, perl packages are exempt from the requirement for -devel packages for .h header files. This has been the status quo for some time, but never explicitly stated. Take a second and vote on this please. Thanks, ~spot From Matt_Domsch at dell.com Tue Feb 6 03:58:13 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 5 Feb 2007 21:58:13 -0600 Subject: [Fedora-packaging] filing ExclusiveArch bugs when it's HW architectural Message-ID: <20070206035813.GA32250@lists.us.dell.com> Packaging Guidelines say: - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch needs to have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number should then be placed in a comment, next to the corresponding ExcludeArch line. New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number. (Extras Only) The bug should be marked as blocking one (or more) of the following bugs to simplify tracking such issues: [WWW] FE-ExcludeArch-x86, [WWW] FE-ExcludeArch-x64, [WWW] FE-ExcludeArch-ppc My question: Why file a bug when it's clearly a hardware architectural issue? e.g. the hardware arch does not provide the capability that the package uses. Seems like a waste of a bug that won't be fixed. For example, the libsmbios spec uses ExclusiveArch i386 x86_64 ia64, with a nice comment on how the tables this uses are only provided by BIOS of those architectures. ppc and sparc most likely won't ever change in this respect. So why file the bug? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From tibbs at math.uh.edu Tue Feb 6 04:29:38 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Feb 2007 22:29:38 -0600 Subject: [Fedora-packaging] Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170606056.9171.6.camel@localhost.localdomain> References: <1170606056.9171.6.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom 'spot' Callaway writes: TC> Since perl is special, perl packages are exempt from the TC> requirement for -devel packages for .h header files. I'm definitely for for this, although I wish someone who truly understands why arch-specific Perl modules need a .h file could explain it to us. For all I know it doesn't actually need to be packaged. - J< From ville.skytta at iki.fi Tue Feb 6 07:58:27 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 6 Feb 2007 09:58:27 +0200 Subject: [Fedora-packaging] Draft: Perl packages don't need -devel for .h headers In-Reply-To: References: <1170606056.9171.6.camel@localhost.localdomain> Message-ID: <200702060958.27589.ville.skytta@iki.fi> On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom 'spot' Callaway writes: > > TC> Since perl is special, perl packages are exempt from the > TC> requirement for -devel packages for .h header files. > > I'm definitely for for this, although I wish someone who truly > understands why arch-specific Perl modules need a .h file could > explain it to us. For all I know it doesn't actually need to be > packaged. They're installed for the usual reasons - something requires them, usually at build time. See for example perl-DBI and perl-DBD-MySQL; the latter needs DBI's *.h to build, ditto probably all other perl-DBD-*. Rather than blanket approval for the status quo, I think it would be better to first discuss whether -devel packages for some perl modules should be introduced instead. From Axel.Thimm at ATrpms.net Tue Feb 6 12:13:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Feb 2007 13:13:25 +0100 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <200702060958.27589.ville.skytta@iki.fi> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> Message-ID: <20070206121325.GB17490@neu.nirvana> On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skytt? wrote: > On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote: > > >>>>> "TC" == Tom 'spot' Callaway writes: > > > > TC> Since perl is special, perl packages are exempt from the > > TC> requirement for -devel packages for .h header files. > > > > I'm definitely for for this, although I wish someone who truly > > understands why arch-specific Perl modules need a .h file could > > explain it to us. For all I know it doesn't actually need to be > > packaged. > > They're installed for the usual reasons - something requires them, usually at > build time. See for example perl-DBI and perl-DBD-MySQL; the latter needs > DBI's *.h to build, ditto probably all other perl-DBD-*. > > Rather than blanket approval for the status quo, I think it would be better to > first discuss whether -devel packages for some perl modules should be > introduced instead. Does anyone know about how many perl packages we're talking about? If it's a small number I'd go with Ville and have them properly split out their *-devel. It's much cleaner that way. If it involves major surgery then we'd have to let this pass though, but I assume it will affect only a few. The packages I've seen carrying *.h files are mostly not suited becoming perl- prefixed anyway (in a monolithic package) as they are carrying more than modules. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jpo at di.uminho.pt Tue Feb 6 13:52:49 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Tue, 06 Feb 2007 13:52:49 +0000 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <20070206121325.GB17490@neu.nirvana> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> Message-ID: <45C88831.6060207@di.uminho.pt> Axel Thimm wrote: > On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skytt? wrote: >> On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote: >>>>>>>> "TC" == Tom 'spot' Callaway writes: >>> TC> Since perl is special, perl packages are exempt from the >>> TC> requirement for -devel packages for .h header files. >>> >>> I'm definitely for for this, although I wish someone who truly >>> understands why arch-specific Perl modules need a .h file could >>> explain it to us. For all I know it doesn't actually need to be >>> packaged. >> They're installed for the usual reasons - something requires them, usually at >> build time. See for example perl-DBI and perl-DBD-MySQL; the latter needs >> DBI's *.h to build, ditto probably all other perl-DBD-*. >> >> Rather than blanket approval for the status quo, I think it would be better to >> first discuss whether -devel packages for some perl modules should be >> introduced instead. > > Does anyone know about how many perl packages we're talking about? If > it's a small number I'd go with Ville and have them properly split out > their *-devel. It's much cleaner that way. If it involves major > surgery then we'd have to let this pass though, but I assume it will > affect only a few. > > The packages I've seen carrying *.h files are mostly not suited > becoming perl- prefixed anyway (in a monolithic package) as they are > carrying more than modules. Perl packages that include .h files (excluding the core perl) Core: 2 perl packages perl-DBI perl-PDL Extras: 16 perl packages perl-Cairo perl-Event perl-Glib perl-Gnome2-Canvas perl-Gnome2-GConf perl-Gnome2-Print perl-Gnome2-VFS perl-Gtk2 perl-Gtk2-GladeXML perl-Gtk2-Notify perl-Gtk2-Sexy perl-Gtk2-Spell perl-Gtk2-TrayIcon perl-Imager perl-Tk perl-Wx 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: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From tibbs at math.uh.edu Tue Feb 6 15:39:39 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Feb 2007 09:39:39 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <20070206121325.GB17490@neu.nirvana> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> If it's a small number I'd go with Ville and have them properly AT> split out their *-devel. It's much cleaner that way. That way leads in many of not most cases to a -devel file containing a single .h file, which I see as being far less clean. - J< From mclasen at redhat.com Tue Feb 6 15:48:32 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 06 Feb 2007 10:48:32 -0500 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> Message-ID: <1170776912.3324.4.camel@dhcp83-33.boston.redhat.com> On Tue, 2007-02-06 at 09:39 -0600, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> If it's a small number I'd go with Ville and have them properly > AT> split out their *-devel. It's much cleaner that way. > > That way leads in many of not most cases to a -devel file containing a > single .h file, which I see as being far less clean. > That argument did not stop single-file -devel packages for .pc files... From tibbs at math.uh.edu Tue Feb 6 15:53:53 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Feb 2007 09:53:53 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170776912.3324.4.camel@dhcp83-33.boston.redhat.com> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170776912.3324.4.camel@dhcp83-33.boston.redhat.com> Message-ID: >>>>> "MC" == Matthias Clasen writes: MC> That argument did not stop single-file -devel packages for .pc MC> files... A reasonable statement, but I will point out that the situation there involves dependencies. - J< From rdieter at math.unl.edu Tue Feb 6 16:25:47 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Feb 2007 10:25:47 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170776912.3324.4.camel@dhcp83-33.boston.redhat.com> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170776912.3324.4.camel@dhcp83-33.boston.redhat.com> Message-ID: <45C8AC0B.9090801@math.unl.edu> Matthias Clasen wrote: > That argument did not stop single-file -devel packages for .pc files.. I agree single-file -devel packages *could* be silly, examples? -- Rex From mclasen at redhat.com Tue Feb 6 16:13:32 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 06 Feb 2007 11:13:32 -0500 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <45C8AC0B.9090801@math.unl.edu> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170776912.3324.4.camel@dhcp83-33.boston.redhat.com> <45C8AC0B.9090801@math.unl.edu> Message-ID: <1170778412.3324.7.camel@dhcp83-33.boston.redhat.com> On Tue, 2007-02-06 at 10:25 -0600, Rex Dieter wrote: > Matthias Clasen wrote: > > That argument did not stop single-file -devel packages for .pc files.. > I agree single-file -devel packages *could* be silly, examples? iso-codes-devel is one, and I'm sure we have or will soon see a request to put the gnome-icon-theme .pc file in its own -devel, too. From rdieter at math.unl.edu Tue Feb 6 16:46:21 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Feb 2007 10:46:21 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170778412.3324.7.camel@dhcp83-33.boston.redhat.com> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170776912.3324.4.camel@dhcp83-33.boston.redhat.com> <45C8AC0B.9090801@math.unl.edu> <1170778412.3324.7.camel@dhcp83-33.boston.redhat.com> Message-ID: <45C8B0DD.60303@math.unl.edu> Matthias Clasen wrote: > On Tue, 2007-02-06 at 10:25 -0600, Rex Dieter wrote: > >> Matthias Clasen wrote: >> >>> That argument did not stop single-file -devel packages for .pc files.. >>> >> I agree single-file -devel packages *could* be silly, examples? >> > iso-codes-devel is one, and I'm sure we have or will soon see a request > to put the gnome-icon-theme .pc file in its own -devel, too. > The relevant section of the guidelines for this is: - *SHOULD*: The placement of pkgconfig(.pc) files depends on their use case, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. -- Rex From tcallawa at redhat.com Tue Feb 6 18:51:51 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Feb 2007 12:51:51 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <20070206121325.GB17490@neu.nirvana> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> Message-ID: <1170787911.12347.5.camel@localhost.localdomain> On Tue, 2007-02-06 at 13:13 +0100, Axel Thimm wrote: > On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skytt? wrote: > > On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote: > > > >>>>> "TC" == Tom 'spot' Callaway writes: > > > > > > TC> Since perl is special, perl packages are exempt from the > > > TC> requirement for -devel packages for .h header files. > > > > > > I'm definitely for for this, although I wish someone who truly > > > understands why arch-specific Perl modules need a .h file could > > > explain it to us. For all I know it doesn't actually need to be > > > packaged. > > > > They're installed for the usual reasons - something requires them, usually at > > build time. See for example perl-DBI and perl-DBD-MySQL; the latter needs > > DBI's *.h to build, ditto probably all other perl-DBD-*. > > > > Rather than blanket approval for the status quo, I think it would be better to > > first discuss whether -devel packages for some perl modules should be > > introduced instead. > > Does anyone know about how many perl packages we're talking about? If > it's a small number I'd go with Ville and have them properly split out > their *-devel. It's much cleaner that way. If it involves major > surgery then we'd have to let this pass though, but I assume it will > affect only a few. > > The packages I've seen carrying *.h files are mostly not suited > becoming perl- prefixed anyway (in a monolithic package) as they are > carrying more than modules. Well, here's a big one: perl. Perl has a healthy number of .h files: /usr/lib/perl5/5.8.8/Encode/encode.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/EXTERN.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/INTERN.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/XSUB.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/av.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/cc_runtime.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/config.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/cop.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/cv.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/dosish.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/embed.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/embedvar.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/fakesdio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/fakethr.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/form.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/gv.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/handy.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/hv.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/intrpvar.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/iperlsys.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/keywords.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/malloc_ctl.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/mg.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/nostdio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/op.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/opcode.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/opnames.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/pad.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/patchlevel.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perl.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlapi.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perliol.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlsdio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlsfio.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perlvars.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perly.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/pp.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/pp_proto.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/proto.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/reentr.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/regcomp.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/regexp.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/regnodes.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/scope.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/sv.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/thrdvar.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/thread.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/uconfig.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/unixish.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/utf8.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/utfebcdic.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/util.h /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/warnings.h My concern is that if we make a perl-devel here, some things that had perl as an unstated BuildRequires will suddenly stop building until they add perl-devel. Not fatal, but rather intrusive. Thoughts? ~spot From jkeating at redhat.com Tue Feb 6 18:57:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 13:57:44 -0500 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170787911.12347.5.camel@localhost.localdomain> References: <1170606056.9171.6.camel@localhost.localdomain> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> Message-ID: <200702061357.44296.jkeating@redhat.com> On Tuesday 06 February 2007 13:51, Tom 'spot' Callaway wrote: > Not fatal, but rather intrusive. Thoughts? Now (development cycle, still fairly early on) is the time to make such changes, if they were to be made. Doing so after Test2 is probably not desireable. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Feb 6 19:16:58 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Feb 2007 13:16:58 -0600 Subject: [Fedora-packaging] Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170606056.9171.6.camel@localhost.localdomain> References: <1170606056.9171.6.camel@localhost.localdomain> Message-ID: <45C8D42A.2070604@math.unl.edu> Tom 'spot' Callaway wrote: > Since perl is special, perl packages are exempt from the requirement for > -devel packages for .h header files. > > This has been the status quo for some time, but never explicitly stated. > Take a second and vote on this please I'm ok with it, +1 -- Rex From tibbs at math.uh.edu Tue Feb 6 19:18:18 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Feb 2007 13:18:18 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170787911.12347.5.camel@localhost.localdomain> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom 'spot' Callaway writes: TC> My concern is that if we make a perl-devel here, some things that TC> had perl as an unstated BuildRequires will suddenly stop building TC> until they add perl-devel. If so, this needs to happen rather soon. Can we get buy-in from Robin and perhaps a couple of mass-packagers like Steve Pritchard? - J< From rdieter at math.unl.edu Tue Feb 6 19:47:01 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Feb 2007 13:47:01 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> Message-ID: <45C8DB35.4060704@math.unl.edu> Jason L Tibbitts III wrote: >>>>>> "TC" == Tom 'spot' Callaway writes: >>>>>> > > TC> My concern is that if we make a perl-devel here, some things that > TC> had perl as an unstated BuildRequires will suddenly stop building > TC> until they add perl-devel. > > If so, this needs to happen rather soon. Can we get buy-in from Robin > and perhaps a couple of mass-packagers like Steve Pritchard? > Imo, lobbying for buy-in is premature. There isn't even consensus (here anyway) that this (perl -devel pkgs) is even a good idea worth pursuing (and if you ask me, it isn't). -- Rex From Axel.Thimm at ATrpms.net Tue Feb 6 19:31:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Feb 2007 20:31:40 +0100 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170787911.12347.5.camel@localhost.localdomain> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> Message-ID: <20070206193140.GA29087@neu.nirvana> On Tue, Feb 06, 2007 at 12:51:51PM -0600, Tom 'spot' Callaway wrote: > On Tue, 2007-02-06 at 13:13 +0100, Axel Thimm wrote: > > On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skytt? wrote: > > > On Tuesday 06 February 2007 06:29, Jason L Tibbitts III wrote: > > > > >>>>> "TC" == Tom 'spot' Callaway writes: > > > > > > > > TC> Since perl is special, perl packages are exempt from the > > > > TC> requirement for -devel packages for .h header files. > > > Rather than blanket approval for the status quo, I think it > > > would be better to first discuss whether -devel packages for > > > some perl modules should be introduced instead. > > > > Does anyone know about how many perl packages we're talking about? > > If it's a small number I'd go with Ville and have them properly > > split out their *-devel. It's much cleaner that way. If it > > involves major surgery then we'd have to let this pass though, but > > I assume it will affect only a few. > > > > The packages I've seen carrying *.h files are mostly not suited > > becoming perl- prefixed anyway (in a monolithic package) as they > > are carrying more than modules. > > Well, here's a big one: > > perl. That hardly counts as a perl module package otherwise it would ahd been named perl-perl ;) > My concern is that if we make a perl-devel here, some things that > had perl as an unstated BuildRequires will suddenly stop building > until they add perl-devel. > > Not fatal, but rather intrusive. Thoughts? I would separate discussion of the perl package and the rest. But even if perl itself were to be split in perl and perl-devel, Matt's mass rebuilds would let the packages surface that need a change from BR: perl to BR: perl-devel. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Tue Feb 6 19:35:51 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Feb 2007 13:35:51 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <20070206193140.GA29087@neu.nirvana> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> <20070206193140.GA29087@neu.nirvana> Message-ID: <1170790551.12347.11.camel@localhost.localdomain> On Tue, 2007-02-06 at 20:31 +0100, Axel Thimm wrote: > > Well, here's a big one: > > > > perl. > > That hardly counts as a perl module package otherwise it would ahd > been named perl-perl ;) Well, it is a perl module package, it has several perl modules inside of it. The main module in this case is called "CORE", but there is also a .h file in the Encode module (also inside perl). > > My concern is that if we make a perl-devel here, some things that > > had perl as an unstated BuildRequires will suddenly stop building > > until they add perl-devel. > > > > Not fatal, but rather intrusive. Thoughts? > > I would separate discussion of the perl package and the rest. But even > if perl itself were to be split in perl and perl-devel, Matt's mass > rebuilds would let the packages surface that need a change from BR: > perl to BR: perl-devel. Well, I'm trying to review the core perl package, and part of that has been a near total spec rewrite. I need to know whether I should add a perl-devel or not. ~spot From tibbs at math.uh.edu Tue Feb 6 19:37:54 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Feb 2007 13:37:54 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <45C8DB35.4060704@math.unl.edu> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> <45C8DB35.4060704@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> Imo, lobbying for buy-in is premature. We should at least ask the people doing the bulk of the Perl work if they think this is reasonable, shouldn't we? - J< From rdieter at math.unl.edu Tue Feb 6 20:02:31 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 Feb 2007 14:02:31 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> <45C8DB35.4060704@math.unl.edu> Message-ID: <45C8DED7.8040200@math.unl.edu> Jason L Tibbitts III wrote: >>>>>> "RD" == Rex Dieter writes: >>>>>> RD> Imo, lobbying for buy-in is premature. >>>>>> >>>>>> We should at least ask the people doing the bulk of the Perl work if >>>>>> they think this is reasonable, shouldn't we? >>>>>> Sure, go ahead, couldn't hurt. -- Rex From tcallawa at redhat.com Tue Feb 6 19:45:49 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Feb 2007 13:45:49 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <45C8DED7.8040200@math.unl.edu> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> <45C8DB35.4060704@math.unl.edu> <45C8DED7.8040200@math.unl.edu> Message-ID: <1170791149.19237.0.camel@localhost.localdomain> On Tue, 2007-02-06 at 14:02 -0600, Rex Dieter wrote: > Jason L Tibbitts III wrote: > >>>>>> "RD" == Rex Dieter writes: > >>>>>> RD> Imo, lobbying for buy-in is premature. > >>>>>> > >>>>>> We should at least ask the people doing the bulk of the Perl work if > >>>>>> they think this is reasonable, shouldn't we? > >>>>>> > Sure, go ahead, couldn't hurt. Indeed, but Robin is letting me rewrite the perl spec file at the moment. :) ~spot From ville.skytta at iki.fi Tue Feb 6 20:34:38 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 6 Feb 2007 22:34:38 +0200 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <20070206121325.GB17490@neu.nirvana> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> Message-ID: <200702062234.38437.ville.skytta@iki.fi> On Tuesday 06 February 2007 14:13, Axel Thimm wrote: > On Tue, Feb 06, 2007 at 09:58:27AM +0200, Ville Skytt? wrote: > > > > Rather than blanket approval for the status quo, I think it would be > > better to first discuss whether -devel packages for some perl modules > > should be introduced instead. > > Does anyone know about how many perl packages we're talking about? If > it's a small number I'd go with Ville and have them properly split out > their *-devel. Just for the record, I don't have a real opinion yet, so you won't know where you'll end up if you decide to go with me at this point :). All I suggested above was discussion about it (which we now have, good). From Axel.Thimm at ATrpms.net Tue Feb 6 20:54:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Feb 2007 21:54:36 +0100 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170790551.12347.11.camel@localhost.localdomain> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> <20070206193140.GA29087@neu.nirvana> <1170790551.12347.11.camel@localhost.localdomain> Message-ID: <20070206205436.GA31898@neu.nirvana> On Tue, Feb 06, 2007 at 01:35:51PM -0600, Tom 'spot' Callaway wrote: > Well, I'm trying to review the core perl package, and part of that has > been a near total spec rewrite. I need to know whether I should add a > perl-devel or not. If there is a mass rebuild (e.g. by Matt's buildsystem) before test2 it could be used to check whether that split really harms anything. But I think perhaps that's us being to pedantic in this case, and we could revisit it after F7. But it wouldn't hurt to add a forward compatible Provides: perl-devel = %{epoch}:%{version}-%{release} That way any current package that should depend on perl-devel instead of or in addition to perl would have a transition time to fix the BRs. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Tue Feb 6 20:49:42 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 6 Feb 2007 22:49:42 +0200 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170790551.12347.11.camel@localhost.localdomain> References: <1170606056.9171.6.camel@localhost.localdomain> <20070206193140.GA29087@neu.nirvana> <1170790551.12347.11.camel@localhost.localdomain> Message-ID: <200702062249.42543.ville.skytta@iki.fi> On Tuesday 06 February 2007 21:35, Tom 'spot' Callaway wrote: > > Well, I'm trying to review the core perl package, and part of that has > been a near total spec rewrite. I need to know whether I should add a > perl-devel or not. I still haven't formed an opinion, but here's some numbers from i386 FC6: $ du -hc `rpm -ql perl` | tail -n 1 237M total $ du -hc `rpm -ql perl | grep '\.h$'` | tail -n 1 1.6M total Not that significant. Also, I haven't checked but would guess that *.h don't inflict any extra dependencies. There's also a bunch of *.ph files which I gather are _mostly_ for development purposes but some modules do pull some of them in at runtime (eg. Net::Domain, Sys::Hostname) so I suppose it's safer to leave at least *.ph alone unless someone knows better. From tcallawa at redhat.com Tue Feb 6 21:21:46 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Feb 2007 15:21:46 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <20070206205436.GA31898@neu.nirvana> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> <20070206193140.GA29087@neu.nirvana> <1170790551.12347.11.camel@localhost.localdomain> <20070206205436.GA31898@neu.nirvana> Message-ID: <1170796906.19237.4.camel@localhost.localdomain> On Tue, 2007-02-06 at 21:54 +0100, Axel Thimm wrote: > On Tue, Feb 06, 2007 at 01:35:51PM -0600, Tom 'spot' Callaway wrote: > > Well, I'm trying to review the core perl package, and part of that has > > been a near total spec rewrite. I need to know whether I should add a > > perl-devel or not. > > If there is a mass rebuild (e.g. by Matt's buildsystem) before test2 > it could be used to check whether that split really harms > anything. But I think perhaps that's us being to pedantic in this > case, and we could revisit it after F7. OK, being pedantic: - I can't make perl pass review unless I make a perl-devel OR - Perl needs an exception in the guidelines so it can pass review. Which one would people prefer for FC-7? At this point, I'm rather indifferent. :) ~spot From mclasen at redhat.com Thu Feb 8 03:18:19 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 07 Feb 2007 22:18:19 -0500 Subject: [Fedora-packaging] some comments on the desktop files section and proposed amendmends Message-ID: <45CA967B.7040807@redhat.com> > If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes > of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that > window. This is just not right. xeyes draws an X window - do you want a desktop file for it ?! xev draws an X window, too. nautilus is certainly a GUI application - do you want to see it in the menus ? On the other hand, I can easily imagine non-GUI applications that may deserve a place on the menus. IMO this whole sentence should be nuked and replaced by something like: If a package contains an application that users would expect to find in the panel menus, it needs to include a properly installed .desktop file. > Installed .desktop files MUST follow the [[WWW] desktop-entry-spec ], paying particular attention to validating correct usage > of Name, GenericName , [[WWW] Categories ], [[WWW] StartupNotify ] entries. A number of comments on this: 1) The desktop-entry-spec doesn't acutally define correct usage of Name and GenericName, all it does is giving a single example of how you could use these fields. 2) While I can see where this is coming from, and may even sympathize with a "correct usage" of Name and GenericName, simply decreeing that it has to be so is not going to make it happen. Packagers really cannot do anything to enforce "correct usage", because doing so would require them to speak all the 40+ languages in which these locale strings are typically translated. Finally, I think it would be beneficial to mention nimetypes and update-desktop-database in this section. From tcallawa at redhat.com Thu Feb 8 03:34:52 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 07 Feb 2007 21:34:52 -0600 Subject: [Fedora-packaging] some comments on the desktop files section and proposed amendmends In-Reply-To: <45CA967B.7040807@redhat.com> References: <45CA967B.7040807@redhat.com> Message-ID: <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> On Wed, 2007-02-07 at 22:18 -0500, Matthias Clasen wrote: > > If a package contains a GUI application, then it needs to also > include a properly installed .desktop file. For the purposes > > of these guidelines, a GUI application is defined as any application > which draws an X window and runs from within that > > window. > > This is just not right. xeyes draws an X window - do you want a desktop > file for it ?! xev draws an X window, too. > nautilus is certainly a GUI application - do you want to see it in the > menus ? On the other hand, I can easily imagine > non-GUI applications that may deserve a place on the menus. Take a deep breath. Use your brain. Use your best judgement. :) A child might want to run xeyes from the menu. A developer may want to launch xev from the menu. There probably isn't anyone who would want to launch nautilus from a menu. The guidelines don't say that only GUI apps get menu entries. If you have a non-GUI app that merits a menu entry, you're certainly permitted to add it. And if you think you have an exception, rather than being outraged, merely point out that you think you have a corner case. A good percentage of the time: you're right, and its ok. Of course, in your specific examples, I disagree with you on 2/3. :) > IMO this whole sentence should be nuked and replaced by something like: > > If a package contains an application that users would expect to find in > the panel menus, it needs to include a properly > installed .desktop file. Ah yes. The psychic ability to read the user's mind. IMHO, it is far simpler, and more broadly correct as we have it. It also involves less assumptions on the part of the packager as to what the user wants/needs/expects. > > Installed .desktop files MUST follow the [[WWW] desktop-entry-spec > ], > paying particular attention to validating correct usage > > of Name, GenericName , > [[WWW] Categories > ], [[WWW] > StartupNotify > ] entries. > > A number of comments on this: > > 1) The desktop-entry-spec doesn't acutally define correct usage of Name > and GenericName, all it does is giving a single > example of how you could use these fields. Fair enough. This is our attempt to follow upstream specifications, if the desktop-entry-spec needs some love, perhaps it should be taken up with the spec authors? We could always provide some more correct examples in our desktop guidelines. > 2) While I can see where this is coming from, and may even sympathize > with a "correct usage" of Name and GenericName, > simply decreeing that it has to be so is not going to make it happen. > Packagers really cannot do anything to enforce > "correct usage", because doing so would require them to speak all the > 40+ languages in which these locale strings are > typically translated. Hmm. While translations are certainly a concern, are the desktop files really static and eternally unchanging documents? > Finally, I think it would be beneficial to mention nimetypes and > update-desktop-database in this section. Seems reasonable, do you have a draft for specific changes? Thanks, ~spot From mclasen at redhat.com Thu Feb 8 04:11:11 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 07 Feb 2007 23:11:11 -0500 Subject: [Fedora-packaging] some comments on the desktop files section and proposed amendmends In-Reply-To: <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> References: <45CA967B.7040807@redhat.com> <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> Message-ID: <45CAA2DF.6030502@redhat.com> Tom 'spot' Callaway wrote: > Take a deep breath. Use your brain. Use your best judgement. :) > > Sure, I do that. And _I_ understand that the packaging guidelines are just guidelines. But a considerable number of reviewers will take a sentence that says "any package that installs a GUI application needs to install a desktop file" literally and block the review on the "violation". I wished the guidelines were less apodictic when there is real room for judgement. >> IMO this whole sentence should be nuked and replaced by something like: >> >> If a package contains an application that users would expect to find in >> the panel menus, it needs to include a properly >> installed .desktop file. >> > > Ah yes. The psychic ability to read the user's mind. IMHO, it is far > simpler, and more broadly correct as we have it. It also involves less > assumptions on the part of the packager as to what the user > wants/needs/expects. > This is not about reading the users mind, this is about clarifying the purpose of the desktop file (making the application appear in the menu). >> 2) While I can see where this is coming from, and may even sympathize >> with a "correct usage" of Name and GenericName, >> simply decreeing that it has to be so is not going to make it happen. >> Packagers really cannot do anything to enforce >> "correct usage", because doing so would require them to speak all the >> 40+ languages in which these locale strings are >> typically translated. >> > > Hmm. While translations are certainly a concern, are the desktop files > really static and eternally unchanging documents? > Desktop files can be changed, but since this involves translations, these changes need to happen upstream. There is not much point in adding further frustration to reviews by adding "must " items to the checklist over which the packager doesn't have any control. Also, the approach of --copy-generic-name-to-name was not just picked to annoy you, but to implement a certain user experience. If we just declare copying generic names illegal without implementing an alternative way to get the desired user experience, we will be thrown back to the days of menus full of undecipherable program names. >> Finally, I think it would be beneficial to mention nimetypes and >> update-desktop-database in this section. >> > > Seems reasonable, do you have a draft for specific changes? > > "If a desktop file contains a Mimetype field, you must call update-desktop-database in %post and %postun. See [...] for details." From opensource at till.name Thu Feb 8 09:18:51 2007 From: opensource at till.name (Till Maas) Date: Thu, 08 Feb 2007 10:18:51 +0100 Subject: [Fedora-packaging] some comments on the desktop files section and proposed amendmends In-Reply-To: <45CAA2DF.6030502@redhat.com> References: <45CA967B.7040807@redhat.com> <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> <45CAA2DF.6030502@redhat.com> Message-ID: <200702081019.00157.opensource@till.name> On Thursday 08 February 2007 05:11, Matthias Clasen wrote: > Sure, I do that. And _I_ understand that the packaging guidelines are > just guidelines. > But a considerable number of reviewers will take a sentence that says > "any package > that installs a GUI application needs to install a desktop file" > literally and block the > review on the "violation". I wished the guidelines were less apodictic > when there is > real room for judgement. Maybe it is because these reviewers do not really know where, which guidelines can be violated safely. It this case it may help to gather these rules in a BestPractices document. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at fedoraproject.org Thu Feb 8 14:23:44 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Thu, 08 Feb 2007 08:23:44 -0600 Subject: [Fedora-packaging] Re: some comments on the desktop files section and proposed amendmends References: <45CA967B.7040807@redhat.com> <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> <45CAA2DF.6030502@redhat.com> Message-ID: Matthias Clasen wrote: > Tom 'spot' Callaway wrote: >> Seems reasonable, do you have a draft for specific changes? >> >> > "If a desktop file contains a Mimetype field, you must call > update-desktop-database > in %post and %postun. See [...] for details." That's already included in the guidelines, http://fedoraproject.org/wiki/Packaging/ScriptletSnippets though it could/should be cross referenced for easier finding. -- Rex From mclasen at redhat.com Thu Feb 8 14:39:58 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 08 Feb 2007 09:39:58 -0500 Subject: [Fedora-packaging] Re: some comments on the desktop files section and proposed amendmends In-Reply-To: References: <45CA967B.7040807@redhat.com> <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> <45CAA2DF.6030502@redhat.com> Message-ID: <45CB363E.2010703@redhat.com> Rex Dieter wrote: > > That's already included in the guidelines, > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets > though it could/should be cross referenced for easier finding. > Exactly. Thats what i tried to hint at with my "See [...]" From rdieter at fedoraproject.org Thu Feb 8 15:16:21 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Thu, 08 Feb 2007 09:16:21 -0600 Subject: [Fedora-packaging] Re: Re: some comments on the desktop files section and proposed amendmends References: <45CA967B.7040807@redhat.com> <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> <45CAA2DF.6030502@redhat.com> <45CB363E.2010703@redhat.com> Message-ID: Matthias Clasen wrote: > Rex Dieter wrote: >> >> That's already included in the guidelines, >> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets >> though it could/should be cross referenced for easier finding. >> > > Exactly. Thats what i tried to hint at with my "See [...]" Agreed, though I'd argue not to add the implementation details, but only provide the cross-reference link. -- Rex From rdieter at fedoraproject.org Thu Feb 8 16:22:57 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Thu, 08 Feb 2007 10:22:57 -0600 Subject: [Fedora-packaging] Re: Re: some comments on the desktop files section and proposed amendmends References: <45CA967B.7040807@redhat.com> <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> <45CAA2DF.6030502@redhat.com> <45CB363E.2010703@redhat.com> Message-ID: Rex Dieter wrote: > Matthias Clasen wrote: > >> Rex Dieter wrote: >>> >>> That's already included in the guidelines, >>> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets >>> though it could/should be cross referenced for easier finding. >>> >> >> Exactly. Thats what i tried to hint at with my "See [...]" > > Agreed, though I'd argue not to add the implementation details, but only > provide the cross-reference link. PC folks: I don't consider simply adding navigation/cross-reference links to be something worth making a separate proposal/vote for. Can we "just do it"? -- Rex From jkeating at redhat.com Thu Feb 8 16:34:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 11:34:17 -0500 Subject: [Fedora-packaging] Re: Re: some comments on the desktop files section and proposed amendmends In-Reply-To: References: <45CA967B.7040807@redhat.com> Message-ID: <200702081134.17331.jkeating@redhat.com> On Thursday 08 February 2007 11:22, Rex Dieter wrote: > PC folks: I don't consider simply adding navigation/cross-reference links > to be something worth making a separate proposal/vote for. ?Can we "just do > it"? Just do it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Thu Feb 8 16:38:51 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Feb 2007 10:38:51 -0600 Subject: [Fedora-packaging] Re: Re: some comments on the desktop files section and proposed amendmends In-Reply-To: References: <45CA967B.7040807@redhat.com> <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> <45CAA2DF.6030502@redhat.com> <45CB363E.2010703@redhat.com> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> Can we "just do it"? For the love of all that is good, please save us more discussion and just do it. - J< From a.badger at gmail.com Thu Feb 8 16:39:25 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Feb 2007 08:39:25 -0800 Subject: [Fedora-packaging] Re: Re: some comments on the desktop files section and proposed amendmends In-Reply-To: References: <45CA967B.7040807@redhat.com> <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> <45CAA2DF.6030502@redhat.com> <45CB363E.2010703@redhat.com> Message-ID: <1170952765.4306.135.camel@localhost.localdomain> On Thu, 2007-02-08 at 10:22 -0600, Rex Dieter wrote: > Rex Dieter wrote: > > > Matthias Clasen wrote: > > > >> Rex Dieter wrote: > >>> > >>> That's already included in the guidelines, > >>> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets > >>> though it could/should be cross referenced for easier finding. > >>> > >> > >> Exactly. Thats what i tried to hint at with my "See [...]" > > > > Agreed, though I'd argue not to add the implementation details, but only > > provide the cross-reference link. > > PC folks: I don't consider simply adding navigation/cross-reference links to > be something worth making a separate proposal/vote for. Can we "just do > it"? +1 (for both "xref without voting" and "add an xref to desktop files policy" if voting is needed.) -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 rdieter at math.unl.edu Thu Feb 8 16:52:22 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Feb 2007 10:52:22 -0600 Subject: [Fedora-packaging] Re: Re: some comments on the desktop files section and proposed amendmends In-Reply-To: References: <45CA967B.7040807@redhat.com> <1170905692.8356.36.camel@dhcp-32-109.ord.redhat.com> <45CAA2DF.6030502@redhat.com> <45CB363E.2010703@redhat.com> Message-ID: <45CB5546.8000407@math.unl.edu> Jason L Tibbitts III wrote: >>>>>> "RD" == Rex Dieter writes: > > RD> Can we "just do it"? > > For the love of all that is good, please save us more discussion and > just do it. It shall be done (might have to wait until after FESCo meeting). -- Rex From fnasser at redhat.com Thu Feb 8 19:37:34 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 08 Feb 2007 14:37:34 -0500 Subject: [Fedora-packaging] Clarification/ammendment to the "non-numeric characters are permitted in the Version: field" clause Message-ID: <45CB7BFE.9030507@redhat.com> Hi, the Naming Guidelines has the following provision in http://fedoraproject.org/wiki/Packaging/NamingGuidelines?highlight=%28Packaging%29#head-18aa467fc6925455e44be682fd336667a17e8933 "Post-release packages: Packages released after a "final" version. This usually is due to a quick bugfix release, such as openssl-0.9.6b or gkrellm-2.1.7a. In this case, the non-numeric characters are permitted in the Version: field." Actually there is another case where the upstream version has non-numeric characters: when they have dual-license and name each of their releases with a letter to discriminate under which license that tar ball is. This is not described above. Furthermore, there may be additional complications (see below). The letters vary, but here is an example: The Saxon library has two tar balls for their 8.8 release http://prdownloads.sourceforge.net/saxon/saxonb8-8j.zip where B is the Open Source licensed one (and I believe and "A" marks the non-free one). If the version gets the letters in this order we would have: saxon-B8.7-1jpp.src.rpm That broke my scripts that separate the VR from the package name (perhaps my regexp is not good enough). What is the better way to handle this: 1) Do not mention the "B" at all, as we only release Open Source licensed software anyway. But what if the two licenses are GPL and ASL for instance? or GPL and BSD... 2) Add the letter to the name of the package (like saxon-b) and add a virtual provides for 'saxon' (Argh! I find it ugly) 3) Leave it in the version field, but not as the first character. But in that case, moving it to the end may get it mixed up with the case described in the guidelines: "Packages released after a "final" version. This usually is due to a quick bugfix release, such as openssl-0.9.6b or gkrellm-2.1.7a" 4) Leave it in the version field in the position where it was upstream (and Fernando has to improve his regexps, *if* he is the only one affected and not mock for instance). Any ideas, suggestions, comments? Regards to all, Fernando From tcallawa at redhat.com Thu Feb 8 19:47:43 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 08 Feb 2007 13:47:43 -0600 Subject: [Fedora-packaging] Clarification/ammendment to the "non-numeric characters are permitted in the Version: field" clause In-Reply-To: <45CB7BFE.9030507@redhat.com> References: <45CB7BFE.9030507@redhat.com> Message-ID: <1170964064.8356.48.camel@dhcp-32-109.ord.redhat.com> On Thu, 2007-02-08 at 14:37 -0500, Fernando Nasser wrote: > What is the better way to handle this: > > 1) Do not mention the "B" at all, as we only release Open Source > licensed software anyway. But what if the two licenses are GPL and ASL > for instance? or GPL and BSD... I vote for this. I think it is rather unlikely that we'd have a GPL vs ASL or GPL vs BSD licensed software component. ~spot From tibbs at math.uh.edu Thu Feb 8 19:56:49 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Feb 2007 13:56:49 -0600 Subject: [Fedora-packaging] Clarification/ammendment to the "non-numeric characters are permitted in the Version: field" clause In-Reply-To: <1170964064.8356.48.camel@dhcp-32-109.ord.redhat.com> References: <45CB7BFE.9030507@redhat.com> <1170964064.8356.48.camel@dhcp-32-109.ord.redhat.com> Message-ID: >>>>> "TC" == Tom 'spot' Callaway writes: TC> I vote for this. I think it is rather unlikely that we'd have a TC> GPL vs ASL or GPL vs BSD licensed software component. And even if we did, the license tag would indicate the license of the package well enough. - J< From fnasser at redhat.com Thu Feb 8 20:18:50 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 08 Feb 2007 15:18:50 -0500 Subject: [Fedora-packaging] Clarification/ammendment to the "non-numeric characters are permitted in the Version: field" clause In-Reply-To: References: <45CB7BFE.9030507@redhat.com> <1170964064.8356.48.camel@dhcp-32-109.ord.redhat.com> Message-ID: <45CB85AA.3040100@redhat.com> Jason L Tibbitts III wrote: >>>>>> "TC" == Tom 'spot' Callaway writes: > > TC> I vote for this. I think it is rather unlikely that we'd have a > TC> GPL vs ASL or GPL vs BSD licensed software component. > Such beasts do exist (Apache forced some folks to dual-license with the ASL their GPL'ed code in order to do collaborative development). But I agree it is unlikely (BTW, that story did not have a very happy ending). > And even if we did, the license tag would indicate the license of the > package well enough. > Right. Ad if we ever have to release more than one, we will need different package names anyway, like apache-joram and objectweb-joran, each with its proper License:. So I vote for (1) as well: +1 From overholt at redhat.com Thu Feb 8 21:09:57 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 8 Feb 2007 16:09:57 -0500 Subject: [Fedora-packaging] plugin naming In-Reply-To: <200701301840.58082.opensource@till.name> References: <200701301840.58082.opensource@till.name> Message-ID: <20070208210956.GD30690@redhat.com> * Till Maas [2007-01-30 12:41]: > > Here are some examples of current plugin names: For eclipse plugins/features we've been sticking to: eclipse- Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Feb 9 02:29:30 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Feb 2007 18:29:30 -0800 Subject: [Fedora-packaging] [Proposal] Spec file name revision Message-ID: <1170988170.4306.218.camel@localhost.localdomain> Here's a proposed policy change for spec file name matching the package name. Basically, it allows us to grandfather in specs from Core that use the %{name}%{MajorVer}.spec format until A) the spec can be renamed and keep its revision controlled history or B) the spec would have been renamed due to MajorVer upgrades in the package. = Spec File Naming = Draft: 0.1 This text will appear on: http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines and be linked from: http://www.fedoraproject.org/wiki/Packaging/ReviewGuidelines It was discussed in this review bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225778 == Rationale == The name of a spec file currently has to match the name of the generated package. This is for two reasons: 1. Preserve history of changes to a spec file in the revision control system. 2. Make it easy for someone extracting an rpm to know what spec filename they need to look for. During the Core merge, some packages which are presently using the %{name}%{version}.spec format will lose history if forced to change. This change provides a temporary exception for those packages. == Text of Change == The spec file should be named using the %{name}.spec scheme. This is to make it easier for people to find the appropriate spec when they install a src.rpm. Example: {{{ If your package is named foo-1.0.0-1.src.rpm, then the spec file should be named foo.spec. }}} There is normally no need to include the %{version} in the spec file name. If you are packaging multiple versions of a package for simultaneous use, they should already reflect the version in the %{name}.spec scheme (refer to Multiple Packages with the same base name for details). In normal cases adding the version can cause the spec file's history to be lost when a package's version is upgraded. As a special exception, there are a few packages which are allowed to have a version in their spec filename. This is because they had the version in their name when they were merged from Fedora Core's cvs and removing the version at that time would *lose* history: * gcc * [Please ask the packaging committee to add your package if you think it should also fall under this exception.] This exception will go away when any of the following criteria are met: 1. We move the packages to a revision control system which is able to preserve history across a file rename. 1. The package spec file is going to be renamed anyway (for example, gcc41.spec is imported into cvs. When gcc is upgraded to gcc-4.2, the new spec will be created as gcc.spec '''not''' gcc42.spec) -------------- 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 fnasser at redhat.com Fri Feb 9 02:45:14 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 08 Feb 2007 21:45:14 -0500 Subject: [Fedora-packaging] Re: Development/Libraries/Java Group? In-Reply-To: <1153773865.7268.145.camel@localhost.localdomain> References: <1153154379.2666.24.camel@localhost.localdomain> <44BFD4F2.10002@redhat.com> <1153773865.7268.145.camel@localhost.localdomain> Message-ID: <45CBE03A.6050104@redhat.com> Anyone knows what was the resolution of this? Is Development/Libraries/Java OK or not? Regards, Fernando Anthony Green wrote: > On Thu, 2006-07-20 at 18:24 -0500, Jason L Tibbitts III wrote: >> Back to reality, it seems to me to be imminently reasonable that Java >> should have its own package group because there are a quantity of >> packages associated with it, but to argue that Java alone deserves >> such treatment while other languages in the same situation don't >> because they're not "subsystems" seems, well, odd. > > I agree. I think we should allow for Development/Libraries/[LANGUAGE] > because... > > - Groups are used to make browsing packages simpler > - People browsing Development/Libraries are programmers > - Programmers are typically looking for language specific libraries > > So, my proposal it to let packagers extend Development/Libraries with > a /[LANGUAGE] (Perl, Python, Java, C++, Lisp, etc, but not C, which can > default to Development/Libraries). > > AG > From tcallawa at redhat.com Fri Feb 9 02:50:41 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 08 Feb 2007 20:50:41 -0600 Subject: [Fedora-packaging] Re: Development/Libraries/Java Group? In-Reply-To: <45CBE03A.6050104@redhat.com> References: <1153154379.2666.24.camel@localhost.localdomain> <44BFD4F2.10002@redhat.com> <1153773865.7268.145.camel@localhost.localdomain> <45CBE03A.6050104@redhat.com> Message-ID: <1170989441.1479.0.camel@dhcp-32-109.ord.redhat.com> On Thu, 2007-02-08 at 21:45 -0500, Fernando Nasser wrote: > Anyone knows what was the resolution of this? > > Is Development/Libraries/Java OK or not? You can put whatever you would like in the Group field. Its not regulated in Fedora whatsoever. ~spot From Axel.Thimm at ATrpms.net Fri Feb 9 04:01:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Feb 2007 05:01:05 +0100 Subject: [Fedora-packaging] Too many exceptions Message-ID: <20070209040105.GC11018@neu.nirvana> Currently the guidelines are bloated with proposals for exceptions. How about we keep the guidelines clean and simple, and either relax their status from commandments to guidelines, or setup an Anti-guidelines wiki page where temporary exceptions are listed. I'm concerned that new packagers, or packagers revisiting the guidelines will need to filter the proper guidelines out of the exceptions, or mistake the exceptions for rules. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Feb 9 04:12:19 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Feb 2007 20:12:19 -0800 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <200702012330.11045.ville.skytta@iki.fi> References: <1170189972.31747.32.camel@localhost.localdomain> <200702010948.10362.ville.skytta@iki.fi> <45C1FE34.90904@redhat.com> <200702012330.11045.ville.skytta@iki.fi> Message-ID: <1170994339.4306.243.camel@localhost.localdomain> On Thu, 2007-02-01 at 23:30 +0200, Ville Skytt? wrote: > On Thursday 01 February 2007 16:50, Fernando Nasser wrote: > > Ville Skytt? wrote: > > > > > JPackage's pre-release Release: tags are not Xjpp only. Was this > > > considered in the draft? Some random examples: > > > > > > classpathx-jaxp-1.0-0.beta1.10jpp > > > cpptasks-1.0-0.b4.1jpp > > > cryptix-asn1-0.1.12-0.cvs20011119.7jpp > > > activemq3-3.2.5-0.r1125.2jpp > > > radeox-0.9-0.beta.2jpp > > > > > > More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/ > > > > These are old style tags, before Nicolas brought up the possible > > problems with upgrade paths. > > My point wasn't about whether they're 0.foo.Xjpp or 0.1.foo.Xjpp, but that the > draft says: > > "JPackage RPMS only use integers in the Release: field, > in the format Xjpp" > > Note: 0.foo.Xjpp is not in the Xjpp format, neither is 0.X.foo.Yjpp. For > example, 1jpp and 15jpp are. > > The draft goes on and says "If this is the case, then ..." and discusses how > to take care of stuff. I just want to make sure the discussion is not based > on a false assumption. I *guess* pre-release names like that are not a > problem, but haven't read the draft too thoroughly to be able to tell at the > moment. > Here's an attempt to resolve this:: When a jpackage package uses a prerelease, use %{fedora prerelease scheme}.Xjpp.%{rest of fedora release} where Xjpp is the integer+"jpp" portion of the jpackage release tag. Example: cpptasks-1.0-0.b4.1jpp => cpptasks-1.0-0.1.b4.1jpp.fc6[OPTIONAL .INT] When a jpackage package uses the same prerelease scheme as Fedora, this will allow interleaving: cpptasks-1.0-0.1.b4.1jpp => cpptasks-1.0-0.1.b4.1jpp.fc6.1 If the jpackage does not there can be breakage but it's not expected that this case will arise. The important thing is for the packagers to realize that the only thing coming from the jpackage tag is 1jpp. Doing this will help catch problems if someone wants to import a JPackage with this old version scheme or a JPackage that has a buggy version string. -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 fnasser at redhat.com Fri Feb 9 15:31:49 2007 From: fnasser at redhat.com (fnasser at redhat.com) Date: Fri, 9 Feb 2007 10:31:49 -0500 Subject: [Fedora-packaging] Exception for JPackage In-Reply-To: <1170994339.4306.243.camel@localhost.localdomain> References: <1170189972.31747.32.camel@localhost.localdomain> <200702010948.10362.ville.skytta@iki.fi> <45C1FE34.90904@redhat.com> <200702012330.11045.ville.skytta@iki.fi> <1170994339.4306.243.camel@localhost.localdomain> Message-ID: <20070209103149.4o4een5twkk844gk@webmail.corp.redhat.com> Quoting Toshio Kuratomi : > On Thu, 2007-02-01 at 23:30 +0200, Ville Skytt? wrote: >> On Thursday 01 February 2007 16:50, Fernando Nasser wrote: >> > Ville Skytt? wrote: >> > >> > > JPackage's pre-release Release: tags are not Xjpp only. Was this >> > > considered in the draft? Some random examples: >> > > >> > > classpathx-jaxp-1.0-0.beta1.10jpp >> > > cpptasks-1.0-0.b4.1jpp >> > > cryptix-asn1-0.1.12-0.cvs20011119.7jpp >> > > activemq3-3.2.5-0.r1125.2jpp >> > > radeox-0.9-0.beta.2jpp >> > > >> > > More at http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/ >> > >> > These are old style tags, before Nicolas brought up the possible >> > problems with upgrade paths. >> >> My point wasn't about whether they're 0.foo.Xjpp or 0.1.foo.Xjpp, >> but that the >> draft says: >> >> "JPackage RPMS only use integers in the Release: field, >> in the format Xjpp" >> >> Note: 0.foo.Xjpp is not in the Xjpp format, neither is 0.X.foo.Yjpp. For >> example, 1jpp and 15jpp are. >> >> The draft goes on and says "If this is the case, then ..." and discusses how >> to take care of stuff. I just want to make sure the discussion is not based >> on a false assumption. I *guess* pre-release names like that are not a >> problem, but haven't read the draft too thoroughly to be able to tell at the >> moment. >> > Here's an attempt to resolve this:: > > When a jpackage package uses a prerelease, use %{fedora prerelease > scheme}.Xjpp.%{rest of fedora release} where Xjpp is the integer+"jpp" > portion of the jpackage release tag. Example: > cpptasks-1.0-0.b4.1jpp => cpptasks-1.0-0.1.b4.1jpp.fc6[OPTIONAL .INT] > > When a jpackage package uses the same prerelease scheme as Fedora, this > will allow interleaving: > cpptasks-1.0-0.1.b4.1jpp => cpptasks-1.0-0.1.b4.1jpp.fc6.1 > > If the jpackage does not there can be breakage but it's not expected > that this case will arise. The important thing is for the packagers to > realize that the only thing coming from the jpackage tag is 1jpp. Doing > this will help catch problems if someone wants to import a JPackage with > this old version scheme or a JPackage that has a buggy version string. > > -Toshio > Hi Toshio, The new upstream JPackage scheme for pre-releases is actually based on the Fedora pre-release scheme and it is fully compatible with Fedora. Actually you seem to have guessed it right above: xxxxx-1.0-0.X..Yjpp where X = 1, 2, 3... and is incremented whenever the package is updated to a new pre-release tag. Rebuilds of the same sources increment the Y. Note that CVS and SVN date tags have now been changed to follow the same Fedora rule: YYYYMMDDcvs or YYYYMMDDsvn Also, as the Jpackage 1.7 release is not yet final, all the packages that have wrong pre-release tags will be rebuilt. (Note: there is a slim possibility that Epoch must be raised for some package, but hopefully not). Regards, Fernando From dlutter at redhat.com Fri Feb 9 19:03:35 2007 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 09 Feb 2007 11:03:35 -0800 Subject: [Fedora-packaging] Too many exceptions In-Reply-To: <20070209040105.GC11018@neu.nirvana> References: <20070209040105.GC11018@neu.nirvana> Message-ID: <1171047815.6483.50.camel@localhost.localdomain> On Fri, 2007-02-09 at 05:01 +0100, Axel Thimm wrote: > Currently the guidelines are bloated with proposals for exceptions. Instead of calling them 'exceptions' we should just face that they are the guidelines as they are now, and document on a separate page how we want to change the guidelines in the future, who needs to do what etc. I agree that it's confusing to call some of the existing guidelines 'exceptions' - that shouldn't matter to anybody submitting a package today. David From overholt at redhat.com Fri Feb 9 19:30:32 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 9 Feb 2007 14:30:32 -0500 Subject: [Fedora-packaging] Requires(post{,un}) on something in coreutils Message-ID: <20070209193032.GH1706@redhat.com> Hi, Are Requires(post{,un}) needed for things in coreutils? Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Feb 9 19:34:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 Feb 2007 13:34:16 -0600 Subject: [Fedora-packaging] Requires(post{,un}) on something in coreutils In-Reply-To: <20070209193032.GH1706@redhat.com> References: <20070209193032.GH1706@redhat.com> Message-ID: <45CCCCB8.3020000@math.unl.edu> Andrew Overholt wrote: > Are Requires(post{,un}) needed for things in coreutils? I'd lean toward yes. -- Rex From fnasser at redhat.com Fri Feb 9 20:46:30 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 09 Feb 2007 15:46:30 -0500 Subject: [Fedora-packaging] Requires(post{,un}) on something in coreutils In-Reply-To: <20070209193032.GH1706@redhat.com> References: <20070209193032.GH1706@redhat.com> Message-ID: <45CCDDA6.3070408@redhat.com> Andrew Overholt wrote: > Hi, > > Are Requires(post{,un}) needed for things in coreutils? > > The build system does not need it but Anaconda can get in trouble. We've been adding Requires(post{,un}) to rm and ls to several packages because of Anaconda. Cheers, Fernando From Axel.Thimm at ATrpms.net Fri Feb 9 21:24:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Feb 2007 22:24:08 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <45CCCCB8.3020000@math.unl.edu> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> Message-ID: <20070209212408.GA21848@neu.nirvana> On Fri, Feb 09, 2007 at 01:34:16PM -0600, Rex Dieter wrote: > Andrew Overholt wrote: > > >Are Requires(post{,un}) needed for things in coreutils? > > I'd lean toward yes. That would mean that any use of say "rm" or "test" in the scriplets would need a coreutils dependency. Since almost all upgrade/remove scriplets test $1, we'd have to add coreutils everywhere. Maybe we need a minimal assumed runtime environment just like we define a minimal assumed build evironment? The definition of such a beast would be the minimal set of packages that are needed to do anything sensible, for example everything that is pulled in by redhat-lsb (which includes coreutils). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 9 21:42:17 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Feb 2007 22:42:17 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070209212408.GA21848@neu.nirvana> (Axel Thimm's message of "Fri, 9 Feb 2007 22:24:08 +0100") References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> Message-ID: <87k5yrnh3a.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: > That would mean that any use of say "rm" or "test" in the scriplets > would need a coreutils dependency. Since almost all upgrade/remove > scriplets test $1, we'd have to add coreutils everywhere. 'test' is a bash builtin > Maybe we need a minimal assumed runtime environment just like we > define a minimal assumed build evironment? What's wrong with the current situation that we need such a change? > The definition of such a beast would be the minimal set of packages > that are needed to do anything sensible, for example everything that > is pulled in by redhat-lsb (which includes coreutils). Hahaha... Why not just add KDE and openoffice to the base environment? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Feb 9 21:50:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Feb 2007 22:50:01 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <87k5yrnh3a.fsf@kosh.bigo.ensc.de> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <87k5yrnh3a.fsf@kosh.bigo.ensc.de> Message-ID: <20070209215001.GB21848@neu.nirvana> On Fri, Feb 09, 2007 at 10:42:17PM +0100, Enrico Scholz wrote: > > Maybe we need a minimal assumed runtime environment just like we > > define a minimal assumed build evironment? > > What's wrong with the current situation that we need such a change? Because as it stands now the OP's question on whether to add coreutils as a dependency is valid and would have to be positively confirmed. Or rephrased: the current situation is that the practice and the guidelines diverge and we need to fix one of them. > > The definition of such a beast would be the minimal set of packages > > that are needed to do anything sensible, for example everything that > > is pulled in by redhat-lsb (which includes coreutils). > > Hahaha... Why not just add KDE and openoffice to the base environment? Because they are too big? Hohoho. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Feb 9 21:54:46 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 9 Feb 2007 23:54:46 +0200 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070209212408.GA21848@neu.nirvana> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> Message-ID: <200702092354.47083.ville.skytta@iki.fi> On Friday 09 February 2007 23:24, Axel Thimm wrote: > > Maybe we need a minimal assumed runtime environment just like we > define a minimal assumed build evironment? The definition of such a > beast would be the minimal set of packages that are needed to do > anything sensible, for example everything that is pulled in by > redhat-lsb (which includes coreutils). redhat-lsb is far from being a suitable package for this. As an example, here's what "yum install redhat-lsb" would do to my very sensibly working, although admittedly quite trimmed down PVR running FC6: ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: redhat-lsb i386 3.1-11 core 21 k Installing for dependencies: at i386 3.1.8-84.fc6 updates 55 k bc i386 1.06-21 core 106 k binutils i386 2.17.50.0.6-2.fc6 updates 2.9 M cairo i386 1.2.6-1.fc6 updates 406 k cups i386 1:1.2.7-1.8.fc6 updates 2.8 M cups-libs i386 1:1.2.7-1.8.fc6 updates 181 k dbus i386 1.0.1-9.fc6 updates 471 k ed i386 0.3-0.fc6 updates 54 k file i386 4.19-1.fc6 updates 357 k gettext i386 0.14.6-4.fc6 updates 1.4 M gnutls i386 1.4.1-2 core 349 k groff i386 1.18.1.1-11.1 core 1.9 M libXft i386 2.1.10-1.1 core 44 k libXi i386 1.0.1-3.1 core 25 k libXrender i386 0.9.1-3.1 core 27 k libXt i386 1.0.2-3.1.fc6 core 174 k libxml2-python i386 2.6.27-1.FC6 updates 705 k m4 i386 1.4.5-4 updates 133 k make i386 1:3.81-1.1 core 465 k man i386 1.6d-2.fc6 updates 263 k pango i386 1.14.8-1.fc6 updates 330 k paps i386 0.6.6-17.fc6 updates 32 k patch i386 2.5.4-29.2.2 core 64 k pax i386 3.4-1.2.2 core 63 k time i386 1.7-27.2.2 core 17 k tmpwatch i386 2.9.7-1.1 core 18 k Transaction Summary ============================================================================= Install 27 Package(s) Update 0 Package(s) Remove 0 Package(s) From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 9 22:08:56 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Feb 2007 23:08:56 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070209215001.GB21848@neu.nirvana> (Axel Thimm's message of "Fri, 9 Feb 2007 22:50:01 +0100") References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <87k5yrnh3a.fsf@kosh.bigo.ensc.de> <20070209215001.GB21848@neu.nirvana> Message-ID: <87fy9fnfuv.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> > Maybe we need a minimal assumed runtime environment just like we >> > define a minimal assumed build evironment? >> >> What's wrong with the current situation that we need such a change? > > Because as it stands now the OP's question on whether to add coreutils > as a dependency is valid and would have to be positively confirmed. Or > rephrased: the current situation is that the practice and the > guidelines diverge and we need to fix one of them. Obviously, 'coreutils' MUST be a Requires(...) when they are used in the corresponding scriptlet. Afais, only some Core package are violating this simple rule and must be fixed. >> > The definition of such a beast would be the minimal set of packages >> > that are needed to do anything sensible, for example everything >> > that is pulled in by redhat-lsb (which includes coreutils). >> >> Hahaha... Why not just add KDE and openoffice to the base environment? > > Because they are too big? Hohoho. Is there such big difference in the size between 'redhat-lsb' and 'KDE'? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Feb 9 22:30:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Feb 2007 23:30:34 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <200702092354.47083.ville.skytta@iki.fi> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> Message-ID: <20070209223034.GC21848@neu.nirvana> On Fri, Feb 09, 2007 at 11:54:46PM +0200, Ville Skytt? wrote: > On Friday 09 February 2007 23:24, Axel Thimm wrote: > > > > Maybe we need a minimal assumed runtime environment just like we > > define a minimal assumed build evironment? The definition of such a > > beast would be the minimal set of packages that are needed to do > > anything sensible, for example everything that is pulled in by > > redhat-lsb (which includes coreutils). > > redhat-lsb is far from being a suitable package for this. As an example, > here's what "yum install redhat-lsb" would do to my very sensibly working, > although admittedly quite trimmed down PVR running FC6: > libXrender i386 0.9.1-3.1 core 27 k Indeed, redhat-lsb does pull in a lot of crap, and thanks for going into details to demonstrate this (it does make a difference whether s/o explains his viewpoint or not ..., Ville get's all the karma points this round ;). Anyway the basic idea remains, we need something to define a very basic run time environment which all packages (but some bootstraping ones like glibc/setup/filesystem) may assume existing to not bloat the dependencies. Perhaps that's just coreutils and its dependencies, perhaps more. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Feb 9 23:03:08 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 Feb 2007 18:03:08 -0500 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070209223034.GC21848@neu.nirvana> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> <20070209223034.GC21848@neu.nirvana> Message-ID: <20070209230308.GA18973@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > Anyway the basic idea remains, we need something to define a very > basic run time environment which all packages (but some bootstraping > ones like glibc/setup/filesystem) may assume existing to not bloat the > dependencies. Perhaps that's just coreutils and its dependencies, > perhaps more. ... why? Bill, who must have missed the first part of this... From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 9 23:28:47 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Feb 2007 00:28:47 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070209223034.GC21848@neu.nirvana> (Axel Thimm's message of "Fri, 9 Feb 2007 23:30:34 +0100") References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> <20070209223034.GC21848@neu.nirvana> Message-ID: <87bqk2oqq8.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: > Anyway the basic idea remains, we need something to define a very > basic run time environment which all packages (but some bootstraping > ones like glibc/setup/filesystem) may assume existing to not bloat the > dependencies. Why do we need such exceptions? Are there existing problems with the current practice? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From katzj at redhat.com Sat Feb 10 03:57:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 09 Feb 2007 22:57:51 -0500 Subject: [Fedora-packaging] Requires(post{,un}) on something in coreutils In-Reply-To: <45CCDDA6.3070408@redhat.com> References: <20070209193032.GH1706@redhat.com> <45CCDDA6.3070408@redhat.com> Message-ID: <1171079871.16241.1.camel@aglarond.local> On Fri, 2007-02-09 at 15:46 -0500, Fernando Nasser wrote: > Andrew Overholt wrote: > > Are Requires(post{,un}) needed for things in coreutils? > > > The build system does not need it but Anaconda can get in trouble. > We've been adding Requires(post{,un}) to rm and ls to several packages > because of Anaconda. More accurately, it's needed to get proper ordering in any case of building a new chroot. This doesn't get hit with initializing build roots due to the fact that they're (currently) done by "install minimal system, then build deps". This could change at a point in the future. But yes, the requirements for things in coreutils must be explicitly specified, just like anything else. Jeremy From rc040203 at freenet.de Sat Feb 10 06:13:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Feb 2007 07:13:27 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <200702092354.47083.ville.skytta@iki.fi> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> Message-ID: <1171088008.31485.210.camel@mccallum.corsepiu.local> On Fri, 2007-02-09 at 23:54 +0200, Ville Skytt? wrote: > On Friday 09 February 2007 23:24, Axel Thimm wrote: > > > > Maybe we need a minimal assumed runtime environment just like we > > define a minimal assumed build evironment? How about implementing a POSIX utilities package (or meta-package) consisting of all mandatory POSIX utilities? c.f. http://www.opengroup.org/onlinepubs/009695399/idx/utilities.html Ralf From pertusus at free.fr Sat Feb 10 09:52:22 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Feb 2007 10:52:22 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <1171088008.31485.210.camel@mccallum.corsepiu.local> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> <1171088008.31485.210.camel@mccallum.corsepiu.local> Message-ID: <20070210095222.GC2797@free.fr> On Sat, Feb 10, 2007 at 07:13:27AM +0100, Ralf Corsepius wrote: > > c.f. > http://www.opengroup.org/onlinepubs/009695399/idx/utilities.html There are some old stuff in it, I spotted fort77 which is doesn't seems to be provided in fedora. -- Pat From Axel.Thimm at ATrpms.net Sat Feb 10 13:53:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Feb 2007 14:53:47 +0100 Subject: [Fedora-packaging] Wrong buildroot ... Message-ID: <20070210135347.GD21848@neu.nirvana> a) the raguments were mainly between racor and myself b) topic was decided on an IRC meeting I couldn't attend c) The summary of my arguments were given by ... racor ??? d) My arguments were not "I do it with macros, don't care about the rest" => Deliberately misquoted? e) True arguments are that obscuring the buildroot for the sake of an extremely rare corner case (several users building the same package on the same system w/o chroots) implies fixing it for far more not corner-cases like building i386 and x86_64 packages simulataneously. So the `id -nu` part is far less important than adding the target arch, but that was silently forgotten by racor I remember us waiting for racor to finish with his relocation for a couple of months before dicussing topics where he was having an active opinion and in this case it's a blitz decision in absence of one party. I'm also not amuised by racor's misquoting, be it deliberate or not. In light of the above I'd like to ask to rediscuss this. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Feb 10 14:13:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Feb 2007 15:13:44 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070209230308.GA18973@nostromo.devel.redhat.com> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> <20070209223034.GC21848@neu.nirvana> <20070209230308.GA18973@nostromo.devel.redhat.com> Message-ID: <20070210141344.GE21848@neu.nirvana> On Fri, Feb 09, 2007 at 06:03:08PM -0500, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > Anyway the basic idea remains, we need something to define a very > > basic run time environment which all packages (but some bootstraping > > ones like glibc/setup/filesystem) may assume existing to not bloat the > > dependencies. Perhaps that's just coreutils and its dependencies, > > perhaps more. > > ... why? > > Bill, who must have missed the first part of this... My assumption is that there are many packages making use of coreutils implicitely in their scriplets by using mv/rm/cp/touch etc w/o Requires(xxx) on coreutils (or a virtual/file provides of it). I think any package with a scriplet that doesn't chkconfig/service is most probably using coreutils w/o pulling it in (e.g. like rpm). The situation is saved by sibling packages like initscripts and/or the kernel, e.g. the "bug" of missing coreutils dependencies goes unseen as there are very few setups w/o initscripts/kernel already in place. Still the packages are "broken" in the sense of not pulling in their dependencies themselves (inlcuding recursive pulling) as required by the guidelines. So it's either a) Axel's assumption wrong, there are only few packages doing that - ignore him b) A large number of packages violating guidelines, so we either b1) fix all these packages b2) adjust the guidelines to assume existence of coreutils for 99.9% of all packages (reverse exceptions would be kernel/initscripts etc., something has to pull in coreutils after all) Depending on the actual number of these packages the order of action is a) b1) b2), and I think the number will be large. Maybe someone wants to script something to grep though all scriplets for coreutils bits to get these numbers. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Sat Feb 10 14:19:00 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Feb 2007 15:19:00 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070210095222.GC2797@free.fr> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> <1171088008.31485.210.camel@mccallum.corsepiu.local> <20070210095222.GC2797@free.fr> Message-ID: <1171117140.31485.219.camel@mccallum.corsepiu.local> On Sat, 2007-02-10 at 10:52 +0100, Patrice Dumas wrote: > On Sat, Feb 10, 2007 at 07:13:27AM +0100, Ralf Corsepius wrote: > > > > c.f. > > http://www.opengroup.org/onlinepubs/009695399/idx/utilities.html > > There are some old stuff in it, What you call old is IEEE Std 1003.1, aka. SUSv3, THE current POSIX standard. > I spotted fort77 which is doesn't seems > to be provided in fedora. It's an FD extension to SUSv3, an option. Ralf From rc040203 at freenet.de Sat Feb 10 14:36:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Feb 2007 15:36:13 +0100 Subject: [Fedora-packaging] Wrong buildroot ... In-Reply-To: <20070210135347.GD21848@neu.nirvana> References: <20070210135347.GD21848@neu.nirvana> Message-ID: <1171118174.31485.236.camel@mccallum.corsepiu.local> Mr. Thimm, you don't seriously expect an answer to this email, which I consider to be filled with hostile and false allegations of yours. On Sat, 2007-02-10 at 14:53 +0100, Axel Thimm wrote: > a) the raguments were mainly between racor and myself > b) topic was decided on an IRC meeting I couldn't attend > c) The summary of my arguments were given by ... racor ??? > d) My arguments were not "I do it with macros, don't care about the rest" > => Deliberately misquoted? You could not be wronger. > e) True arguments are that > obscuring the buildroot for the sake of an extremely rare > corner case (several users building the same package on the > same system w/o chroots) implies fixing it for far more not > corner-cases like building i386 and x86_64 packages > simulataneously. So the `id -nu` part is far less important > than adding the target arch, but that was silently forgotten by > racor You should remember that this had been an IRC, and I was citing off-head. > I remember us waiting for racor to finish with his relocation for a > couple of months before dicussing topics where he was having an > active opinion and in this case it's a blitz decision in absence of > one party. I'm also not amuised by racor's misquoting, be it > deliberate or not. > > In light of the above I'd like to ask to rediscuss this. I don't have a log of this meeting, but IIRC, we concluded to revisit this topic should something appear _technically_ broken with it. Ralf From pertusus at free.fr Sat Feb 10 14:59:05 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Feb 2007 15:59:05 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <1171117140.31485.219.camel@mccallum.corsepiu.local> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> <1171088008.31485.210.camel@mccallum.corsepiu.local> <20070210095222.GC2797@free.fr> <1171117140.31485.219.camel@mccallum.corsepiu.local> Message-ID: <20070210145905.GC24710@free.fr> On Sat, Feb 10, 2007 at 03:19:00PM +0100, Ralf Corsepius wrote: > > What you call old is IEEE Std 1003.1, aka. SUSv3, THE current POSIX > standard. The standard may be recent, there are some old stuff in it. I have nothing against old stuff, I actually happen to maintain asa, but I don't think it belongs to a package set installed anywhere. Reading a bit more, there are indeed categories, so asa , fort77 and sccs are optional. Maybe you wanted to have the all the mandatory commands? I think that it is still too much since there seems to be bc, for example, which is very usefull but not vital at all. -- Pat From pertusus at free.fr Sat Feb 10 15:01:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Feb 2007 16:01:00 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070210145905.GC24710@free.fr> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> <1171088008.31485.210.camel@mccallum.corsepiu.local> <20070210095222.GC2797@free.fr> <1171117140.31485.219.camel@mccallum.corsepiu.local> <20070210145905.GC24710@free.fr> Message-ID: <20070210150100.GD24710@free.fr> On Sat, Feb 10, 2007 at 03:59:05PM +0100, Patrice Dumas wrote: > > Maybe you wanted to have the all the mandatory commands? I think that In fact it is exactly what you said... > it is still too much since there seems to be bc, for example, which is very > usefull but not vital at all. A meta package or a comps category could be used, however, but I don't think it should be assumed to be there. -- Pat From rc040203 at freenet.de Sat Feb 10 15:15:43 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Feb 2007 16:15:43 +0100 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070210150100.GD24710@free.fr> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> <1171088008.31485.210.camel@mccallum.corsepiu.local> <20070210095222.GC2797@free.fr> <1171117140.31485.219.camel@mccallum.corsepiu.local> <20070210145905.GC24710@free.fr> <20070210150100.GD24710@free.fr> Message-ID: <1171120543.31485.259.camel@mccallum.corsepiu.local> On Sat, 2007-02-10 at 16:01 +0100, Patrice Dumas wrote: > On Sat, Feb 10, 2007 at 03:59:05PM +0100, Patrice Dumas wrote: > > > > Maybe you wanted to have the all the mandatory commands? I think that > > In fact it is exactly what you said... Almost, but not quite - POSIX mandates a certain set of "utilities" any POSIX compliant system must provide as "smallest common denominator". These tools are a real world "norm"/"standard", all portable SW should be able to rely on. My initial posting therefore was aim at, instead of "implementing a Fedora ad-hock standard set of utilities" to adopt what POSIX mandates. Ralf From a.badger at gmail.com Sat Feb 10 18:41:44 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 10 Feb 2007 10:41:44 -0800 Subject: [Fedora-packaging] Wrong buildroot ... In-Reply-To: <20070210135347.GD21848@neu.nirvana> References: <20070210135347.GD21848@neu.nirvana> Message-ID: <1171132904.4306.274.camel@localhost.localdomain> On Sat, 2007-02-10 at 14:53 +0100, Axel Thimm wrote: > e) True arguments are that > obscuring the buildroot for the sake of an extremely rare > corner case (several users building the same package on the > same system w/o chroots) implies fixing it for far more not > corner-cases like building i386 and x86_64 packages > simulataneously. So the `id -nu` part is far less important > than adding the target arch, but that was silently forgotten by > racor > Is your suggestion to add arch to the buildroot? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Sat Feb 10 23:05:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 11 Feb 2007 00:05:07 +0100 Subject: [Fedora-packaging] Re: Wrong buildroot ... In-Reply-To: <1171132904.4306.274.camel@localhost.localdomain> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> Message-ID: <20070210230507.GC23731@neu.nirvana> On Sat, Feb 10, 2007 at 10:41:44AM -0800, Toshio Kuratomi wrote: > On Sat, 2007-02-10 at 14:53 +0100, Axel Thimm wrote: > > e) True arguments are that > > obscuring the buildroot for the sake of an extremely rare > > corner case (several users building the same package on the > > same system w/o chroots) implies fixing it for far more not > > corner-cases like building i386 and x86_64 packages > > simulataneously. So the `id -nu` part is far less important > > than adding the target arch, but that was silently forgotten by > > racor > > > Is your suggestion to add arch to the buildroot? No, my suggestion is to loose up on requirements on buildroots. There is no known problem ever caused by choosing a "wrong" buildroot even by novices, and we're definitely over-engineering in fixing stuff that never broke. But if you want to be pedantic about corner cases, you would have to take arch far more serious than the user's id. The current suggested/preferred/mandatory buildroot is far from being worth being called that way. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jorton at redhat.com Mon Feb 12 15:52:18 2007 From: jorton at redhat.com (Joe Orton) Date: Mon, 12 Feb 2007 15:52:18 +0000 Subject: [Fedora-packaging] Re: Wrong buildroot ... In-Reply-To: <20070210230507.GC23731@neu.nirvana> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> Message-ID: <20070212155218.GA25585@redhat.com> On Sun, Feb 11, 2007 at 12:05:07AM +0100, Axel Thimm wrote: > On Sat, Feb 10, 2007 at 10:41:44AM -0800, Toshio Kuratomi wrote: > > On Sat, 2007-02-10 at 14:53 +0100, Axel Thimm wrote: > > > e) True arguments are that > > > obscuring the buildroot for the sake of an extremely rare > > > corner case (several users building the same package on the > > > same system w/o chroots) implies fixing it for far more not > > > corner-cases like building i386 and x86_64 packages > > > simulataneously. So the `id -nu` part is far less important > > > than adding the target arch, but that was silently forgotten by > > > racor > > > > > Is your suggestion to add arch to the buildroot? > > No, my suggestion is to loose up on requirements on buildroots. There > is no known problem ever caused by choosing a "wrong" buildroot even > by novices, and we're definitely over-engineering in fixing stuff that > never broke. I completely agree with that. Unless the buildroot is picked by mkdtemp() you can't really *guarantee* avoidance of conflicts. If you want a guarantee then rpmbuild should be fixed to ignore BuildRoot and use mkdtemp() instead. Standardising an inadequate workaround and having packagers go through fixing N hundred spec files to match seems like a waste of time. joe From jkeating at redhat.com Mon Feb 12 15:57:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 10:57:40 -0500 Subject: [Fedora-packaging] Re: Wrong buildroot ... In-Reply-To: <20070212155218.GA25585@redhat.com> References: <20070210135347.GD21848@neu.nirvana> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> Message-ID: <200702121057.40586.jkeating@redhat.com> On Monday 12 February 2007 10:52, Joe Orton wrote: > I completely agree with that. ?Unless the buildroot is picked by > mkdtemp() you can't really *guarantee* avoidance of conflicts. ?If you > want a guarantee then rpmbuild should be fixed to ignore BuildRoot and > use mkdtemp() instead. ?Standardising an inadequate workaround and > having packagers go through fixing N hundred spec files to match seems > like a waste of time. +1 We have the spec stubs that have an acceptable buildroot tag for new packages, I don't see much value in harping on existing packages for the BuildRoot. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Feb 12 15:54:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 10:54:38 -0500 Subject: [Fedora-packaging] Re: Requires(post{, un}) on something in coreutils In-Reply-To: <20070210141344.GE21848@neu.nirvana> References: <20070209193032.GH1706@redhat.com> <45CCCCB8.3020000@math.unl.edu> <20070209212408.GA21848@neu.nirvana> <200702092354.47083.ville.skytta@iki.fi> <20070209223034.GC21848@neu.nirvana> <20070209230308.GA18973@nostromo.devel.redhat.com> <20070210141344.GE21848@neu.nirvana> Message-ID: <20070212155438.GD11536@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > b) A large number of packages violating guidelines, so we either > b1) fix all these packages Yeah, I'd just say fix them all. Bill From rc040203 at freenet.de Mon Feb 12 15:57:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 12 Feb 2007 16:57:36 +0100 Subject: [Fedora-packaging] Re: Wrong buildroot ... In-Reply-To: <20070212155218.GA25585@redhat.com> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> Message-ID: <1171295856.3622.23.camel@mccallum.corsepiu.local> On Mon, 2007-02-12 at 15:52 +0000, Joe Orton wrote: > On Sun, Feb 11, 2007 at 12:05:07AM +0100, Axel Thimm wrote: > > On Sat, Feb 10, 2007 at 10:41:44AM -0800, Toshio Kuratomi wrote: > > > On Sat, 2007-02-10 at 14:53 +0100, Axel Thimm wrote: > > > > e) True arguments are that > > > > obscuring the buildroot for the sake of an extremely rare > > > > corner case (several users building the same package on the > > > > same system w/o chroots) implies fixing it for far more not > > > > corner-cases like building i386 and x86_64 packages > > > > simulataneously. So the `id -nu` part is far less important > > > > than adding the target arch, but that was silently forgotten by > > > > racor > > > > > > > Is your suggestion to add arch to the buildroot? > > > > No, my suggestion is to loose up on requirements on buildroots. There > > is no known problem ever caused by choosing a "wrong" buildroot even > > by novices, and we're definitely over-engineering in fixing stuff that > > never broke. > > I completely agree with that. Unless the buildroot is picked by > mkdtemp() you can't really *guarantee* avoidance of conflicts. If you > want a guarantee then rpmbuild should be fixed to ignore BuildRoot and > use mkdtemp() instead. Standardising an inadequate workaround and > having packagers go through fixing N hundred spec files to match seems > like a waste of time. Wrong, it would be one single sed invocation. Ralf From rdieter at fedoraproject.org Mon Feb 12 16:20:08 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 12 Feb 2007 10:20:08 -0600 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> Message-ID: Joe Orton wrote: > Standardising an inadequate workaround and > having packagers go through fixing N hundred spec files to match seems > like a waste of time. *sigh*. One justification the FPC had used for mandating a standard buildroot was to avoid the waste of time associated with endless debates on mailing lists and package reviews. So much for that plan. (: -- Rex From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 12 16:50:59 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 12 Feb 2007 17:50:59 +0100 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> Message-ID: <20070212175059.31dee292@python3.es.egwn.lan> Rex Dieter wrote : > Joe Orton wrote: > > > Standardising an inadequate workaround and > > having packagers go through fixing N hundred spec files to match seems > > like a waste of time. > > *sigh*. One justification the FPC had used for mandating a standard > buildroot was to avoid the waste of time associated with endless debates on > mailing lists and package reviews. So much for that plan. (: The "standard" buildroot plan is a good plan, as long as the goal involves ripping it out from all spec files once and for all (i.e. have a sane default set for rpmbuild). I keep repeating this, sorry, but am I the only one who'd like to see all useless and repetitive stuff taken out of spec files? - BuildRoot - The "-q" to %setup - BuildRoot cleanup when %install and %clean start - %defattr(-,root,root,-) or %defattr(-,root,root,0755) For now, I do find it silly to add the 'id' execution to the buildroot. And I avoid doing silly things when they relate to serious matters :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.88 1.10 0.86 From tcallawa at redhat.com Mon Feb 12 17:45:53 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 12 Feb 2007 11:45:53 -0600 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <20070212175059.31dee292@python3.es.egwn.lan> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> Message-ID: <1171302353.25143.11.camel@localhost.localdomain> On Mon, 2007-02-12 at 17:50 +0100, Matthias Saou wrote: > Rex Dieter wrote : > > > Joe Orton wrote: > > > > > Standardising an inadequate workaround and > > > having packagers go through fixing N hundred spec files to match seems > > > like a waste of time. > > > > *sigh*. One justification the FPC had used for mandating a standard > > buildroot was to avoid the waste of time associated with endless debates on > > mailing lists and package reviews. So much for that plan. (: > > The "standard" buildroot plan is a good plan, as long as the goal > involves ripping it out from all spec files once and for all (i.e. have > a sane default set for rpmbuild). > > I keep repeating this, sorry, but am I the only one who'd like to see > all useless and repetitive stuff taken out of spec files? > - BuildRoot > - The "-q" to %setup > - BuildRoot cleanup when %install and %clean start > - %defattr(-,root,root,-) or %defattr(-,root,root,0755) No. Accepting patches. Welcoming patches. ~spot From tibbs at math.uh.edu Mon Feb 12 18:32:21 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Feb 2007 12:32:21 -0600 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <20070212175059.31dee292@python3.es.egwn.lan> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> Message-ID: >>>>> "MS" == Matthias Saou writes: MS> I keep repeating this, sorry, but am I the only one who'd like to MS> see all useless and repetitive stuff taken out of spec files? Of course not; the packaging committee has been vocal about wishing to change some of these. But you have to keep in mind that changes to rpm itself will block until something happens on that front, and that's completely out of our hands. If you know how to fix RPM to do some of these things, please do tell. - J< From tmz at pobox.com Mon Feb 12 18:49:26 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 12 Feb 2007 13:49:26 -0500 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> Message-ID: <20070212184926.GI11003@psilocybe.teonanacatl.org> Jason L Tibbitts III wrote: > If you know how to fix RPM to do some of these things, please do > tell. I haven't looked at the rpm source at all yet, but I think the buildroot is one that can be "fixed" just using a macro. From /usr/lib/rpm/macros: # ---- Optional rpmrc macros. # Macros that are initialized as a side effect of rpmrc and/or spec # file parsing. # # Configurable build root path, same as BuildRoot: in a specfile. # (Note: the configured macro value will override the spec file value). # #%buildroot If the packaging committee wanted to make a standard buildroot and enforce it have the build systems set %buildroot. Then all the BuildRoot values in spec files could just be removed (at the very least they should be irrelevant since they will be overridden according to the comments in /usr/lib/rpm/macros). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== The future isn't what it used to be. -- Arthur C. Clarke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Feb 12 18:55:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 12 Feb 2007 12:55:55 -0600 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <20070212184926.GI11003@psilocybe.teonanacatl.org> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> <20070212184926.GI11003@psilocybe.teonanacatl.org> Message-ID: <45D0B83B.90607@math.unl.edu> Todd Zullinger wrote: > Jason L Tibbitts III wrote: >> If you know how to fix RPM to do some of these things, please do >> tell. > > I haven't looked at the rpm source at all yet, but I think the > buildroot is one that can be "fixed" just using a macro. > > From /usr/lib/rpm/macros: > # ---- Optional rpmrc macros. > # Macros that are initialized as a side effect of rpmrc and/or spec > # file parsing. > # > # Configurable build root path, same as BuildRoot: in a specfile. > # (Note: the configured macro value will override the spec file value). > # > #%buildroot > > If the packaging committee wanted to make a standard buildroot and > enforce it have the build systems set %buildroot. We looked into that. I recall there some serious implementation problems with that method. -- Rex From jkeating at redhat.com Mon Feb 12 18:59:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 13:59:49 -0500 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <45D0B83B.90607@math.unl.edu> References: <20070210135347.GD21848@neu.nirvana> <20070212184926.GI11003@psilocybe.teonanacatl.org> <45D0B83B.90607@math.unl.edu> Message-ID: <200702121359.49552.jkeating@redhat.com> On Monday 12 February 2007 13:55, Rex Dieter wrote: > > #%buildroot > > > > If the packaging committee wanted to make a standard buildroot and > > enforce it have the build systems set %buildroot. ? > > We looked into that. ?I recall there some serious implementation > problems with that method. Not to mention that this severely hurts our spec portability. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Feb 12 19:04:22 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 12 Feb 2007 13:04:22 -0600 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <200702121359.49552.jkeating@redhat.com> References: <20070210135347.GD21848@neu.nirvana> <20070212184926.GI11003@psilocybe.teonanacatl.org> <45D0B83B.90607@math.unl.edu> <200702121359.49552.jkeating@redhat.com> Message-ID: <45D0BA36.5010901@math.unl.edu> Jesse Keating wrote: > On Monday 12 February 2007 13:55, Rex Dieter wrote: >>> #%buildroot >>> >>> If the packaging committee wanted to make a standard buildroot and >>> enforce it have the build systems set %buildroot. >> We looked into that. I recall there some serious implementation >> problems with that method. > > Not to mention that this severely hurts our spec portability. like dropping Group: tag? (: -- Rex From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 12 19:08:18 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 12 Feb 2007 20:08:18 +0100 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <200702121359.49552.jkeating@redhat.com> References: <20070210135347.GD21848@neu.nirvana> <20070212184926.GI11003@psilocybe.teonanacatl.org> <45D0B83B.90607@math.unl.edu> <200702121359.49552.jkeating@redhat.com> Message-ID: <20070212200818.4ad6fefc@python3.es.egwn.lan> Jesse Keating wrote : > On Monday 12 February 2007 13:55, Rex Dieter wrote: > > > #%buildroot > > > > > > If the packaging committee wanted to make a standard buildroot and > > > enforce it have the build systems set %buildroot. ? > > > > We looked into that. ?I recall there some serious implementation > > problems with that method. > > Not to mention that this severely hurts our spec portability. The later we postpone any major change, the longer we will be stuck with "legacy" spec files. If this change had been made for Fedora Core 3 or 4, we could realistically be dealing with buildroot-less spec files nowadays. To be thinking _now_ about major cleanups that we could go forward with by the time we hit Fedora _10_ doesn't seem that crazy to me. I'd definitely like to have a look at the "new" rpm when I've got some time in order to see how complicated any of these changes would be... Oh, and if by "portability" you meant across to other distros, sure it'll "hurt" it, but I don't think this has ever been regarded as an important feature of Fedora packages, as they're initially only meant for Fedora itself... and other distros could start doing the same as us :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 2.12 1.68 1.43 From tibbs at math.uh.edu Mon Feb 12 19:14:08 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Feb 2007 13:14:08 -0600 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <200702121359.49552.jkeating@redhat.com> References: <20070210135347.GD21848@neu.nirvana> <20070212184926.GI11003@psilocybe.teonanacatl.org> <45D0B83B.90607@math.unl.edu> <200702121359.49552.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Not to mention that this severely hurts our spec portability. If by that you mean that people wanting to take our specs to other distros have to add a single line containing "BuildRoot:" and they get to argue about what it should contain instead of us, then I'm all for it. - J< From ville.skytta at iki.fi Mon Feb 12 19:38:44 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 12 Feb 2007 21:38:44 +0200 Subject: [Fedora-packaging] Missing tomorrow's meeting Message-ID: <200702122138.44480.ville.skytta@iki.fi> Hello, Looks like I'll be missing tomorrow's packaging committee meeting. From tmz at pobox.com Mon Feb 12 19:41:41 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 12 Feb 2007 14:41:41 -0500 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <45D0B83B.90607@math.unl.edu> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> <20070212184926.GI11003@psilocybe.teonanacatl.org> <45D0B83B.90607@math.unl.edu> Message-ID: <20070212194141.GK11003@psilocybe.teonanacatl.org> Rex Dieter wrote: > Todd Zullinger wrote: [...] >>If the packaging committee wanted to make a standard buildroot and >>enforce it have the build systems set %buildroot. > > We looked into that. I recall there some serious implementation > problems with that method. Ah, I should've guessed it wouldn't be that simple. :) Do you (or anyone else) recall if the problems were in addition to just causing other builders a hassle if they try to build packages which lack a BuildRoot? That one seems rather minor to me, especially considering that the BuildRoot: tag doesn't have to be removed from spec files immediately, it would just become irrelevant for review purposes (one less nit for anyone to pick). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== Nothing is so simple that it cannot be misunderstood. -- Teague's Paradox -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Feb 12 19:45:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 12 Feb 2007 13:45:55 -0600 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <20070212194141.GK11003@psilocybe.teonanacatl.org> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> <20070212184926.GI11003@psilocybe.teonanacatl.org> <45D0B83B.90607@math.unl.edu> <20070212194141.GK11003@psilocybe.teonanacatl.org> Message-ID: <45D0C3F3.9010601@math.unl.edu> Todd Zullinger wrote: > Rex Dieter wrote: >> Todd Zullinger wrote: > [...] >>> If the packaging committee wanted to make a standard buildroot and >>> enforce it have the build systems set %buildroot. >> We looked into that. I recall there some serious implementation >> problems with that method. > > Ah, I should've guessed it wouldn't be that simple. :) > > Do you (or anyone else) recall if the problems were... One biggie: Setting rpm macro %buildroot didn't populate $RPM_BUILD_ROOT. -- Rex From tmz at pobox.com Mon Feb 12 20:24:06 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 12 Feb 2007 15:24:06 -0500 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <45D0C3F3.9010601@math.unl.edu> References: <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> <20070212184926.GI11003@psilocybe.teonanacatl.org> <45D0B83B.90607@math.unl.edu> <20070212194141.GK11003@psilocybe.teonanacatl.org> <45D0C3F3.9010601@math.unl.edu> Message-ID: <20070212202406.GL11003@psilocybe.teonanacatl.org> Rex Dieter wrote: >>Do you (or anyone else) recall if the problems were... > > One biggie: Setting rpm macro %buildroot didn't populate > $RPM_BUILD_ROOT. That sounds a little like a plus to me. It would mean that the section on Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS could be eliminated (at least the buildroot portion.) A s/\$RPM_BUILD_ROOT/%{buildroot}/ could fix all current spec files. (I'm only half joking. :-) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== Bureaucracy is the enemy of innovation. -- Mark Shepherd, former President and CEO of Texas Instruments -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Feb 12 21:01:20 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 12 Feb 2007 23:01:20 +0200 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <20070212202406.GL11003@psilocybe.teonanacatl.org> References: <1171132904.4306.274.camel@localhost.localdomain> <45D0C3F3.9010601@math.unl.edu> <20070212202406.GL11003@psilocybe.teonanacatl.org> Message-ID: <200702122301.21016.ville.skytta@iki.fi> On Monday 12 February 2007 22:24, Todd Zullinger wrote: > Rex Dieter wrote: > >>Do you (or anyone else) recall if the problems were... > > > > One biggie: Setting rpm macro %buildroot didn't populate > > $RPM_BUILD_ROOT. > > That sounds a little like a plus to me. It would mean that the > section on Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and > $RPM_OPT_FLAGS could be eliminated (at least the buildroot portion.) > > A s/\$RPM_BUILD_ROOT/%{buildroot}/ could fix all current spec files. No, it would just shift the problem elsewhere. It can be also argued that s/%{buildroot}/\$RPM_BUILD_ROOT/ would be the less evil way around. More than one wants to read about it is available in the archives, see the thread starting at [1], especially towards the end of it, eg. [2] and the message it links to. [1] https://www.redhat.com/archives/fedora-packaging/2006-July/msg00250.html [2] https://www.redhat.com/archives/fedora-packaging/2006-July/msg00308.html From notting at redhat.com Mon Feb 12 21:03:04 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 16:03:04 -0500 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <20070212194141.GK11003@psilocybe.teonanacatl.org> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> <20070212184926.GI11003@psilocybe.teonanacatl.org> <45D0B83B.90607@math.unl.edu> <20070212194141.GK11003@psilocybe.teonanacatl.org> Message-ID: <20070212210304.GE7175@nostromo.devel.redhat.com> Todd Zullinger (tmz at pobox.com) said: > >>If the packaging committee wanted to make a standard buildroot and > >>enforce it have the build systems set %buildroot. > > > > We looked into that. I recall there some serious implementation > > problems with that method. > > Ah, I should've guessed it wouldn't be that simple. :) rpm is somewhat braindead. It only uses %{buildroot} if there actually is a BuildRoot: line in the spec file. In any case, https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-February/000162.html Bill From notting at redhat.com Tue Feb 13 01:52:58 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 20:52:58 -0500 Subject: [Fedora-packaging] Firmware packaging Message-ID: <20070213015257.GA12724@nostromo.devel.redhat.com> We did some discussion at the board meeting last week about firmware images, such as that used for ipw2200. The decision was made that we're OK with shipping these firmware images based on the guidelines currently in the packaging guidelines: * The files are non-executable (note: this means that the files cannot run on their own, not that they are just chmod -x) * The files are not libraries. * The files are standalone, not embedded in executable or library code. * Explicit permission is given by the owner to freely redistribute without restrictions (this permission must be included, in "writing", with the files in the packaging) * The files must be necessary for the functionality of open source code being included in Fedora. However, these packages will not be (in many cases) fully open source - while they're distributable, the licenses do not permit modification, reverse engineering, etc. So we want to make sure that these packages are easily queryable/findable. Proposal: 1) Firmware packages are given the Group: tag of System Environment/Kernel (unless we want to make up a new 'Firmware' tag) 2) The License tag for any firmware that disallows modification should be set to: "Redistributable firmware, no modification permitted" Comments? Note that there is other firmware (zd* USB devices, etc) that is under GPL and wouldn't need this license tag. Bill From jcm at redhat.com Tue Feb 13 02:55:53 2007 From: jcm at redhat.com (Jon Masters) Date: Mon, 12 Feb 2007 21:55:53 -0500 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213015257.GA12724@nostromo.devel.redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> Message-ID: <45D128B9.6080605@redhat.com> Bill Nottingham wrote: > 1) Firmware packages are given the Group: tag of System Environment/Kernel > (unless we want to make up a new 'Firmware' tag) I think it's reasonable to keep them in the Kernel group. > 2) The License tag for any firmware that disallows modification should > be set to: > > "Redistributable firmware, no modification permitted" Reasonable also. > Comments? Note that there is other firmware (zd* USB devices, etc) that > is under GPL and wouldn't need this license tag. I'm modifying upstream module-init-tools so we can additionally pick up firmware dependency information from modules using modinfo. This will allow us to build initrd images with the correct firmware files inside without including a bazillion optional firmware files for good measure. Actually, the upstream kernel has only 2 drivers currently using the MODULE_FIRMWARE tag needed so we'll want to encourage that. I told Jeremy the other day that I'm not so worried about ipw2200 because - to be honest - the idea of someone doing a bootpath iSCSI install over IPW makes me want to put my fingers in my ears and sing "la..la..la". But if you've got pet drivers that need "fixing" upstream, now's the time... Jon. From tibbs at math.uh.edu Tue Feb 13 03:25:07 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Feb 2007 21:25:07 -0600 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213015257.GA12724@nostromo.devel.redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> 1) Firmware packages are given the Group: tag of System BN> Environment/Kernel (unless we want to make up a new 'Firmware' BN> tag) I don't see why we wouldn't, given the nearly meaningless nature of Group at the moment. BN> The License tag for any firmware that disallows modification BN> should be set to: BN> "Redistributable firmware, no modification permitted" This seems reasonable. I'm not sure what point coming up with mnemonics for the actual license text would be when the above text succinctly sums up the end-user's rights. - J< From tcallawa at redhat.com Tue Feb 13 04:17:42 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 12 Feb 2007 22:17:42 -0600 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213015257.GA12724@nostromo.devel.redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> Message-ID: <1171340262.3085.15.camel@localhost.localdomain> On Mon, 2007-02-12 at 20:52 -0500, Bill Nottingham wrote: > Proposal: > > 1) Firmware packages are given the Group: tag of System Environment/Kernel > (unless we want to make up a new 'Firmware' tag) This is fine. As I've said before, we don't have any guidelines on setting Group properly. You can put "Giant Flying Alligator" in there for all I care. > 2) The License tag for any firmware that disallows modification should > be set to: > > "Redistributable firmware, no modification permitted" Seems right to me. ~spot From fedora at leemhuis.info Tue Feb 13 05:50:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 13 Feb 2007 06:50:17 +0100 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <45D128B9.6080605@redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <45D128B9.6080605@redhat.com> Message-ID: <45D15199.5050809@leemhuis.info> On 13.02.2007 03:55, Jon Masters wrote: > Bill Nottingham wrote: >> 1) Firmware packages are given the Group: tag of System Environment/Kernel >> (unless we want to make up a new 'Firmware' tag) > I think it's reasonable to keep them in the Kernel group. I disagree a small bit -- what if we for example start to ship Firmwares for Scanners? They depend on sane, and have nearly have nothing to do with the kernel... But it's probably a corner case we maybe should simply ignore... > [...] CU thl From rc040203 at freenet.de Tue Feb 13 06:15:17 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Feb 2007 07:15:17 +0100 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213015257.GA12724@nostromo.devel.redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> Message-ID: <1171347317.3622.117.camel@mccallum.corsepiu.local> On Mon, 2007-02-12 at 20:52 -0500, Bill Nottingham wrote: > We did some discussion at the board meeting last week about firmware images, > such as that used for ipw2200. The decision was made that we're OK with shipping > these firmware images based on the guidelines currently in the packaging > guidelines: > However, these packages will not be (in many cases) fully open source - while > they're distributable, the licenses do not permit modification, reverse > engineering, etc. So we want to make sure that these packages are easily > queryable/findable. > > Proposal: > > 1) Firmware packages are given the Group: tag of System Environment/Kernel > (unless we want to make up a new 'Firmware' tag) > 2) The License tag for any firmware that disallows modification should > be set to: > > "Redistributable firmware, no modification permitted" > > Comments? -1, for several reasons: 1. Generally speaking, the "no modifications" goes too far for my taste and is in conflict with Fedora's objectives. We should stick with "shipping/redistributing binaries (prebuilt binaries) is allowed, provided they are Open-Source (source-code available and modifiable)". 2. "no-mods-allowed" firmware is a controversial corner case wrt. licensing: Is a GPL'ed kernel-module using a "no-mods-allowed" firmware image, legal? "Under which kind of usages" is this legal and when not? 3. The definition of firmware in the FPG is weak. This had been discussed several times before, but IIRC, so far, nobody has been able to come up with a better one (Where does "firmware" end and other "general binary data" start, why should firmware be a special exception from the rules being applied to binaries elsewhere?) Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 13 10:31:06 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 13 Feb 2007 11:31:06 +0100 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213015257.GA12724@nostromo.devel.redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> Message-ID: <20070213113106.258e0390@python3.es.egwn.lan> Bill Nottingham wrote : > Proposal: > > 1) Firmware packages are given the Group: tag of System Environment/Kernel > (unless we want to make up a new 'Firmware' tag) > 2) The License tag for any firmware that disallows modification should > be set to: > > "Redistributable firmware, no modification permitted" > > Comments? Note that there is other firmware (zd* USB devices, etc) that > is under GPL and wouldn't need this license tag. Seems fine to me. Definitely a big win for end users, and not such a bad compromise overall, although I'd prefer hardware vendors putting firmwares back where they belong... in the hardware... for good, not on every driver load ;-p For the ipw2100 and ipw2200 firmwares, do updated written permissions still need to be obtained from Intel, or do the current ones match these new guidelines? (I'm asking because I always thought they both were fine, but they weren't) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.17 0.44 1.23 From mattdm at mattdm.org Tue Feb 13 14:08:31 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Feb 2007 09:08:31 -0500 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213015257.GA12724@nostromo.devel.redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> Message-ID: <20070213140831.GA31490@jadzia.bu.edu> On Mon, Feb 12, 2007 at 08:52:58PM -0500, Bill Nottingham wrote: > 1) Firmware packages are given the Group: tag of System Environment/Kernel > (unless we want to make up a new 'Firmware' tag) I'm for the new tag. Then we can start consolidating all the useless ones into simple classifications like this. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tibbs at math.uh.edu Tue Feb 13 15:35:14 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Feb 2007 09:35:14 -0600 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <1171347317.3622.117.camel@mccallum.corsepiu.local> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <1171347317.3622.117.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> 1. Generally speaking, the "no modifications" goes too far for my RC> taste and is in conflict with Fedora's objectives. This and the rest of the points you raise are off-topic for this discussion and beyond our scope as a committee; the board has already decided that this is not in conflict with Fedora's objectives, and is asking is for guidelines on what the specfiles should look like. If you want to have the type of discussion you're looking for, please take it to the board. - J< From Axel.Thimm at ATrpms.net Tue Feb 13 15:38:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Feb 2007 16:38:18 +0100 Subject: [Fedora-packaging] Re: Firmware packaging In-Reply-To: <45D15199.5050809@leemhuis.info> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <45D128B9.6080605@redhat.com> <45D15199.5050809@leemhuis.info> Message-ID: <20070213153818.GF8836@neu.nirvana> On Tue, Feb 13, 2007 at 06:50:17AM +0100, Thorsten Leemhuis wrote: > On 13.02.2007 03:55, Jon Masters wrote: > >Bill Nottingham wrote: > >>1) Firmware packages are given the Group: tag of System Environment/Kernel > >> (unless we want to make up a new 'Firmware' tag) > >I think it's reasonable to keep them in the Kernel group. > > I disagree a small bit -- what if we for example start to ship Firmwares > for Scanners? They depend on sane, and have nearly have nothing to do > with the kernel... Good catch. Perhaps the tag should be just a suggestion and the packager should be able to use something else. Although, which entry in /usr/share/doc/rpm-*/GROUPS might apply to a scanner firmware? Perhaps firmware should get their own Group tag different from /usr/share/doc/rpm-*/GROUPS. It would make them easy to filter out, too, which was one of Bill's topics. > But it's probably a corner case we maybe should simply ignore... No, I think you made a good example, better to lay down a proper layout now, than to reengineer it later. > > [...] > > CU > thl > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dlutter at redhat.com Tue Feb 13 16:51:20 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 13 Feb 2007 08:51:20 -0800 Subject: [Fedora-packaging] Missing tomorrow's meeting In-Reply-To: <200702122138.44480.ville.skytta@iki.fi> References: <200702122138.44480.ville.skytta@iki.fi> Message-ID: <1171385480.20097.6.camel@localhost.localdomain> On Mon, 2007-02-12 at 21:38 +0200, Ville Skytt? wrote: > Looks like I'll be missing tomorrow's packaging committee meeting. I will have to miss both this week's and next week's meeting. Sorry about that. David From fnasser at redhat.com Tue Feb 13 17:00:01 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Tue, 13 Feb 2007 12:00:01 -0500 Subject: [Fedora-packaging] Re: Wrong buildroot ... In-Reply-To: <200702121057.40586.jkeating@redhat.com> References: <20070210135347.GD21848@neu.nirvana> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <200702121057.40586.jkeating@redhat.com> Message-ID: <45D1EE91.4090805@redhat.com> Jesse Keating wrote: > On Monday 12 February 2007 10:52, Joe Orton wrote: >> I completely agree with that. Unless the buildroot is picked by >> mkdtemp() you can't really *guarantee* avoidance of conflicts. If you >> want a guarantee then rpmbuild should be fixed to ignore BuildRoot and >> use mkdtemp() instead. Standardising an inadequate workaround and >> having packagers go through fixing N hundred spec files to match seems >> like a waste of time. > > +1 > > We have the spec stubs that have an acceptable buildroot tag for new packages, > I don't see much value in harping on existing packages for the BuildRoot. > So, what is the current procedure. We have 150 Java packages that would need to have the -%(%{__id_u} -n) appended. Can the reviewers waive that bit until we have a final (and better) solution to our buildroot? Or perhaps we could make it a mass automated rebuild to replace all BuildRoot: in all packages? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 13 16:59:41 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 13 Feb 2007 17:59:41 +0100 Subject: [Fedora-packaging] Re: Wrong buildroot ... In-Reply-To: <45D1EE91.4090805@redhat.com> References: <20070210135347.GD21848@neu.nirvana> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <200702121057.40586.jkeating@redhat.com> <45D1EE91.4090805@redhat.com> Message-ID: <20070213175941.065986c7@python3.es.egwn.lan> Fernando Nasser wrote : > So, what is the current procedure. We have 150 Java packages that would > need to have the -%(%{__id_u} -n) appended. We have a currently _suggested_ value. Just point it out politely to anyone telling you "you must change it". Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.73 0.58 0.55 From notting at redhat.com Tue Feb 13 17:01:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 Feb 2007 12:01:09 -0500 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213113106.258e0390@python3.es.egwn.lan> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <20070213113106.258e0390@python3.es.egwn.lan> Message-ID: <20070213170109.GB526@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > For the ipw2100 and ipw2200 firmwares, do updated written > permissions still need to be obtained from Intel, or do the current > ones match these new guidelines? (I'm asking because I always thought > they both were fine, but they weren't) The ipw2100/2200 licenses, as written, were deemed OK. (Yes, this is a change.) Bill From jcm at redhat.com Tue Feb 13 17:20:31 2007 From: jcm at redhat.com (Jon Masters) Date: Tue, 13 Feb 2007 12:20:31 -0500 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213113106.258e0390@python3.es.egwn.lan> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <20070213113106.258e0390@python3.es.egwn.lan> Message-ID: <45D1F35F.6070005@redhat.com> Matthias Saou wrote: > Seems fine to me. Definitely a big win for end users, and not such a > bad compromise overall, although I'd prefer hardware vendors putting > firmwares back where they belong... in the hardware... for good, not on > every driver load ;-p Actually, logically these folks are doing the right thing. Having firmware *in* the hardware works when you've got years to design the hardware and then have guaranteed sales for years after that. But, these days, hardware manufacturers need to make rapid changes and fix bugs/add new features after release. Not allowing them to do that is like saying "you can never release an update for F7, no matter what breaks" - it's not realistic :-) So, actually, we should be working to make using loadable firmware easier - because it's going to become much *much* more common. Jon. From Matt_Domsch at dell.com Tue Feb 13 17:27:00 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 13 Feb 2007 11:27:00 -0600 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <45D1F35F.6070005@redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <20070213113106.258e0390@python3.es.egwn.lan> <45D1F35F.6070005@redhat.com> Message-ID: <20070213172700.GA11385@lists.us.dell.com> On Tue, Feb 13, 2007 at 12:20:31PM -0500, Jon Masters wrote: > Actually, logically these folks are doing the right thing. > > Having firmware *in* the hardware works when you've got years to design > the hardware and then have guaranteed sales for years after that. But, > these days, hardware manufacturers need to make rapid changes and fix > bugs/add new features after release. Not allowing them to do that is > like saying "you can never release an update for F7, no matter what > breaks" - it's not realistic :-) > > So, actually, we should be working to make using loadable firmware > easier - because it's going to become much *much* more common. in other words, from a manufacturer's perspective, disk space is less expensive than flash, because the customer pays for the disk, where you pay for the flash. :-) -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jcm at redhat.com Tue Feb 13 17:32:26 2007 From: jcm at redhat.com (Jon Masters) Date: Tue, 13 Feb 2007 12:32:26 -0500 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213172700.GA11385@lists.us.dell.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <20070213113106.258e0390@python3.es.egwn.lan> <45D1F35F.6070005@redhat.com> <20070213172700.GA11385@lists.us.dell.com> Message-ID: <45D1F62A.2020106@redhat.com> Matt Domsch wrote: > in other words, from a manufacturer's perspective, disk space is less > expensive than flash, because the customer pays for the disk, where > you pay for the flash. :-) Yup. There are exceptions to this of course. I used to build NMR (MRI) systems running Linux on custom FPGA platforms we "flashed" via a SystemAce (a magic device from Xilinx - a CompactFlash reader device to Linux, a hardware programmer at other times) that we could use to say "hey, let's redefine the entire hardware platform, replace the firmware, and the kernel and the userland" in one operation...takes...guts. Jon. From dominik at greysector.net Tue Feb 13 18:53:24 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 13 Feb 2007 19:53:24 +0100 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213170109.GB526@nostromo.devel.redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <20070213113106.258e0390@python3.es.egwn.lan> <20070213170109.GB526@nostromo.devel.redhat.com> Message-ID: <20070213185324.GA14233@ryvius.pekin.waw.pl> On Tuesday, 13 February 2007 at 18:01, Bill Nottingham wrote: > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > For the ipw2100 and ipw2200 firmwares, do updated written > > permissions still need to be obtained from Intel, or do the current > > ones match these new guidelines? (I'm asking because I always thought > > they both were fine, but they weren't) > > The ipw2100/2200 licenses, as written, were deemed OK. (Yes, this > is a change.) If that is correct, why are #217350 and #217351 still blocking FE-Legal? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From notting at redhat.com Tue Feb 13 18:53:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 Feb 2007 13:53:18 -0500 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213185324.GA14233@ryvius.pekin.waw.pl> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <20070213113106.258e0390@python3.es.egwn.lan> <20070213170109.GB526@nostromo.devel.redhat.com> <20070213185324.GA14233@ryvius.pekin.waw.pl> Message-ID: <20070213185318.GA5485@nostromo.devel.redhat.com> Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: > > The ipw2100/2200 licenses, as written, were deemed OK. (Yes, this > > is a change.) > > If that is correct, why are #217350 and #217351 still blocking FE-Legal? 'Cos I'm a slowpoke? Feel free to remove the block. Bill From dominik at greysector.net Tue Feb 13 19:05:49 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 13 Feb 2007 20:05:49 +0100 Subject: [Fedora-packaging] Firmware packaging In-Reply-To: <20070213185318.GA5485@nostromo.devel.redhat.com> References: <20070213015257.GA12724@nostromo.devel.redhat.com> <20070213113106.258e0390@python3.es.egwn.lan> <20070213170109.GB526@nostromo.devel.redhat.com> <20070213185324.GA14233@ryvius.pekin.waw.pl> <20070213185318.GA5485@nostromo.devel.redhat.com> Message-ID: <20070213190549.GB14233@ryvius.pekin.waw.pl> On Tuesday, 13 February 2007 at 19:53, Bill Nottingham wrote: > Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: > > > The ipw2100/2200 licenses, as written, were deemed OK. (Yes, this > > > is a change.) > > > > If that is correct, why are #217350 and #217351 still blocking FE-Legal? > > 'Cos I'm a slowpoke? Feel free to remove the block. Why, thank you! Removing now. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From ville.skytta at iki.fi Tue Feb 13 22:04:39 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 14 Feb 2007 00:04:39 +0200 Subject: [Fedora-packaging] BuildRoot and mktemp -d In-Reply-To: <20070213214047.5458.25830@fpserv.fedoraproject.org> References: <20070213214047.5458.25830@fpserv.fedoraproject.org> Message-ID: <200702140004.39542.ville.skytta@iki.fi> On Tuesday 13 February 2007, you wrote: > > The following page has been changed by TomCallaway: > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo [...] > + ||ratify ||New Required Buildroot||[wiki:Self:TomCallaway > spot]||2007-02-13||Change required buildroot for new packages to %(mktemp > -d %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) (old packages/core > merge packages using old buildroot are grandfathered)|| Using mktemp -d in specfiles' BuildRoot means that quite a few stray temp dirs will start to appear in %{_tmppath}. For example "rpm -q --specfile foo.spec" and "rpmbuild -bs foo.spec" create them, and nothing cleans them up (no, tmpwatch doesn't count) - we probably don't want that. One way to avoid it is mktemp -ud, but it's more racy than plain -d. I think -ud would be a better choice nevertheless. From rdieter at math.unl.edu Tue Feb 13 23:00:32 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Feb 2007 17:00:32 -0600 Subject: [Fedora-packaging] BuildRoot and mktemp -d In-Reply-To: <200702140004.39542.ville.skytta@iki.fi> References: <20070213214047.5458.25830@fpserv.fedoraproject.org> <200702140004.39542.ville.skytta@iki.fi> Message-ID: <45D24310.5050902@math.unl.edu> Ville Skytt? wrote: > Using mktemp -d in specfiles' BuildRoot means that quite a few stray temp dirs > will start to appear in %{_tmppath}. For example "rpm -q --specfile > foo.spec" and "rpmbuild -bs foo.spec" create them, and nothing cleans them up > (no, tmpwatch doesn't count) - we probably don't want that. Isn't that what %clean is for? > One way to avoid it is mktemp -ud, but it's more racy than plain -d. I doubt this would work. -- Rex From jcm at redhat.com Tue Feb 13 23:03:15 2007 From: jcm at redhat.com (Jon Masters) Date: Tue, 13 Feb 2007 18:03:15 -0500 Subject: [Fedora-packaging] BuildRoot and mktemp -d In-Reply-To: <45D24310.5050902@math.unl.edu> References: <20070213214047.5458.25830@fpserv.fedoraproject.org> <200702140004.39542.ville.skytta@iki.fi> <45D24310.5050902@math.unl.edu> Message-ID: <45D243B3.9030400@redhat.com> Rex Dieter wrote: > Ville Skytt? wrote: > >> Using mktemp -d in specfiles' BuildRoot means that quite a few stray temp dirs >> will start to appear in %{_tmppath}. For example "rpm -q --specfile >> foo.spec" and "rpmbuild -bs foo.spec" create them, and nothing cleans them up >> (no, tmpwatch doesn't count) - we probably don't want that. > > Isn't that what %clean is for? That's what I use it for... Jon. From tibbs at math.uh.edu Tue Feb 13 23:06:24 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Feb 2007 17:06:24 -0600 Subject: [Fedora-packaging] BuildRoot and mktemp -d In-Reply-To: <45D24310.5050902@math.unl.edu> References: <20070213214047.5458.25830@fpserv.fedoraproject.org> <200702140004.39542.ville.skytta@iki.fi> <45D24310.5050902@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> Isn't that what %clean is for? Not really; the problem here is that even parsing of the spec will call mktemp and thus create some random directory. This kind of thing needs to be in deeply coded into rpm, and until then we just need to stick with the single approved buildroot as we have now. - J< From ville.skytta at iki.fi Tue Feb 13 23:37:31 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 14 Feb 2007 01:37:31 +0200 Subject: [Fedora-packaging] BuildRoot and mktemp -d In-Reply-To: <45D24310.5050902@math.unl.edu> References: <20070213214047.5458.25830@fpserv.fedoraproject.org> <200702140004.39542.ville.skytta@iki.fi> <45D24310.5050902@math.unl.edu> Message-ID: <200702140137.31687.ville.skytta@iki.fi> On Wednesday 14 February 2007, Rex Dieter wrote: > Ville Skytt? wrote: > > Using mktemp -d in specfiles' BuildRoot means that quite a few stray temp > > dirs will start to appear in %{_tmppath}. For example "rpm -q --specfile > > foo.spec" and "rpmbuild -bs foo.spec" create them, and nothing cleans > > them up (no, tmpwatch doesn't count) - we probably don't want that. > > Isn't that what %clean is for? %clean is not run with eg. "rpm -q --specfile" nor "rpm -bs". And it's not even possible to pass --clean to the former, and passing it to the latter does not clean up the created temp dir either - it doesn't run the actual %clean scriptlet from the specfile. > > One way to avoid it is mktemp -ud, but it's more racy than plain -d. > > I doubt this would work. Why not? Seems to work fine here in the few tests I've done. From Axel.Thimm at ATrpms.net Tue Feb 13 23:47:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Feb 2007 00:47:36 +0100 Subject: [Fedora-packaging] Re: BuildRoot and mktemp -d In-Reply-To: <200702140004.39542.ville.skytta@iki.fi> References: <20070213214047.5458.25830@fpserv.fedoraproject.org> <200702140004.39542.ville.skytta@iki.fi> Message-ID: <20070213234736.GA8935@neu.nirvana> On Wed, Feb 14, 2007 at 12:04:39AM +0200, Ville Skytt? wrote: > On Tuesday 13 February 2007, you wrote: > > > > The following page has been changed by TomCallaway: > > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo > [...] > > + ||ratify ||New Required Buildroot||[wiki:Self:TomCallaway > > spot]||2007-02-13||Change required buildroot for new packages to %(mktemp > > -d %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) (old packages/core > > merge packages using old buildroot are grandfathered)|| > > Using mktemp -d in specfiles' BuildRoot means that quite a few stray temp dirs > will start to appear in %{_tmppath}. For example "rpm -q --specfile > foo.spec" and "rpmbuild -bs foo.spec" create them, and nothing cleans them up > (no, tmpwatch doesn't count) - we probably don't want that. > > One way to avoid it is mktemp -ud, but it's more racy than plain -d. I > think -ud would be a better choice nevertheless. Good catch! +1 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Feb 14 02:19:11 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Feb 2007 20:19:11 -0600 Subject: [Fedora-packaging] BuildRoot and mktemp -d In-Reply-To: <200702140137.31687.ville.skytta@iki.fi> References: <20070213214047.5458.25830@fpserv.fedoraproject.org> <200702140004.39542.ville.skytta@iki.fi> <45D24310.5050902@math.unl.edu> <200702140137.31687.ville.skytta@iki.fi> Message-ID: <45D2719F.3090407@math.unl.edu> Ville Skytt? wrote: > On Wednesday 14 February 2007, Rex Dieter wrote: >>> One way to avoid it is mktemp -ud, but it's more racy than plain -d. >> I doubt this would work. > > Why not? Seems to work fine here in the few tests I've done. Fair 'nuf, as long as it works. (: -- Rex From steve at silug.org Wed Feb 14 21:22:40 2007 From: steve at silug.org (Steven Pritchard) Date: Wed, 14 Feb 2007 15:22:40 -0600 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> Message-ID: <20070214212240.GA2699@osiris.silug.org> There's nothing like coming into a discussion *really* late... (Sorry, $dayjob has been hell recently.) On Tue, Feb 06, 2007 at 01:18:18PM -0600, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom 'spot' Callaway writes: > TC> My concern is that if we make a perl-devel here, some things that > TC> had perl as an unstated BuildRequires will suddenly stop building > TC> until they add perl-devel. > > If so, this needs to happen rather soon. Can we get buy-in from Robin > and perhaps a couple of mass-packagers like Steve Pritchard? My only concern is that some of our BuildRequires will need to be on perl-foo-devel instead of perl(foo), and I may or may not be able to figure that out automatically in cpanspec. If I were going to look for things to be concerned with in the perl package, I'd probably worry about noarch packages being in /usr/lib/perl5 instead of /usr/share/perl5. :-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From a.badger at gmail.com Wed Feb 14 21:45:25 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 14 Feb 2007 13:45:25 -0800 Subject: [Fedora-packaging] Source Url Guidelines Message-ID: <1171489525.4472.45.camel@localhost.localdomain> Hey all, Here's my first draft of a SourceURL guideline. This tries to encapsulate current practices but a few new things had to be added related to SRPMs where no upstream source exists. This draft will probably need some touching up as I whipped it up pretty quickly but hopefully it captures the spirit of what we're trying to achieve. The latest version is available at: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl ''' = Referencing Source = One of the design goals of rpm is to cleanly separate upstream source from vendor modifications. For the Fedora packager, this means that sources used to build a package should be the vanilla sources available from upstream. To help reviewers and QA scripts verify this, the packager needs to indicate where a reviewer can find the source that was used to make the rpm. The most common case is where upstream distributes source as a tar.gz, tar.bz2 or zip archive that we can download from an upstream website. In these cases you must use a full URL to the package in the SourceX: line. For example:: {{{ Source0: http://download.sourceforge.net/%{name}/%{name}-%{version}.tar.gz Source0: http://ftp.gnome.org/pub/GNOME/sources/gnome-common/2.12/gnome-common-2.12.0.tar.bz2 }}} There are several cases where upstream is not providing the source to you in an upstream tarball. In these cases you must document how to generate the tarball used in the rpm either through a spec file comment or a script included as a separate SourceX:. Here are some specific examples: == Using Revision Control == In some cases you may want to pull sources from upstream's revision control system because there have been many changes since the last release and you think that a tarball that you generate from there will more accurately show how the package relates to upstream's development. Here's how you can use a comment to show where the source came from:: {{{ # The source for this package was pulled from upstream's cvs. Use the # following commands to generate the tarball: # svn export -r 250 http://www.foo.org/svn/foo/trunk foo-20070221 # tar -czvf foo-20070221.tar.gz foo-20070221 Source0: foo-20070221.tar.gz }}} When pulling from revision control, please remember to use a Name-version-release compatible with the release guidelines. In particular, check the section on Naming Snapshots. == When Upstream uses Prohibited Code == Some upstream packages include patents or trademarks that we are not allowed to ship even as source code. In these cases you have to modify the source tarball to remove this code before you even upload it to the build system. Here's an example of using a script to document how you went from the upstream tarball to the one included in the package: From the spec: {{{ Source0: libfoo-1.0-nopatents.tar.gz # libfoo contains patented code that we cannot ship. Therefore we use # this script to remove the patented code before shipping it. # Download the upstream tarball and invoke this script while in the # tarball's directory: # ./generate-tarball.sh 1.0 Source1: generate-tarball.sh }}} generate-tarball.sh: {{{ #!/bin/sh VERSION=$1 tar -xzvf libfoo-$VERSION.tar.gz rm libfoo-$VERSION/src/patentedcodec.c sed -i -e 's/patentedcodec.c//' libfoo-$VERSION/src/Makefile tar -czvf libfoo-$VERSION-nopatents.tar.gz }}} == We are Upstream == For some packages where we are the upstream authors, for instance, the system-config-* tools, the source rpm that we distribute is the canonical source of the files. There is no public revision control system or publically released tarball for these programs so there is no tarball to list. Add a comment like the following to the spec: {{{ # This is a Red Hat maintained package which is specific to # our distribution. Thus the source is only available from # within this srpm. Source0: system-config-foo-1.0.tar.gz }}} ''' -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Wed Feb 14 21:57:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Feb 2007 22:57:26 +0100 Subject: [Fedora-packaging] Re: Source Url Guidelines In-Reply-To: <1171489525.4472.45.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> Message-ID: <20070214215726.GA8296@neu.nirvana> On Wed, Feb 14, 2007 at 01:45:25PM -0800, Toshio Kuratomi wrote: > Hey all, > > Here's my first draft of a SourceURL guideline. This tries to > encapsulate current practices but a few new things had to be added > related to SRPMs where no upstream source exists. This draft will > probably need some touching up as I whipped it up pretty quickly but > hopefully it captures the spirit of what we're trying to achieve. Looks OK. But since we're commenting on source origin could somewhere a kind request ("SHOULD") to (srpm-)package upstream sources/patches with original timestamps where possible be embedded? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Wed Feb 14 22:06:28 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 14 Feb 2007 23:06:28 +0100 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <1171489525.4472.45.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> Message-ID: <20070214220628.GC2815@free.fr> On Wed, Feb 14, 2007 at 01:45:25PM -0800, Toshio Kuratomi wrote: > Hey all, > > Here's my first draft of a SourceURL guideline. This tries to Overall it looks good to me. I see 2 other situations that may be worth mentionning: 1. the tarball was found on a regular site, kept in a srpm, or a disk drive, a mirror, the lookaside cache or whatever place, and afterwards the initial download source disappeared. It is similar than the "we are upstream" case but not exactly the same. The fedora maintainer should maintain the package in that case, that is fix bugs and so on but without being upstream, only in the fedora cvs (with patches). These packages may be on the road to retirement, but not necessarily, especially when these are old, stable, and little packages. 2. sometimes upstream don't have a properly versioned tarball. In that case it should be asked to upstream to version properly, but it is not always possible. I think that the rule for those cases should be to provide the full url in a comment, and add a version to the tarball based, for example on the timestamp of the file (but not necessarily). For example: # Source1 is only used for documentation # renamed to tex4ht-all-YYYYMMDD.zip - based on last timestamp in # directory Source1: tex4ht-all-20050228.zip # unversioned upstream source, downloaded with wget -N #Source1 http://www.cse.ohio-state.edu/~gurari/TeX4ht/tex4ht-all.zip -- Pat From a.badger at gmail.com Wed Feb 14 22:37:51 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 14 Feb 2007 14:37:51 -0800 Subject: [Fedora-packaging] Re: Source Url Guidelines In-Reply-To: <1171489525.4472.45.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> Message-ID: <1171492671.4472.51.camel@localhost.localdomain> On Wed, 2007-02-14 at 13:45 -0800, Toshio Kuratomi wrote: > ''' > = Referencing Source = > > One of the design goals of rpm is to cleanly separate upstream > source from vendor modifications. For the Fedora packager, this > means that sources used to build a package should be the vanilla > sources available from upstream. To help reviewers and QA scripts > verify this, the packager needs to indicate where a reviewer can find > the source that was used to make the rpm. caillon had this to say in the bug which spawned this: ''' Looks good from the brief glance I took, but I strongly feel this whole thing should be a "good practises" recommendation and not a requirement. If you're trying to prevent against "bad" RPMs, well you're not going to do that if there are exceptions... Even for a good SRPM, someone could simply fork an open source project, not have a repo other than the SRPM, and distribute whatever code they want that way in extras, theoretically. This has no bearing on the actual packaging or quality of RPMs. It's only redeeming quality is that it might potentially help with automated verification of upstream sources, but that does not exist right now and that potential benefit should be enough to convince most packagers to do this. There's simply no reason to make it a hard requirement IMO other than because it's always been that way (which is no real reason). ''' -------------- 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 a.badger at gmail.com Wed Feb 14 22:40:06 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 14 Feb 2007 14:40:06 -0800 Subject: [Fedora-packaging] Re: Source Url Guidelines In-Reply-To: <20070214215726.GA8296@neu.nirvana> References: <1171489525.4472.45.camel@localhost.localdomain> <20070214215726.GA8296@neu.nirvana> Message-ID: <1171492806.4472.54.camel@localhost.localdomain> On Wed, 2007-02-14 at 22:57 +0100, Axel Thimm wrote: > On Wed, Feb 14, 2007 at 01:45:25PM -0800, Toshio Kuratomi wrote: > > Hey all, > > > > Here's my first draft of a SourceURL guideline. This tries to > > encapsulate current practices but a few new things had to be added > > related to SRPMs where no upstream source exists. This draft will > > probably need some touching up as I whipped it up pretty quickly but > > hopefully it captures the spirit of what we're trying to achieve. > > Looks OK. But since we're commenting on source origin could somewhere > a kind request ("SHOULD") to (srpm-)package upstream sources/patches > with original timestamps where possible be embedded? That sounds like a good best practice. It sounds like a separate item the way things are currently phrased. Do you have some wording to fit it in, or do you just want to throw it in a separate recommendation. -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 cweyl at alumni.drew.edu Wed Feb 14 21:53:44 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 14 Feb 2007 13:53:44 -0800 Subject: [Fedora-packaging] Re: Draft: Perl packages don't need -devel for .h headers In-Reply-To: <1170796906.19237.4.camel@localhost.localdomain> References: <1170606056.9171.6.camel@localhost.localdomain> <200702060958.27589.ville.skytta@iki.fi> <20070206121325.GB17490@neu.nirvana> <1170787911.12347.5.camel@localhost.localdomain> <20070206193140.GA29087@neu.nirvana> <1170790551.12347.11.camel@localhost.localdomain> <20070206205436.GA31898@neu.nirvana> <1170796906.19237.4.camel@localhost.localdomain> Message-ID: <7dd7ab490702141353r39730767wafe2cc6d17325aaf@mail.gmail.com> On 2/6/07, Tom 'spot' Callaway wrote: > > OK, being pedantic: > > - I can't make perl pass review unless I make a perl-devel > OR > - Perl needs an exception in the guidelines so it can pass review. > > Which one would people prefer for FC-7? At this point, I'm rather > indifferent. :) I'd suggest just codifying existing practice... It has worked quite well so far, and there doesn't seem to be a pressing _technical_ reason to change it. (a la a .pc files potential to generate additional deps in the package.) Steve's point of "we can't just br: perl(Foo) anymore" is well taken, and would seem to be a compelling reason to leave things as is. We would no longer be able to just say "this requires perl(foo) to build" in all cases. -Chris -- Chris Weyl Ex astris, scientia From ville.skytta at iki.fi Wed Feb 14 22:59:59 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 15 Feb 2007 00:59:59 +0200 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <1171489525.4472.45.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> Message-ID: <200702150059.59885.ville.skytta@iki.fi> On Wednesday 14 February 2007, Toshio Kuratomi wrote: > Source0: http://download.sourceforge.net/%{name}/%{name}-%{version}.tar.gz Tiny detail: s/download./downloads./ - the former has been shaky for quite a while now, but I've never seen the latter fail. From opensource at till.name Wed Feb 14 23:02:34 2007 From: opensource at till.name (Till Maas) Date: Thu, 15 Feb 2007 00:02:34 +0100 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <1171489525.4472.45.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> Message-ID: <200702150002.42644.opensource@till.name> On Mittwoch 14 Februar 2007, Toshio Kuratomi wrote: > The latest version is available at: > http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl I made some minor corrections, e.g. using example.com instead of foo.org and links to the mentioned NamingGuidelines sections. I also added a section about the correct sourceforge.net URL, afaik it is not documented anywhere else, and a section why using %{version} in SourceX: is good. I hope this is ok. :-) I noticed, that in the section titled "When Upstream uses Prohibited Code" there is not mentioned, that the URL of the original tarball must be included in the generate-tarball.sh script, or, that it also must download it, e.g. curl http://www.example.com/files/libfoo-$VERSION.tar.gz | xzvf libfoo-$VERSION.tar.gz Also, one could argue, that the script must always be named "generate-tarball.sh" (or whatever name is appropriate) because then QA-scripts could automatically use them. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Wed Feb 14 23:06:36 2007 From: opensource at till.name (Till Maas) Date: Thu, 15 Feb 2007 00:06:36 +0100 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <200702150059.59885.ville.skytta@iki.fi> References: <1171489525.4472.45.camel@localhost.localdomain> <200702150059.59885.ville.skytta@iki.fi> Message-ID: <200702150006.36577.opensource@till.name> On Mittwoch 14 Februar 2007, Ville Skytt? wrote: > On Wednesday 14 February 2007, Toshio Kuratomi wrote: > > Source0: > > http://download.sourceforge.net/%{name}/%{name}-%{version}.tar.gz > > Tiny detail: s/download./downloads./ - the former has been shaky for quite > a while now, but I've never seen the latter fail. I just remembered, that in another thread I read prdownloads.sourceforge.net as the recommended sourceforge download source. But I do not know, which works better or if there are any differences. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmz at pobox.com Wed Feb 14 23:30:43 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 14 Feb 2007 18:30:43 -0500 Subject: [Fedora-packaging] Re: Source Url Guidelines In-Reply-To: <1171492806.4472.54.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> <20070214215726.GA8296@neu.nirvana> <1171492806.4472.54.camel@localhost.localdomain> Message-ID: <20070214233043.GM23466@psilocybe.teonanacatl.org> Toshio Kuratomi wrote: > On Wed, 2007-02-14 at 22:57 +0100, Axel Thimm wrote: >> Looks OK. But since we're commenting on source origin could >> somewhere a kind request ("SHOULD") to (srpm-)package upstream >> sources/patches with original timestamps where possible be >> embedded? > > That sounds like a good best practice. It sounds like a separate > item the way things are currently phrased. Do you have some wording > to fit it in, or do you just want to throw it in a separate > recommendation. Is this section from the packaging guidelines what you're after? http://fedoraproject.org/wiki/Packaging/Guidelines#head-0239576e441f9ef53d175c4aec8c12868dffb5ab "When downloading sources, patches etc, consider using a client that preserves the upstream timestamps. For example wget -N or curl -R. To make the change global for wget, add this to your ~/.wgetrc: timestamping = on, and for curl, add to your ~/.curlrc: -R." -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== To have a successful relationship, I must learn to make it look like I'm giving as much as I'm getting. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Feb 14 23:33:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Feb 2007 00:33:42 +0100 Subject: [Fedora-packaging] Re: Source Url Guidelines In-Reply-To: <1171492806.4472.54.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> <20070214215726.GA8296@neu.nirvana> <1171492806.4472.54.camel@localhost.localdomain> Message-ID: <20070214233342.GC8296@neu.nirvana> On Wed, Feb 14, 2007 at 02:40:06PM -0800, Toshio Kuratomi wrote: > On Wed, 2007-02-14 at 22:57 +0100, Axel Thimm wrote: > > On Wed, Feb 14, 2007 at 01:45:25PM -0800, Toshio Kuratomi wrote: > > > Hey all, > > > > > > Here's my first draft of a SourceURL guideline. This tries to > > > encapsulate current practices but a few new things had to be added > > > related to SRPMs where no upstream source exists. This draft will > > > probably need some touching up as I whipped it up pretty quickly but > > > hopefully it captures the spirit of what we're trying to achieve. > > > > Looks OK. But since we're commenting on source origin could somewhere > > a kind request ("SHOULD") to (srpm-)package upstream sources/patches > > with original timestamps where possible be embedded? > > That sounds like a good best practice. It sounds like a separate item > the way things are currently phrased. Do you have some wording to fit > it in, or do you just want to throw it in a separate recommendation. since it's a weak suggestion and only a subsentence it would be nice to interweave in the part that discusses unmodified upstream sources. I agree the topic "URL" is not exactly describing timestamps :) Maybe the general topic could be abstracted to "Dealing with sources and patches" or similar, so it wouldn't be completely out of the water. As a phrasing I would suggest "Whenever possible try to maintain timestamps of sources or patches". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Feb 14 23:37:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Feb 2007 00:37:04 +0100 Subject: [Fedora-packaging] Re: Source Url Guidelines In-Reply-To: <20070214233043.GM23466@psilocybe.teonanacatl.org> References: <1171489525.4472.45.camel@localhost.localdomain> <20070214215726.GA8296@neu.nirvana> <1171492806.4472.54.camel@localhost.localdomain> <20070214233043.GM23466@psilocybe.teonanacatl.org> Message-ID: <20070214233704.GD8296@neu.nirvana> On Wed, Feb 14, 2007 at 06:30:43PM -0500, Todd Zullinger wrote: > Toshio Kuratomi wrote: > > On Wed, 2007-02-14 at 22:57 +0100, Axel Thimm wrote: > >> Looks OK. But since we're commenting on source origin could > >> somewhere a kind request ("SHOULD") to (srpm-)package upstream > >> sources/patches with original timestamps where possible be > >> embedded? > > > > That sounds like a good best practice. It sounds like a separate > > item the way things are currently phrased. Do you have some wording > > to fit it in, or do you just want to throw it in a separate > > recommendation. > > Is this section from the packaging guidelines what you're after? > > http://fedoraproject.org/wiki/Packaging/Guidelines#head-0239576e441f9ef53d175c4aec8c12868dffb5ab > > "When downloading sources, patches etc, consider using a client that > preserves the upstream timestamps. For example wget -N or curl -R. To > make the change global for wget, add this to your ~/.wgetrc: > timestamping = on, and for curl, add to your ~/.curlrc: -R." Indeed, thanks for pointing this out, Todd! Toshio, forget my request then, unless you want to consolidate or rearange parts of the guidelines talking about handling upstream sources/patches. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wart at kobold.org Thu Feb 15 00:06:43 2007 From: wart at kobold.org (Michael Thomas) Date: Wed, 14 Feb 2007 16:06:43 -0800 Subject: [Fedora-packaging] Tcl packaging guidelines proposal Message-ID: <45D3A413.8040606@kobold.org> I sent this proposal to f-m-l about a week ago to gather comments, and there were no serious disagreements with the proposal which have not yet been addressed (thanks to Tibbs and Toshio for their feedback). Basically, I want to establish a set of guidelines for packaging Tcl extensions, as we already have guidelines for other popular scripting languages. In addition to making Tcl packages more consistent with each other, it will also help work toward fixing my pet-peeve bug (bz #226893) http://fedoraproject.org/wiki/PackagingDrafts/Tcl Please let me know if I need to do anything to help get these draft guidelines adopted. Thanks, --Wart From ville.skytta at iki.fi Thu Feb 15 07:17:50 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 15 Feb 2007 09:17:50 +0200 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <200702150006.36577.opensource@till.name> References: <1171489525.4472.45.camel@localhost.localdomain> <200702150059.59885.ville.skytta@iki.fi> <200702150006.36577.opensource@till.name> Message-ID: <200702150917.50946.ville.skytta@iki.fi> On Thursday 15 February 2007, Till Maas wrote: > On Mittwoch 14 Februar 2007, Ville Skytt? wrote: > > On Wednesday 14 February 2007, Toshio Kuratomi wrote: > > > Source0: > > > http://download.sourceforge.net/%{name}/%{name}-%{version}.tar.gz > > > > Tiny detail: s/download./downloads./ - the former has been shaky for > > quite a while now, but I've never seen the latter fail. > > I just remembered, that in another thread I read > prdownloads.sourceforge.net as the recommended sourceforge download source. > But I do not know, which works better or if there are any differences. prdownloads tarball URLs aren't suitable, they're not directly downloadable. From opensource at till.name Thu Feb 15 09:52:10 2007 From: opensource at till.name (Till Maas) Date: Thu, 15 Feb 2007 10:52:10 +0100 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <200702150917.50946.ville.skytta@iki.fi> References: <1171489525.4472.45.camel@localhost.localdomain> <200702150006.36577.opensource@till.name> <200702150917.50946.ville.skytta@iki.fi> Message-ID: <200702151052.21907.opensource@till.name> On Donnerstag 15 Februar 2007, Ville Skytt? wrote: > prdownloads tarball URLs aren't suitable, they're not directly > downloadable. When I try to download http://prdownloads.sourceforge.net/optipng/optipng-0.5.4.tar.gz, it works, but it is a redirection to http://downloads.sourceforge.net/optipng/optipng-0.5.4.tar.gz, so I guess downloads is the better choice. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Feb 15 12:46:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Feb 2007 06:46:55 -0600 Subject: [Fedora-packaging] Re: Source Url Guidelines In-Reply-To: <1171492671.4472.51.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> <1171492671.4472.51.camel@localhost.localdomain> Message-ID: <45D4563F.8060700@math.unl.edu> Toshio Kuratomi wrote: > On Wed, 2007-02-14 at 13:45 -0800, Toshio Kuratomi wrote: >> ''' >> = Referencing Source = >> >> One of the design goals of rpm is to cleanly separate upstream >> source from vendor modifications. For the Fedora packager, this >> means that sources used to build a package should be the vanilla >> sources available from upstream. To help reviewers and QA scripts >> verify this, the packager needs to indicate where a reviewer can find >> the source that was used to make the rpm. > > caillon had this to say in the bug which spawned this: > ''' > Looks good from the brief glance I took, but I strongly feel this whole > thing should be a "good practises" recommendation and not a requirement. Or, I don't know, something like "Packaging Guidelines"? (: I like your draft, good work. -- Rex From notting at redhat.com Thu Feb 15 16:48:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 11:48:09 -0500 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <1171489525.4472.45.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> Message-ID: <20070215164809.GA11994@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > {{{ > # The source for this package was pulled from upstream's cvs. Use the > # following commands to generate the tarball: > # svn export -r 250 http://www.foo.org/svn/foo/trunk foo-20070221 > # tar -czvf foo-20070221.tar.gz foo-20070221 > Source0: foo-20070221.tar.gz > }}} Might want to match your SCMs in the example. :) As for the whole thing, I'd argue that they should be suggests-guidelines, not required-guidelines. Bill From tcallawa at redhat.com Thu Feb 15 17:42:03 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 15 Feb 2007 11:42:03 -0600 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <20070215164809.GA11994@nostromo.devel.redhat.com> References: <1171489525.4472.45.camel@localhost.localdomain> <20070215164809.GA11994@nostromo.devel.redhat.com> Message-ID: <1171561323.3740.26.camel@localhost.localdomain> On Thu, 2007-02-15 at 11:48 -0500, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: > > {{{ > > # The source for this package was pulled from upstream's cvs. Use the > > # following commands to generate the tarball: > > # svn export -r 250 http://www.foo.org/svn/foo/trunk foo-20070221 > > # tar -czvf foo-20070221.tar.gz foo-20070221 > > Source0: foo-20070221.tar.gz > > }}} > > Might want to match your SCMs in the example. :) > > As for the whole thing, I'd argue that they should be suggests-guidelines, > not required-guidelines. Why? Is there any reason why we don't want this information in the package? ~spot From notting at redhat.com Thu Feb 15 17:48:53 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 12:48:53 -0500 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <1171561323.3740.26.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> <20070215164809.GA11994@nostromo.devel.redhat.com> <1171561323.3740.26.camel@localhost.localdomain> Message-ID: <20070215174853.GB12697@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > > As for the whole thing, I'd argue that they should be suggests-guidelines, > > not required-guidelines. > > Why? Is there any reason why we don't want this information in the > package? I dunno - it just feels like something that should be 'please do this', not 'package rejected because you didn't do this.' Bill From rdieter at math.unl.edu Thu Feb 15 17:55:35 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Feb 2007 11:55:35 -0600 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <20070215174853.GB12697@nostromo.devel.redhat.com> References: <1171489525.4472.45.camel@localhost.localdomain> <20070215164809.GA11994@nostromo.devel.redhat.com> <1171561323.3740.26.camel@localhost.localdomain> <20070215174853.GB12697@nostromo.devel.redhat.com> Message-ID: <45D49E97.30104@math.unl.edu> Bill Nottingham wrote: > Tom 'spot' Callaway (tcallawa at redhat.com) said: >>> As for the whole thing, I'd argue that they should be suggests-guidelines, >>> not required-guidelines. >> Why? Is there any reason why we don't want this information in the >> package? > > I dunno - it just feels like something that should be 'please do this', > not 'package rejected because you didn't do this.' If folks want to be able to reliably verify upstream sources, this kind of stuff is pretty much required. I can't think of very many legit cases otherwise. -- Rex From tcallawa at redhat.com Thu Feb 15 17:55:50 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 15 Feb 2007 11:55:50 -0600 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <20070215174853.GB12697@nostromo.devel.redhat.com> References: <1171489525.4472.45.camel@localhost.localdomain> <20070215164809.GA11994@nostromo.devel.redhat.com> <1171561323.3740.26.camel@localhost.localdomain> <20070215174853.GB12697@nostromo.devel.redhat.com> Message-ID: <1171562150.3740.28.camel@localhost.localdomain> On Thu, 2007-02-15 at 12:48 -0500, Bill Nottingham wrote: > Tom 'spot' Callaway (tcallawa at redhat.com) said: > > > As for the whole thing, I'd argue that they should be suggests-guidelines, > > > not required-guidelines. > > > > Why? Is there any reason why we don't want this information in the > > package? > > I dunno - it just feels like something that should be 'please do this', > not 'package rejected because you didn't do this.' Sorry. If you don't eat your meat, you cannot have any pudding. HOW CAN YOU HAVE ANY PUDDING IF YOU DON'T EAT YOUR MEAT?!? ~spot From notting at redhat.com Thu Feb 15 17:56:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 12:56:43 -0500 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <1171562150.3740.28.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> <20070215164809.GA11994@nostromo.devel.redhat.com> <1171561323.3740.26.camel@localhost.localdomain> <20070215174853.GB12697@nostromo.devel.redhat.com> <1171562150.3740.28.camel@localhost.localdomain> Message-ID: <20070215175643.GA12916@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > Sorry. If you don't eat your meat, you cannot have any pudding. > > HOW CAN YOU HAVE ANY PUDDING IF YOU DON'T EAT YOUR MEAT?!? OK, just a little pinprick... More seriously, if we're trying to encode this sort of metadata, it would be nice to have a real format/mechanism, rather than 'a defined comment syntax.' Bill From tcallawa at redhat.com Thu Feb 15 18:01:48 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 15 Feb 2007 12:01:48 -0600 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <20070215175643.GA12916@nostromo.devel.redhat.com> References: <1171489525.4472.45.camel@localhost.localdomain> <20070215164809.GA11994@nostromo.devel.redhat.com> <1171561323.3740.26.camel@localhost.localdomain> <20070215174853.GB12697@nostromo.devel.redhat.com> <1171562150.3740.28.camel@localhost.localdomain> <20070215175643.GA12916@nostromo.devel.redhat.com> Message-ID: <1171562508.3740.30.camel@localhost.localdomain> On Thu, 2007-02-15 at 12:56 -0500, Bill Nottingham wrote: > Tom 'spot' Callaway (tcallawa at redhat.com) said: > > Sorry. If you don't eat your meat, you cannot have any pudding. > > > > HOW CAN YOU HAVE ANY PUDDING IF YOU DON'T EAT YOUR MEAT?!? > > OK, just a little pinprick... > > More seriously, if we're trying to encode this sort of metadata, it > would be nice to have a real format/mechanism, rather than 'a defined > comment syntax.' OK. Suggestions on format welcome. :) ~spot From opensource at till.name Thu Feb 15 18:11:45 2007 From: opensource at till.name (Till Maas) Date: Thu, 15 Feb 2007 19:11:45 +0100 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <1171562508.3740.30.camel@localhost.localdomain> References: <1171489525.4472.45.camel@localhost.localdomain> <20070215175643.GA12916@nostromo.devel.redhat.com> <1171562508.3740.30.camel@localhost.localdomain> Message-ID: <200702151911.52113.opensource@till.name> On Donnerstag 15 Februar 2007, Tom 'spot' Callaway wrote: > OK. Suggestions on format welcome. :) I suggest a shell script with the name "generate-tarball.sh" that generates the desired tarball and is included as SourceX:. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu Feb 15 18:19:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 Feb 2007 19:19:30 +0100 Subject: [Fedora-packaging] Source Url Guidelines In-Reply-To: <200702151911.52113.opensource@till.name> References: <1171489525.4472.45.camel@localhost.localdomain> <20070215175643.GA12916@nostromo.devel.redhat.com> <1171562508.3740.30.camel@localhost.localdomain> <200702151911.52113.opensource@till.name> Message-ID: <20070215181930.GD2797@free.fr> On Thu, Feb 15, 2007 at 07:11:45PM +0100, Till Maas wrote: > On Donnerstag 15 Februar 2007, Tom 'spot' Callaway wrote: > > > OK. Suggestions on format welcome. :) > > I suggest a shell script with the name "generate-tarball.sh" that generates > the desired tarball and is included as SourceX:. There should be the package name prepended. Something like foo-generate-tarball.sh -- Pat From pmatilai at laiskiainen.org Fri Feb 16 08:11:00 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 16 Feb 2007 10:11:00 +0200 (EET) Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: <20070212175059.31dee292@python3.es.egwn.lan> References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> Message-ID: On Mon, 12 Feb 2007, Matthias Saou wrote: > Rex Dieter wrote : > >> Joe Orton wrote: >> >>> Standardising an inadequate workaround and >>> having packagers go through fixing N hundred spec files to match seems >>> like a waste of time. >> >> *sigh*. One justification the FPC had used for mandating a standard >> buildroot was to avoid the waste of time associated with endless debates on >> mailing lists and package reviews. So much for that plan. (: > > The "standard" buildroot plan is a good plan, as long as the goal > involves ripping it out from all spec files once and for all (i.e. have > a sane default set for rpmbuild). > > I keep repeating this, sorry, but am I the only one who'd like to see > all useless and repetitive stuff taken out of spec files? > - BuildRoot > - The "-q" to %setup > - BuildRoot cleanup when %install and %clean start > - %defattr(-,root,root,-) or %defattr(-,root,root,0755) Heh, actually this last one item (cause of no-end stupid mistakes) has actually already been fixed in RPM while we weren't looking. In /usr/share/doc/rpm-*/CHANGES: 4.3.3 -> 4.4: ... - silently add default %defattr(-,root,root) for all packages. ... And that indeed seems to be the case. One check-item less in the package review procedure. - Panu - From ville.skytta at iki.fi Fri Feb 16 15:28:14 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 16 Feb 2007 17:28:14 +0200 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: References: <20070210135347.GD21848@neu.nirvana> <20070212175059.31dee292@python3.es.egwn.lan> Message-ID: <200702161728.14179.ville.skytta@iki.fi> On Friday 16 February 2007, Panu Matilainen wrote: > > Heh, actually this last one item (cause of no-end stupid mistakes) has > actually already been fixed in RPM while we weren't looking. In > /usr/share/doc/rpm-*/CHANGES: > > 4.3.3 -> 4.4: > ... > - silently add default %defattr(-,root,root) for all packages. > ... > > And that indeed seems to be the case. One check-item less in the package > review procedure. Not for EL-4's rpm 4.3.3. Enough reason to continue requiring it IMO. From jkeating at redhat.com Fri Feb 16 23:00:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Feb 2007 18:00:40 -0500 Subject: [Fedora-packaging] Draft: Init Scripts Message-ID: <200702161800.40666.jkeating@redhat.com> After repeated (heated) discussions over init scripts, I wanted to guideify my thoughts (and others) on this. Can we have some discussion over this draft and vote at next meeting? http://fedoraproject.org/wiki/PackagingDrafts/InitScripts -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Feb 16 23:25:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 17 Feb 2007 00:25:05 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <200702161800.40666.jkeating@redhat.com> References: <200702161800.40666.jkeating@redhat.com> Message-ID: <20070216232505.GB2195@neu.nirvana> On Fri, Feb 16, 2007 at 06:00:40PM -0500, Jesse Keating wrote: > After repeated (heated) discussions over init scripts, I wanted to guideify my > thoughts (and others) on this. Can we have some discussion over this draft > and vote at next meeting? > > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts > I would be more stringent than that and require packages to transit into non-%config init files. E.g. to make a temporary exception and explicitely say that this exception will be lifted later. The migration should be done in the new package's %prein script. Also a side-note: The text could be read as "all config information must be under /etc/sysconfig", maybe this needs to be clarified to mean any config bits, not already dealt with in the package's native config space under /etc? I had a couple of times where people argued that everything pertaining to configuration needs to be placed under /etc/sysconfig, so the policy could be misread by them. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Sat Feb 17 00:20:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Feb 2007 18:20:12 -0600 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <200702161800.40666.jkeating@redhat.com> References: <200702161800.40666.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Can we have some discussion over this draft and vote at next JK> meeting? I can get behind this, but I think that we make the set of exceptions as narrow as possible. It should be possible to actually list out all of the packages which violate this, limit the exceptions to those and then work to shrink that list over time. So perhaps nuke the two sentences starting with "A valid exception", and add a section "Grandfathered packages" so there is no question as to whether a new package can be excepted from the guideline. I do anticipate that it simply might not be possible for some of these grandfathered packages to ever switch over, but at least if they're explicitly listed the question won't keep coming up about whether they violate guideline. - J< From tibbs at math.uh.edu Sat Feb 17 00:23:32 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Feb 2007 18:23:32 -0600 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <200702161800.40666.jkeating@redhat.com> References: <200702161800.40666.jkeating@redhat.com> Message-ID: Here's another possibly related question I found while grepping through core package specs: Do we care about use of %{_initrddir} versus %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other? - J< From tibbs at math.uh.edu Sat Feb 17 00:29:05 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Feb 2007 18:29:05 -0600 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: References: <200702161800.40666.jkeating@redhat.com> Message-ID: >>>>> "JLT" == Jason L Tibbitts writes: JLT> It should be possible to actually list out all of the packages JLT> which violate this, limit the exceptions to those and then work JLT> to shrink that list over time. And here's a list of core packages, generated by grep -l '^%config.*init' */devel/*spec|awk -F/ '{print $1}' in a complete core checkout and edited for one false positive (e2fsprogs): am-utils anacron apmd arptables_jf at autofs bind bootparamd Canna ccs cups cyrus-sasl dbus device-mapper-multipath dhcp dovecot fence firstboot freeradius FreeWnn GFS ghostscript glibc gpm gulm hal howl hplip hpoj httpd hwcrypto initscripts iptables iputils ipvsadm irda-utils iscsi iscsi-initiator-utils isdn4k-utils kdenetwork kexec-tools krb5 kudzu lm_sensors LPRng mars-nwe net-snmp NetworkManager nfs-utils openhpi OpenIPMI policycoreutils policy portmap privoxy quagga radvd rarpd rgmanager routed rusers rwall rwho selinux-policy selinux-policy-strict selinux-policy-targeted sendmail spamassassin squid tog-pegasus tomcat tux vixie-cron XFree86 xinetd xinitrc xorg-x11 ypbind ypserv yum zebra Also note that a few packages use %config(noreplace). - J< From rdieter at math.unl.edu Sat Feb 17 01:15:22 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Feb 2007 19:15:22 -0600 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: References: <200702161800.40666.jkeating@redhat.com> Message-ID: Jason L Tibbitts III wrote: > Here's another possibly related question I found while grepping > through core package specs: > > Do we care about use of %{_initrddir} versus > %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other? imo, the former, since that is precisely what it exists for. -- Rex From Axel.Thimm at ATrpms.net Sat Feb 17 03:48:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 17 Feb 2007 04:48:51 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: References: <200702161800.40666.jkeating@redhat.com> Message-ID: <20070217034851.GB13491@neu.nirvana> On Fri, Feb 16, 2007 at 07:15:22PM -0600, Rex Dieter wrote: > Jason L Tibbitts III wrote: > > Here's another possibly related question I found while grepping > > through core package specs: > > > > Do we care about use of %{_initrddir} versus > > %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other? > > imo, the former, since that is precisely what it exists for. While at it could we have the typo in the macro fixed? We can keep the old one indefinitely around for compatibility's sake. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Feb 17 11:14:27 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 17 Feb 2007 12:14:27 +0100 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <200702161800.40666.jkeating@redhat.com> (Jesse Keating's message of "Fri, 16 Feb 2007 18:00:40 -0500") References: <200702161800.40666.jkeating@redhat.com> Message-ID: <87y7mx6nos.fsf@kosh.bigo.ensc.de> jkeating at redhat.com (Jesse Keating) writes: > After repeated (heated) discussions over init scripts, I wanted to guideify my > thoughts (and others) on this. Can we have some discussion over this draft > and vote at next meeting? > > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts no; %config is ok (I do not want to lose changes to /etc files silently). But I agree that there is no need to mark them as %config(noreplace). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From jkeating at redhat.com Sat Feb 17 14:51:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 Feb 2007 09:51:34 -0500 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <87y7mx6nos.fsf@kosh.bigo.ensc.de> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> Message-ID: <200702170951.34896.jkeating@redhat.com> On Saturday 17 February 2007 06:14, Enrico Scholz wrote: > no; %config is ok (I do not want to lose changes to /etc files silently). > But I agree that there is no need to mark them as %config(noreplace). And you feel OK about other scripts on your system silently losing changes because they're outside of /etc? init script placement in /etc always seemed funny to me, these are scripts to be executed, not files to be configured. Just because they live in /etc shouldn't give them any special treatment over any other script that may live in /usr I'd prefer if init scripts didn't live in /etc at all, or were symlinked into /etc for compat purposes, but that's a larger change than I want to push right now. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Sun Feb 18 08:25:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 18 Feb 2007 09:25:58 +0100 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <200702170951.34896.jkeating@redhat.com> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> Message-ID: <1171787159.20765.290.camel@mccallum.corsepiu.local> On Sat, 2007-02-17 at 09:51 -0500, Jesse Keating wrote: > On Saturday 17 February 2007 06:14, Enrico Scholz wrote: > > no; %config is ok (I do not want to lose changes to /etc files silently). > > But I agree that there is no need to mark them as %config(noreplace). > > And you feel OK about other scripts on your system silently losing changes > because they're outside of /etc? init script placement in /etc always seemed > funny to me, these are scripts to be executed, not files to be configured. init scripts live in /etc, because the traditional view on them and their traditional usage is customizable/configurable scripts. This concept is older than Linux, sysv-init, /etc/sysconfig, the LSB and the FHS. I.e. editing init scripts had been part of standard proceedures to run a system. Since introduction of /etc/sysconfig this role has gradually lost importance, but even nowadays, there still can exist situations where resorting to it is hardly avoidable. Ralf From herrold at owlriver.com Tue Feb 13 22:39:07 2007 From: herrold at owlriver.com (R P Herrold) Date: Tue, 13 Feb 2007 17:39:07 -0500 (EST) Subject: [Fedora-packaging] BuildRoot and mktemp -d In-Reply-To: <200702140004.39542.ville.skytta@iki.fi> References: <20070213214047.5458.25830@fpserv.fedoraproject.org> <200702140004.39542.ville.skytta@iki.fi> Message-ID: On Wed, 14 Feb 2007, Ville Skytt? wrote: > Using mktemp -d in specfiles' BuildRoot means that quite a > few stray temp dirs will start to appear in %{_tmppath}. > For example "rpm -q --specfile foo.spec" and "rpmbuild -bs > foo.spec" create them, and nothing cleans them up (no, > tmpwatch doesn't count) - we probably don't want that. umm, if it is to be so done, passing mktemp a subordinate 'template' directory pattern of -p %{_tmppath}rpm-build/{...whatever nameing per build instance} may be helpful in confining this to a known search sub-tree in %{_tmppath}; I know I go poking in the RPM-BUILD temp dirs on occasion when builds are being diagnosed, but also like to clean house confidently when space gets tight. -- Russ Herrold From jkeating at redhat.com Sun Feb 18 13:20:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 18 Feb 2007 08:20:39 -0500 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <1171787159.20765.290.camel@mccallum.corsepiu.local> References: <200702161800.40666.jkeating@redhat.com> <200702170951.34896.jkeating@redhat.com> <1171787159.20765.290.camel@mccallum.corsepiu.local> Message-ID: <200702180820.42282.jkeating@redhat.com> On Sunday 18 February 2007 03:25, Ralf Corsepius wrote: > Since introduction of /etc/sysconfig this role has gradually lost > importance, but even nowadays, there still can exist situations where > resorting to it is hardly avoidable. Is the split between config in the init script and config in a proper /etc/sysconfig file something we wish to continue, perhaps even encourage by marking such files as %config? At the very least it bothers rpmlint, but more it bothers me to have an inconsistent design for how services should be configured. We don't protect any other script which may be edited by the admin... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Feb 19 16:26:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 11:26:19 -0500 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070216232505.GB2195@neu.nirvana> References: <200702161800.40666.jkeating@redhat.com> <20070216232505.GB2195@neu.nirvana> Message-ID: <20070219162619.GD26885@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > I would be more stringent than that and require packages to transit > into non-%config init files. E.g. to make a temporary exception and > explicitely say that this exception will be lifted later. The > migration should be done in the new package's %prein script. Why would changing from %config to non-%config require changes in the scriplets at all? Bill From notting at redhat.com Mon Feb 19 16:27:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 11:27:16 -0500 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: References: <200702161800.40666.jkeating@redhat.com> Message-ID: <20070219162716.GE26885@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > Here's another possibly related question I found while grepping > through core package specs: > > Do we care about use of %{_initrddir} versus > %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other? Techncially, someone who redefines %{_sysconfdir} for init scripts is just asking for pain; among other things, the path is compiled in to chkconfig and various other scripts. Bill From Axel.Thimm at ATrpms.net Mon Feb 19 16:32:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Feb 2007 17:32:37 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070219162619.GD26885@nostromo.devel.redhat.com> References: <200702161800.40666.jkeating@redhat.com> <20070216232505.GB2195@neu.nirvana> <20070219162619.GD26885@nostromo.devel.redhat.com> Message-ID: <20070219163237.GA14989@neu.nirvana> On Mon, Feb 19, 2007 at 11:26:19AM -0500, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > I would be more stringent than that and require packages to transit > > into non-%config init files. E.g. to make a temporary exception and > > explicitely say that this exception will be lifted later. The > > migration should be done in the new package's %prein script. > > Why would changing from %config to non-%config require > changes in the scriplets at all? The above referred to the following part of the draft: "A valid exception to this rule would be existing packages where configuration is still done via the init file. In this case, the init file could be marked as %config to preserve a users configuration upon upgrade, hopefully so that the user can migrate said configuration to a new /etc/sysconfig/ config file." Does it make more sense now? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Feb 19 16:33:21 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 11:33:21 -0500 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070219163237.GA14989@neu.nirvana> References: <200702161800.40666.jkeating@redhat.com> <20070216232505.GB2195@neu.nirvana> <20070219162619.GD26885@nostromo.devel.redhat.com> <20070219163237.GA14989@neu.nirvana> Message-ID: <20070219163321.GF26885@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > Why would changing from %config to non-%config require > > changes in the scriplets at all? > > The above referred to the following part of the draft: > > "A valid exception to this rule would be existing packages where > configuration is still done via the init file. In this case, the init > file could be marked as %config to preserve a users configuration upon > upgrade, hopefully so that the user can migrate said configuration to > a new /etc/sysconfig/ config file." > > Does it make more sense now? No. If it changes from %config (modified) to non-%config, it would still get moved on upgrade, unless I'm forgetting the state machine. Bill From Axel.Thimm at ATrpms.net Mon Feb 19 17:33:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Feb 2007 18:33:02 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070219163321.GF26885@nostromo.devel.redhat.com> References: <200702161800.40666.jkeating@redhat.com> <20070216232505.GB2195@neu.nirvana> <20070219162619.GD26885@nostromo.devel.redhat.com> <20070219163237.GA14989@neu.nirvana> <20070219163321.GF26885@nostromo.devel.redhat.com> Message-ID: <20070219173302.GB14989@neu.nirvana> On Mon, Feb 19, 2007 at 11:33:21AM -0500, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > Why would changing from %config to non-%config require > > > changes in the scriplets at all? > > > > The above referred to the following part of the draft: > > > > "A valid exception to this rule would be existing packages where > > configuration is still done via the init file. In this case, the init > > file could be marked as %config to preserve a users configuration upon > > upgrade, hopefully so that the user can migrate said configuration to > > a new /etc/sysconfig/ config file." > > > > Does it make more sense now? > > No. If it changes from %config (modified) to non-%config, it would > still get moved on upgrade, unless I'm forgetting the state machine. That's why I suggested %prein -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Feb 19 17:33:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 12:33:54 -0500 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070219173302.GB14989@neu.nirvana> References: <200702161800.40666.jkeating@redhat.com> <20070216232505.GB2195@neu.nirvana> <20070219162619.GD26885@nostromo.devel.redhat.com> <20070219163237.GA14989@neu.nirvana> <20070219163321.GF26885@nostromo.devel.redhat.com> <20070219173302.GB14989@neu.nirvana> Message-ID: <20070219173354.GA31919@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > No. If it changes from %config (modified) to non-%config, it would > > still get moved on upgrade, unless I'm forgetting the state machine. > > That's why I suggested %prein I think we're talking past each other. AFAIK, it will get successfully saved as .rpmsave *without* any %pre magic. Bill From Axel.Thimm at ATrpms.net Mon Feb 19 17:47:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Feb 2007 18:47:55 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070219173354.GA31919@nostromo.devel.redhat.com> References: <200702161800.40666.jkeating@redhat.com> <20070216232505.GB2195@neu.nirvana> <20070219162619.GD26885@nostromo.devel.redhat.com> <20070219163237.GA14989@neu.nirvana> <20070219163321.GF26885@nostromo.devel.redhat.com> <20070219173302.GB14989@neu.nirvana> <20070219173354.GA31919@nostromo.devel.redhat.com> Message-ID: <20070219174755.GC14989@neu.nirvana> On Mon, Feb 19, 2007 at 12:33:54PM -0500, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > No. If it changes from %config (modified) to non-%config, it would > > > still get moved on upgrade, unless I'm forgetting the state machine. > > > > That's why I suggested %prein > > I think we're talking past each other. AFAIK, it will get successfully > saved as .rpmsave *without* any %pre magic. Indeed, my issue is to have the upgrade do something with the existing configuration in some scripts, not simply archive away the user's config into an .rpmsave file. The upgrade would break on the user and leave him fiddle out where his config has vanished to. And the cleanest way is for the package to extract the config out of the script and place it to the new canonical place during the upgrade. Hopefully the config will be in some extractable form. Note: We are talking only about package that don't only tag init files as %config, but indeed misuse them to store config information. Not that I know of any to present an example, but Jesse said there are some. This has nothing to do with the tons of packages marking init files as %config even though all config has been moved to sysconfig ages ago. Perhaps it become clearer if we find such a package and discuss what we'd like an upgrade to perform. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Mon Feb 19 18:05:39 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Feb 2007 19:05:39 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070219174755.GC14989@neu.nirvana> References: <200702161800.40666.jkeating@redhat.com> <20070216232505.GB2195@neu.nirvana> <20070219162619.GD26885@nostromo.devel.redhat.com> <20070219163237.GA14989@neu.nirvana> <20070219163321.GF26885@nostromo.devel.redhat.com> <20070219173302.GB14989@neu.nirvana> <20070219173354.GA31919@nostromo.devel.redhat.com> <20070219174755.GC14989@neu.nirvana> Message-ID: <1171908339.3280.23.camel@mccallum.corsepiu.local> On Mon, 2007-02-19 at 18:47 +0100, Axel Thimm wrote: > On Mon, Feb 19, 2007 at 12:33:54PM -0500, Bill Nottingham wrote: > > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > > > No. If it changes from %config (modified) to non-%config, it would > > > > still get moved on upgrade, unless I'm forgetting the state machine. > > > > > > That's why I suggested %prein > > > > I think we're talking past each other. AFAIK, it will get successfully > > saved as .rpmsave *without* any %pre magic. > > Indeed, my issue is to have the upgrade do something with the existing > configuration in some scripts, not simply archive away the user's > config into an .rpmsave file. The upgrade would break on the user and > leave him fiddle out where his config has vanished to. IMO, the logic should be: Do not replace /etc/init.d scripts a user had altered, only replace those without changes. => %config(noreplace) Normal users will not notice anything, users customizing init-scripts will have to "know what they are doing". > Perhaps it become clearer if we find such a package and discuss what > we'd like an upgrade to perform. E.g. customizing/fixing init priorities, buggy init-scripts with local bug-fixes applied, ... Theoretically, such things should not exist, but things happen ... Ralf From notting at redhat.com Mon Feb 19 18:10:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 13:10:18 -0500 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <1171908339.3280.23.camel@mccallum.corsepiu.local> References: <200702161800.40666.jkeating@redhat.com> <20070216232505.GB2195@neu.nirvana> <20070219162619.GD26885@nostromo.devel.redhat.com> <20070219163237.GA14989@neu.nirvana> <20070219163321.GF26885@nostromo.devel.redhat.com> <20070219173302.GB14989@neu.nirvana> <20070219173354.GA31919@nostromo.devel.redhat.com> <20070219174755.GC14989@neu.nirvana> <1171908339.3280.23.camel@mccallum.corsepiu.local> Message-ID: <20070219181018.GA32529@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > > Perhaps it become clearer if we find such a package and discuss what > > we'd like an upgrade to perform. > > E.g. customizing/fixing init priorities, There are overrides for this in rawhide. See the latest chkconfig package. > buggy init-scripts with local > bug-fixes applied, ... That could apply to *anything*, whether it be /usr/bin/find or /etc/init.d/sshd. Special-casing something just because it happens to be shell seems misguided. Bill From rc040203 at freenet.de Tue Feb 20 03:31:45 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Feb 2007 04:31:45 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070219181018.GA32529@nostromo.devel.redhat.com> References: <200702161800.40666.jkeating@redhat.com> <20070216232505.GB2195@neu.nirvana> <20070219162619.GD26885@nostromo.devel.redhat.com> <20070219163237.GA14989@neu.nirvana> <20070219163321.GF26885@nostromo.devel.redhat.com> <20070219173302.GB14989@neu.nirvana> <20070219173354.GA31919@nostromo.devel.redhat.com> <20070219174755.GC14989@neu.nirvana> <1171908339.3280.23.camel@mccallum.corsepiu.local> <20070219181018.GA32529@nostromo.devel.redhat.com> Message-ID: <1171942306.3280.36.camel@mccallum.corsepiu.local> On Mon, 2007-02-19 at 13:10 -0500, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > > Perhaps it become clearer if we find such a package and discuss what > > > we'd like an upgrade to perform. > > > > E.g. customizing/fixing init priorities, > > There are overrides for this in rawhide. See the latest chkconfig package. > > > buggy init-scripts with local > > bug-fixes applied, ... > > That could apply to *anything*, whether it be /usr/bin/find or > /etc/init.d/sshd. Yes, ... if you want to drive this to extremes, one could argue this to be a missing feature in rpm. > Special-casing something just because it happens > to be shell seems misguided. Whether this is special casing depends on your view "/etc ... /etc/ == configuration" == no special casing. Apart of this, a system is not unlikely not to boot up anymore or at least not to work properly anymore when an update reverts a local bug fix/customization. Ralf From Axel.Thimm at ATrpms.net Tue Feb 20 10:21:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Feb 2007 11:21:11 +0100 Subject: [Fedora-packaging] Stopping the mandatory buildroot insanity Message-ID: <20070220102111.GA30283@neu.nirvana> So we voted on a new *mandatory* buildroot. By now people saw that the previous *mandatory* buildroot entered the guidelines and started blocking new packages requiring the old *mandatory* buildroot. I don't know what fesco did last week on ratifying or not the new buildroot, and either way people will think differently on any single buildroot. Perhaps buildroots are the most unimportant piece of s**t with the most polarized parties. Now who's idea was it to have a *MANDATORY* buildroot at all? Most of the FPC are fed up and have often stated that the buildroot guidelines should be simple "If it works, have it". Plain and simple: Request for voting on dropping the *mandatory* from the guidelines and explicitely cast it into a *suggestion* +1 The first other five positive voters get a free beer when I meet them (we never said that committee members could not be bribed, or do we need a guideline for that? ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Feb 20 13:04:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 08:04:35 -0500 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <1171942306.3280.36.camel@mccallum.corsepiu.local> References: <200702161800.40666.jkeating@redhat.com> <20070219181018.GA32529@nostromo.devel.redhat.com> <1171942306.3280.36.camel@mccallum.corsepiu.local> Message-ID: <200702200804.38984.jkeating@redhat.com> On Monday 19 February 2007 22:31, Ralf Corsepius wrote: > Apart of this, a system is not unlikely not to boot up anymore or at > least not to work properly anymore when an update reverts a local bug > fix/customization. Alternatively it may not boot or work properly if your old init script is kept in place while a newer init script with different launch options is needed for the new binary. This is why configuration must be split from launch script. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Feb 20 13:33:40 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Feb 2007 14:33:40 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <200702200804.38984.jkeating@redhat.com> References: <200702161800.40666.jkeating@redhat.com> <20070219181018.GA32529@nostromo.devel.redhat.com> <1171942306.3280.36.camel@mccallum.corsepiu.local> <200702200804.38984.jkeating@redhat.com> Message-ID: <1171978420.23237.19.camel@mccallum.corsepiu.local> On Tue, 2007-02-20 at 08:04 -0500, Jesse Keating wrote: > On Monday 19 February 2007 22:31, Ralf Corsepius wrote: > > Apart of this, a system is not unlikely not to boot up anymore or at > > least not to work properly anymore when an update reverts a local bug > > fix/customization. > > Alternatively it may not boot or work properly if your old init script is kept > in place while a newer init script with different launch options is needed > for the new binary. In theory yes, in practice in most cases things are the other way round: An old script continues to work unless things been deliberately changed in incompatible ways. Or conversely: An old script is likely to degrade, if things are being changed deliberately. > This is why configuration must be split from launch > script. I don't see this - Separate config files only restrict the user to what a vendor wants him to restrict to and what the vendor has taken into consideration. It takes away the freedom of customization and takes away the freedom extending init-scripts to what the vendor has not considered. Why would this be useful? The user has chosen to customize, so it's the user's responsibility to handle this situation - If you take away %config you are simply erasing, killing his "carefully handcrafted solution" to a real world problem. - I can't find this helpful. Ralf From jkeating at redhat.com Tue Feb 20 13:43:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 08:43:29 -0500 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <1171978420.23237.19.camel@mccallum.corsepiu.local> References: <200702161800.40666.jkeating@redhat.com> <200702200804.38984.jkeating@redhat.com> <1171978420.23237.19.camel@mccallum.corsepiu.local> Message-ID: <200702200843.30039.jkeating@redhat.com> On Tuesday 20 February 2007 08:33, Ralf Corsepius wrote: > I don't see this - Separate config files only restrict the user to what > a vendor wants him to restrict to and what the vendor has taken into > consideration. > > It takes away the freedom of customization and takes away the freedom > extending init-scripts to what the vendor has not considered. > > Why would this be useful? The user has chosen to customize, so it's the > user's responsibility to handle this situation - If you take away > %config you are simply erasing, killing his "carefully handcrafted > solution" to a real world problem. - I can't find this helpful. And I can't see any difference between this an any other script on the file system. So unless we extend it so that all editable scripts become %config, I don't see this special casing being helpful, instead its promoting upstreams to continue to use init scripts for configuration. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Feb 20 14:07:03 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Feb 2007 15:07:03 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <200702200843.30039.jkeating@redhat.com> References: <200702161800.40666.jkeating@redhat.com> <200702200804.38984.jkeating@redhat.com> <1171978420.23237.19.camel@mccallum.corsepiu.local> <200702200843.30039.jkeating@redhat.com> Message-ID: <1171980424.23237.35.camel@mccallum.corsepiu.local> On Tue, 2007-02-20 at 08:43 -0500, Jesse Keating wrote: > On Tuesday 20 February 2007 08:33, Ralf Corsepius wrote: > > I don't see this - Separate config files only restrict the user to what > > a vendor wants him to restrict to and what the vendor has taken into > > consideration. > > > > It takes away the freedom of customization and takes away the freedom > > extending init-scripts to what the vendor has not considered. > > > > Why would this be useful? The user has chosen to customize, so it's the > > user's responsibility to handle this situation - If you take away > > %config you are simply erasing, killing his "carefully handcrafted > > solution" to a real world problem. - I can't find this helpful. > > And I can't see any difference between this an any other script on the file > system. As I wrote before, if you want to take this too extremes, yes the same consideration can also be applied to any script in the system and one could go so far to state rpm not allowing this to be a bug. The difference between an arbitrary script and /etc/init.d scripts is their history of init.d and their role. Nobody expects arbitrary scripts to customizable. Instead, people resort to other means, such as repackaging rpms, adding custom scripts to /usr/local (exactly this is what /usr/local is for) or elsewhere (/opt, ~/bin, /root/bin). Such workaround aren't easily applicable to init.d scripts. > So unless we extend it so that all editable scripts become %config, > I don't see this special casing being helpful, instead its promoting > upstreams to continue to use init scripts for configuration. Let me ask differently: What is the problem you are trying to solve? I don't see any. Files under /etc/* are defined as config files, therefore /etc/init.d are config-files by definition. This matches their history, matches tradition, matches common practice, is helpful to users and makes no difference to a vendor, and also makes no difference to the vast majority of users. To the remaining minority of users it makes a substantial difference. It at least forces them to redesign their "customizations" because any update will trash their customizations. Ralf From jkeating at redhat.com Tue Feb 20 14:29:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 09:29:27 -0500 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <1171980424.23237.35.camel@mccallum.corsepiu.local> References: <200702161800.40666.jkeating@redhat.com> <200702200843.30039.jkeating@redhat.com> <1171980424.23237.35.camel@mccallum.corsepiu.local> Message-ID: <200702200929.27671.jkeating@redhat.com> On Tuesday 20 February 2007 09:07, Ralf Corsepius wrote: > Let me ask differently: What is the problem you are trying to solve? > I don't see any. Inconsistency between configuration in an init file and in /etc/sysconfig/, executable config files, inability to get new init scripts in place (blocked by .rpmnew), just to name a few. > Files under /etc/* are defined as config files, therefore /etc/init.d > are config-files by definition. This matches their history, matches > tradition, matches common practice, is helpful to users and makes no > difference to a vendor, and also makes no difference to the vast > majority of users. Yes, history is a hard thing to change. However unless we want to end up like Solaris, we need to be open to refinement to our system, and such refinement could include pressure to stop configuration in an init script (which REALLY should live outside of etc, but alas...) and instead push configuration to /etc/sysconfig/ > To the remaining minority of users it makes a substantial difference. It > at least forces them to redesign their "customizations" because any > update will trash their customizations. Yep, sucks to be them, but we use Fedora to push new technology and new ways of thinking. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Tue Feb 20 15:20:40 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Feb 2007 09:20:40 -0600 Subject: [Fedora-packaging] Stopping the mandatory buildroot insanity In-Reply-To: <20070220102111.GA30283@neu.nirvana> References: <20070220102111.GA30283@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> Request for voting on dropping the *mandatory* from the guidelines AT> and explicitely cast it into a *suggestion* -1 - J< From a.badger at gmail.com Tue Feb 20 16:57:48 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 20 Feb 2007 08:57:48 -0800 Subject: [Fedora-packaging] Stopping the mandatory buildroot insanity In-Reply-To: References: <20070220102111.GA30283@neu.nirvana> Message-ID: <1171990668.4472.205.camel@localhost.localdomain> On Tue, 2007-02-20 at 09:20 -0600, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> Request for voting on dropping the *mandatory* from the guidelines > AT> and explicitely cast it into a *suggestion* > > -1 -1 This puts us back where we started. It was a suggestion until recently. The fact that it wasn't mandatory just confused reviewers and made people debate the issue over and over inside of bugzilla. Let's move forward: 1) Make a clear rule on a buildroot value that fixes the technical issues. 2) Get changes made to rpm so that F7/8 and RHEL6 don't have to worry about this. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue Feb 20 19:59:09 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Feb 2007 20:59:09 +0100 Subject: [Fedora-packaging] Re: Stopping the mandatory buildroot insanity In-Reply-To: <1171990668.4472.205.camel@localhost.localdomain> References: <20070220102111.GA30283@neu.nirvana> <1171990668.4472.205.camel@localhost.localdomain> Message-ID: <20070220195909.GC15784@neu.nirvana> On Tue, Feb 20, 2007 at 08:57:48AM -0800, Toshio Kuratomi wrote: > On Tue, 2007-02-20 at 09:20 -0600, Jason L Tibbitts III wrote: > > >>>>> "AT" == Axel Thimm writes: > > > > AT> Request for voting on dropping the *mandatory* from the guidelines > > AT> and explicitely cast it into a *suggestion* > > > > -1 > > -1 > This puts us back where we started. It was a suggestion until recently. > The fact that it wasn't mandatory just confused reviewers and made > people debate the issue over and over inside of bugzilla. which is the same now when a half-hearted buildroot is made mandatory. If you want to make something mandatory it has to be something worth doing so. The buildroot that only covers a seldom corner case of multiple users building the same package while ignoring the far more common use case of building i386 and x86_64 on x86_64 (for F7 we're making even more multilib developping noise) is just not worth putting in specfiles lest to cast it into an iron mandatory part. > Let's move forward: > 1) Make a clear rule on a buildroot value that fixes the technical > issues. We made that rule. BTW was it ratified? Still it will see opposition just like the id -un rule. And any other buildroot is suggested. So let us just stop suggesting a buildroot (or at least stop dictating one). "If it works, it's OK". And any other funny corner case can indeed bend buildroots at will, right? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Feb 20 21:27:37 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Feb 2007 15:27:37 -0600 Subject: [Fedora-packaging] Re: Stopping the mandatory buildroot insanity References: <20070220102111.GA30283@neu.nirvana> <1171990668.4472.205.camel@localhost.localdomain> <20070220195909.GC15784@neu.nirvana> Message-ID: Axel Thimm wrote: > So let us just stop suggesting a buildroot (or at least stop dictating > one). "If it works, it's OK". Problem being there are even differing opinions on what "If it works" means. -- Rex From Axel.Thimm at ATrpms.net Tue Feb 20 21:36:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Feb 2007 22:36:25 +0100 Subject: [Fedora-packaging] Re: Stopping the mandatory buildroot insanity In-Reply-To: References: <20070220102111.GA30283@neu.nirvana> <1171990668.4472.205.camel@localhost.localdomain> <20070220195909.GC15784@neu.nirvana> Message-ID: <20070220213625.GE15784@neu.nirvana> On Tue, Feb 20, 2007 at 03:27:37PM -0600, Rex Dieter wrote: > Axel Thimm wrote: > > > > So let us just stop suggesting a buildroot (or at least stop dictating > > one). "If it works, it's OK". > > Problem being there are even differing opinions on what "If it works" means. Let it be a broad as possible or drop that part from the guidelines. "If it works" means it doesn't eat your cats, wife and mother in law. Although some may even discuss that some of these side-effects aren't really that bad ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmz at pobox.com Wed Feb 21 16:41:43 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 21 Feb 2007 11:41:43 -0500 Subject: [Fedora-packaging] Use of vendor in .desktop files Message-ID: <20070221164143.GB31735@psilocybe.teonanacatl.org> Has the use of vendor in .desktop files been changed recently? The guidelines currently say "If upstream uses , leave it intact, otherwise use fedora as ." This is what I'm doing in my package. I see that there are some proposed changes to the desktop files section in PackagingDrafts/DesktopFiles, but the use of vendor is unchanged in that draft. I also don't see anything in the IRClogs nor do I recall reading anything on this list. I ask because it's come up in a review and I'd just like to be sure that I haven't missed a change (and so I'll have a clear and definitive answer to refer to in the review [#228425]). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== So live that you can look any man in the eye and tell him to go to hell. -- Anonymous -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Feb 21 16:56:05 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 Feb 2007 10:56:05 -0600 Subject: [Fedora-packaging] Use of vendor in .desktop files In-Reply-To: <20070221164143.GB31735@psilocybe.teonanacatl.org> References: <20070221164143.GB31735@psilocybe.teonanacatl.org> Message-ID: <45DC79A5.2060905@math.unl.edu> Todd Zullinger wrote: > Has the use of vendor in .desktop files been changed recently? The > guidelines currently say "If upstream uses , leave it > intact, otherwise use fedora as ." This is what I'm doing > in my package. I see that there are some proposed changes to the > desktop files section in PackagingDrafts/DesktopFiles, but the use of > vendor is unchanged in that draft. I also don't see anything in the > IRClogs nor do I recall reading anything on this list. Recently? yes. Packaging/Guidelines were updated on 02/16 to include what was in PackagingDrafts/DesktopFiles -- Rex From tmz at pobox.com Wed Feb 21 17:08:53 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 21 Feb 2007 12:08:53 -0500 Subject: [Fedora-packaging] Use of vendor in .desktop files In-Reply-To: <45DC79A5.2060905@math.unl.edu> References: <20070221164143.GB31735@psilocybe.teonanacatl.org> <45DC79A5.2060905@math.unl.edu> Message-ID: <20070221170853.GC31735@psilocybe.teonanacatl.org> Rex Dieter wrote: > Recently? yes. > Packaging/Guidelines were updated on 02/16 to include what was in > PackagingDrafts/DesktopFiles Thanks Rex. That ought to make it clear that vendor is still needed. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== Never was a government that was not composed of liars, malefactors and thieves. -- Cicero, last Free Consul of Rome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Feb 22 11:23:48 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 22 Feb 2007 12:23:48 +0100 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <200702170951.34896.jkeating@redhat.com> (Jesse Keating's message of "Sat, 17 Feb 2007 09:51:34 -0500") References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> Message-ID: <874ppe8mgr.fsf@kosh.bigo.ensc.de> jkeating at redhat.com (Jesse Keating) writes: >> no; %config is ok (I do not want to lose changes to /etc files >> silently). But I agree that there is no need to mark them as >> %config(noreplace). > > And you feel OK about other scripts on your system silently losing > changes because they're outside of /etc? It depends on their location. When they are under /usr, I would never edit them because this location is not intended for configuration. When they are in /etc, I expect that my changes will not be thrown away silently, because this location is intended for configuration. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mattdm at mattdm.org Thu Feb 22 13:24:46 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Feb 2007 08:24:46 -0500 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <874ppe8mgr.fsf@kosh.bigo.ensc.de> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> Message-ID: <20070222132446.GA9401@jadzia.bu.edu> On Thu, Feb 22, 2007 at 12:23:48PM +0100, Enrico Scholz wrote: > > And you feel OK about other scripts on your system silently losing > > changes because they're outside of /etc? > It depends on their location. When they are under /usr, I would never > edit them because this location is not intended for configuration. > When they are in /etc, I expect that my changes will not be thrown away > silently, because this location is intended for configuration. And further, I don't want to have to look for .rpmsave/.rpmnew files outside of /etc. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tibbs at math.uh.edu Thu Feb 22 15:33:47 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Feb 2007 09:33:47 -0600 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <20070222132446.GA9401@jadzia.bu.edu> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> <20070222132446.GA9401@jadzia.bu.edu> Message-ID: >>>>> "MM" == Matthew Miller writes: MM> And further, I don't want to have to look for .rpmsave/.rpmnew MM> files outside of /etc. Why would you look for them at all? That's what tools are for. http://www.math.uh.edu/~tibbs/rpmchanges Exits 1 if any .rpmnew/.rpmsave files are present. -q will give no report, -d will give you diffs. - J< From mattdm at mattdm.org Thu Feb 22 15:37:03 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Feb 2007 10:37:03 -0500 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> <20070222132446.GA9401@jadzia.bu.edu> Message-ID: <20070222153703.GA20048@jadzia.bu.edu> On Thu, Feb 22, 2007 at 09:33:47AM -0600, Jason L Tibbitts III wrote: > MM> And further, I don't want to have to look for .rpmsave/.rpmnew > MM> files outside of /etc. > Why would you look for them at all? That's what tools are for. Rephrase: "my tools should have to crawl the whole frickin' universe of filesystems looking for rpmnew/rpmsave files". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tibbs at math.uh.edu Thu Feb 22 16:31:16 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Feb 2007 10:31:16 -0600 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <20070222153703.GA20048@jadzia.bu.edu> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> <20070222132446.GA9401@jadzia.bu.edu> <20070222153703.GA20048@jadzia.bu.edu> Message-ID: >>>>> "MM" == Matthew Miller writes: MM> Rephrase: "my tools should have to crawl the whole frickin' MM> universe of filesystems looking for rpmnew/rpmsave files". Just the universe of files marked as %config, as given by rpm -qac, which I thought was the whole point. After all, if you want to know the files that could potentially cause .rpmnew or .rpmsave files to be created, isn't it best to just ask rpm rather than assuming that they'll all be in a specific place? Of course, this is pretty much offtopic for the discussion. Sorry for derailing it. - J< From fedora at leemhuis.info Thu Feb 22 17:02:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Feb 2007 18:02:42 +0100 Subject: [Fedora-packaging] Scripts around rpm (was: Re: Draft: Init Scripts) In-Reply-To: References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> <20070222132446.GA9401@jadzia.bu.edu> Message-ID: <45DDCCB2.5010102@leemhuis.info> Jason L Tibbitts III schrieb: >>>>>> "MM" == Matthew Miller writes: > MM> And further, I don't want to have to look for .rpmsave/.rpmnew > MM> files outside of /etc. > > Why would you look for them at all? That's what tools are for. > http://www.math.uh.edu/~tibbs/rpmchanges I (and probably many others) have similar scripts. I'm wondering if we should trow them together, put the best one into a package (?) and ship them in Fedora, so people don't have to reinvent the wheel over and over again. CU thl (?) -- something similar to the rpmdevtools package probably From wart at kobold.org Thu Feb 22 17:20:20 2007 From: wart at kobold.org (Wart) Date: Thu, 22 Feb 2007 09:20:20 -0800 Subject: [Fedora-packaging] Scripts around rpm In-Reply-To: <45DDCCB2.5010102@leemhuis.info> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> <20070222132446.GA9401@jadzia.bu.edu> <45DDCCB2.5010102@leemhuis.info> Message-ID: <45DDD0D4.7080901@kobold.org> Thorsten Leemhuis wrote: > Jason L Tibbitts III schrieb: >>>>>>> "MM" == Matthew Miller writes: >> MM> And further, I don't want to have to look for .rpmsave/.rpmnew >> MM> files outside of /etc. >> >> Why would you look for them at all? That's what tools are for. >> http://www.math.uh.edu/~tibbs/rpmchanges > > I (and probably many others) have similar scripts. I'm wondering if we > should trow them together, put the best one into a package (?) and ship > them in Fedora, so people don't have to reinvent the wheel over and over > again. Maybe I'm just being dense, but aren't these files easily found with: # updatedb # locate rpmsave # locate rpmnew ? --Wart From ville.skytta at iki.fi Thu Feb 22 17:24:16 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 22 Feb 2007 19:24:16 +0200 Subject: [Fedora-packaging] Scripts around rpm (was: Re: Draft: Init Scripts) In-Reply-To: <45DDCCB2.5010102@leemhuis.info> References: <200702161800.40666.jkeating@redhat.com> <45DDCCB2.5010102@leemhuis.info> Message-ID: <200702221924.16582.ville.skytta@iki.fi> On Thursday 22 February 2007, Thorsten Leemhuis wrote: > Jason L Tibbitts III schrieb: > >>>>>> "MM" == Matthew Miller writes: > > > > MM> And further, I don't want to have to look for .rpmsave/.rpmnew > > MM> files outside of /etc. > > > > Why would you look for them at all? That's what tools are for. > > http://www.math.uh.edu/~tibbs/rpmchanges > > I (and probably many others) have similar scripts. I'm wondering if we > should trow them together, put the best one into a package (?) and ship > them in Fedora, so people don't have to reinvent the wheel over and over > again. Everyone's welcome to suggest additions to rpmdevtools. But it would not hurt to have another similar but less development oriented package of nifty scripts around. There's also http://fedoraproject.org/wiki/Extras/UsefulScripts Oh, and qa-robot from ALT Linux has a bunch of useful looking things (especially rpmsodiff) that I've meant to take a look at but haven't got around to it yet, anyone interested? Some of them might require some cleanup/changes to be generally applicable outside of ALT Linux. http://www.altlinux.com/index.php?module=sisyphus&package=qa-robot From fedora at leemhuis.info Thu Feb 22 17:59:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Feb 2007 18:59:38 +0100 Subject: [Fedora-packaging] Scripts around rpm In-Reply-To: <45DDD0D4.7080901@kobold.org> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> <20070222132446.GA9401@jadzia.bu.edu> <45DDCCB2.5010102@leemhuis.info> <45DDD0D4.7080901@kobold.org> Message-ID: <45DDDA0A.9040309@leemhuis.info> Wart schrieb: > Thorsten Leemhuis wrote: >> Jason L Tibbitts III schrieb: >>>>>>>> "MM" == Matthew Miller writes: >>> MM> And further, I don't want to have to look for .rpmsave/.rpmnew >>> MM> files outside of /etc. >>> >>> Why would you look for them at all? That's what tools are for. >>> http://www.math.uh.edu/~tibbs/rpmchanges >> I (and probably many others) have similar scripts. I'm wondering if we >> should trow them together, put the best one into a package (?) and ship >> them in Fedora, so people don't have to reinvent the wheel over and over >> again. > > Maybe I'm just being dense, but aren't these files easily found with: > > # updatedb > # locate rpmsave > # locate rpmnew That IMHO becomes quite annoying quickly. Thus I wrote some functions for my .bashrc that automate parts of the work -- I just uploaded them to http://www.leemhuis.info/files/fedorarpms/MISC.fdr/rpmstuff Not sure if the stuff is complete; Warning, the stuff is grown over time and might delete all your data, kill kittens and so own. Further: there are probably much better and cleaner ways to archive the goals than the stuff I wrote. What my stuff does: rpm_find_packages_with_corrupted_files -> finds missing, corrupted files and config files that got changed rpmcleanup-rpmnewfile and rpmcleanup-rpmnewfiles as well as rpmcleanup-rpmsavefile and rpmcleanup-rpmsavefiles -> process rpm{new,save} files; if the md5sum is identical move the rpmnew file over for example; otherwise show a diff, ask user what to do (for example run meld to merge the files) rpm_find_problems -> run some of above test as well as some stuff from rpmdevtools and yum-utils I'm sure most of us have other scripts for the same and different problems. So it might be a good idea to just find the best ones for particular problems and package them up, so the problem get solved once and for all. CU thl From skvidal at linux.duke.edu Thu Feb 22 18:04:37 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 22 Feb 2007 13:04:37 -0500 Subject: [Fedora-packaging] Scripts around rpm (was: Re: Draft: Init Scripts) In-Reply-To: <45DDCCB2.5010102@leemhuis.info> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> <20070222132446.GA9401@jadzia.bu.edu> <45DDCCB2.5010102@leemhuis.info> Message-ID: <1172167477.8256.132.camel@cutter> On Thu, 2007-02-22 at 18:02 +0100, Thorsten Leemhuis wrote: > Jason L Tibbitts III schrieb: > >>>>>> "MM" == Matthew Miller writes: > > MM> And further, I don't want to have to look for .rpmsave/.rpmnew > > MM> files outside of /etc. > > > > Why would you look for them at all? That's what tools are for. > > http://www.math.uh.edu/~tibbs/rpmchanges > > I (and probably many others) have similar scripts. I'm wondering if we > should trow them together, put the best one into a package (?) and ship > them in Fedora, so people don't have to reinvent the wheel over and over > again. > why not put the rpmchanges mechanism in a post-transaction plugin in yum. Then it can go through and create a little report for you after any transaction. -sv From mattdm at mattdm.org Thu Feb 22 18:07:46 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Feb 2007 13:07:46 -0500 Subject: [Fedora-packaging] Scripts around rpm (was: Re: Draft: Init Scripts) In-Reply-To: <1172167477.8256.132.camel@cutter> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> <20070222132446.GA9401@jadzia.bu.edu> <45DDCCB2.5010102@leemhuis.info> <1172167477.8256.132.camel@cutter> Message-ID: <20070222180746.GA32609@jadzia.bu.edu> On Thu, Feb 22, 2007 at 01:04:37PM -0500, seth vidal wrote: > why not put the rpmchanges mechanism in a post-transaction plugin in > yum. Then it can go through and create a little report for you after any > transaction. Yes, please, someone, because that would reduce my todo list by one item. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Thu Feb 22 18:05:13 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 Feb 2007 13:05:13 -0500 Subject: [Fedora-packaging] Scripts around rpm (was: Re: Draft: Init Scripts) In-Reply-To: <1172167477.8256.132.camel@cutter> References: <200702161800.40666.jkeating@redhat.com> <87y7mx6nos.fsf@kosh.bigo.ensc.de> <200702170951.34896.jkeating@redhat.com> <874ppe8mgr.fsf@kosh.bigo.ensc.de> <20070222132446.GA9401@jadzia.bu.edu> <45DDCCB2.5010102@leemhuis.info> <1172167477.8256.132.camel@cutter> Message-ID: <20070222180513.GC1985@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > why not put the rpmchanges mechanism in a post-transaction plugin in > yum. Then it can go through and create a little report for you after any > transaction. And pirut can put up a three-way diff with a Merge/Apply button. Woo. Bill From Axel.Thimm at ATrpms.net Thu Feb 22 20:21:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 22 Feb 2007 21:21:38 +0100 Subject: [Fedora-packaging] Re: Stopping the mandatory buildroot insanity In-Reply-To: <20070220102111.GA30283@neu.nirvana> References: <20070220102111.GA30283@neu.nirvana> Message-ID: <20070222202138.GC2096@neu.nirvana> spot asked me to draft something in the wiki about pushing all responsibility to (grown-up) packagers while still presenting a couple of sane buildroots as a guideline. The outcome is on http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot: > [[Anchor(BuildRoot)]] > == Build root tag == > > The ''Build``Root'' MUST be below %{_tmppath} and MUST use %{name}, %{version} and %{release}. It also may make use of ''mktemp'' since this is guaranteed to exist on any system. Other than that packagers are free to use any sane ''Build``Root''. > > The ''recommended'' values for the ''Build``Root'' tag are (in descending order of preference) > {{{ > %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > %{_tmppath}/%{name}-%{version}-%{release}-root > }}} At one point, this was a mandatory value, but it is now left to the packager. On Tue, Feb 20, 2007 at 11:21:11AM +0100, Axel Thimm wrote: > So we voted on a new *mandatory* buildroot. By now people saw that the > previous *mandatory* buildroot entered the guidelines and started > blocking new packages requiring the old *mandatory* buildroot. > > I don't know what fesco did last week on ratifying or not the new > buildroot, and either way people will think differently on any single > buildroot. Perhaps buildroots are the most unimportant piece of s**t > with the most polarized parties. > > Now who's idea was it to have a *MANDATORY* buildroot at all? > > Most of the FPC are fed up and have often stated that the buildroot > guidelines should be simple "If it works, have it". > > Plain and simple: > > Request for voting on dropping the *mandatory* from the guidelines > and explicitely cast it into a *suggestion* > > +1 > > The first other five positive voters get a free beer when I meet > them (we never said that committee members could not be bribed, or do > we need a guideline for that? ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Feb 23 04:24:24 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 Feb 2007 23:24:24 -0500 Subject: [Fedora-packaging] Firmware packaging, v2 Message-ID: <20070223042424.GA23898@nostromo.devel.redhat.com> Just a minor edit to the previous proposal. I'd like the firmware section of the packaging guidelines modified to add: 1) Firmware packages are given the Group: tag of Firmware 2) The License tag for any firmware that disallows modification should be set to: "Redistributable firmware, no modification permitted" I'd write something for the PackagingDrafts, but it's locked down. Can we get this approved? Thanks in advance, Bill From jcm at redhat.com Fri Feb 23 05:06:26 2007 From: jcm at redhat.com (Jon Masters) Date: Fri, 23 Feb 2007 00:06:26 -0500 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <20070223042424.GA23898@nostromo.devel.redhat.com> References: <20070223042424.GA23898@nostromo.devel.redhat.com> Message-ID: <45DE7652.7040205@redhat.com> Bill Nottingham wrote: > Just a minor edit to the previous proposal. > > I'd like the firmware section of the packaging guidelines modified > to add: > > 1) Firmware packages are given the Group: tag of Firmware Did I miss where this was decided? I can see why, but I'm curious if I missed some of the discussion beyond the initial "it's a good idea". Jon. From notting at redhat.com Fri Feb 23 05:13:49 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Feb 2007 00:13:49 -0500 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <45DE7652.7040205@redhat.com> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <45DE7652.7040205@redhat.com> Message-ID: <20070223051349.GB26082@nostromo.devel.redhat.com> Jon Masters (jcm at redhat.com) said: > >1) Firmware packages are given the Group: tag of Firmware > > Did I miss where this was decided? I can see why, but I'm curious if I > missed some of the discussion beyond the initial "it's a good idea". More people that responded preferred 'Firmware' to 'System Environment/Kernel'. Bill From jcm at redhat.com Fri Feb 23 05:48:55 2007 From: jcm at redhat.com (Jon Masters) Date: Fri, 23 Feb 2007 00:48:55 -0500 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <20070223051349.GB26082@nostromo.devel.redhat.com> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <45DE7652.7040205@redhat.com> <20070223051349.GB26082@nostromo.devel.redhat.com> Message-ID: <45DE8047.4010807@redhat.com> Bill Nottingham wrote: > Jon Masters (jcm at redhat.com) said: >>> 1) Firmware packages are given the Group: tag of Firmware >> Did I miss where this was decided? I can see why, but I'm curious if I >> missed some of the discussion beyond the initial "it's a good idea". > > More people that responded preferred 'Firmware' to > 'System Environment/Kernel'. Ok. I'm cool with either. So we should now also have mkinitrd doing the right thing...I guess that just leaves anaconda... :-) Jon. From Axel.Thimm at ATrpms.net Fri Feb 23 09:32:12 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Feb 2007 10:32:12 +0100 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <20070223042424.GA23898@nostromo.devel.redhat.com> References: <20070223042424.GA23898@nostromo.devel.redhat.com> Message-ID: <20070223093212.GA6561@neu.nirvana> On Thu, Feb 22, 2007 at 11:24:24PM -0500, Bill Nottingham wrote: > Just a minor edit to the previous proposal. > > I'd like the firmware section of the packaging guidelines modified > to add: > > 1) Firmware packages are given the Group: tag of Firmware > > 2) The License tag for any firmware that disallows modification should > be set to: > > "Redistributable firmware, no modification permitted" > > I'd write something for the PackagingDrafts, but it's locked down. > Can we get this approved? Why do firmwares need to be special-cased like that? Firmwares are special in that they needed the explicit exemption from the otherwise open source definition, but when it comes to packaging they should be treated like all the rest, e.g. 1) no one is fond of the Groups tag, but that would be the first deviation from the set set in stone ages ago for no good cause. And "System Environment/Base" seems adequate enough to cover both kernelland and userland firmwares. 2) If we need to define a non-open source license we should drop the "firmware" part if it. I think what you want is to quickly select firmware packages. Maybe that's better done with having firmwares always prefix the package name instead with "firmware-"? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Feb 23 09:51:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Feb 2007 10:51:18 +0100 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <20070223093212.GA6561@neu.nirvana> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> Message-ID: <45DEB916.2050408@leemhuis.info> On 23.02.2007 10:32, Axel Thimm wrote: > [...] > I think what you want is to quickly select firmware packages. Maybe > that's better done with having firmwares always prefix the package > name instead with "firmware-"? Sound like a nice idea to me. BTW, do we have a definite description of what a firmware is (and what not). Something like "A firmware is uploaded to the flash of a hardware device and executed there *and not* by the operating system on the host cpu" Might be a good idea to write that or something similar down somewhere, to avoid that someone submits madwifi's HAL or similar cruft as firmware package. CU thl From Axel.Thimm at ATrpms.net Fri Feb 23 10:35:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Feb 2007 11:35:42 +0100 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <45DEB916.2050408@leemhuis.info> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> <45DEB916.2050408@leemhuis.info> Message-ID: <20070223103542.GB6561@neu.nirvana> On Fri, Feb 23, 2007 at 10:51:18AM +0100, Thorsten Leemhuis wrote: > On 23.02.2007 10:32, Axel Thimm wrote: > >[...] > >I think what you want is to quickly select firmware packages. Maybe > >that's better done with having firmwares always prefix the package > >name instead with "firmware-"? > > Sound like a nice idea to me. > > BTW, do we have a definite description of what a firmware is does that fit? http://en.wikipedia.org/wiki/Firmware > (and what not). Something like "A firmware is uploaded to the flash > of a hardware device and executed there *and not* by the operating > system on the host cpu" > Might be a good idea to write that or something similar down somewhere, > to avoid that someone submits madwifi's HAL or similar cruft as firmware > package. > > CU > thl > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Feb 23 10:56:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Feb 2007 11:56:36 +0100 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <20070223103542.GB6561@neu.nirvana> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> <45DEB916.2050408@leemhuis.info> <20070223103542.GB6561@neu.nirvana> Message-ID: <45DEC864.2090902@leemhuis.info> On 23.02.2007 11:35, Axel Thimm wrote: > On Fri, Feb 23, 2007 at 10:51:18AM +0100, Thorsten Leemhuis wrote: >> On 23.02.2007 10:32, Axel Thimm wrote: >>> [...] >>> I think what you want is to quickly select firmware packages. Maybe >>> that's better done with having firmwares always prefix the package >>> name instead with "firmware-"? >> Sound like a nice idea to me. >> BTW, do we have a definite description of what a firmware is > does that fit? > http://en.wikipedia.org/wiki/Firmware Well, sure, but writing a single sentence like >> (and what not). Something like "A firmware is uploaded to the flash >> of a hardware device and executed there *and not* by the operating >> system on the host cpu" might be helpful without much work afaics. Especially the part "not executed by the operating system on the host cpu" -- that part it not that obvious in the wikipedia article, but important for us afaics. CU thl From Axel.Thimm at ATrpms.net Fri Feb 23 11:50:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Feb 2007 12:50:20 +0100 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <45DEC864.2090902@leemhuis.info> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> <45DEB916.2050408@leemhuis.info> <20070223103542.GB6561@neu.nirvana> <45DEC864.2090902@leemhuis.info> Message-ID: <20070223115020.GC6561@neu.nirvana> On Fri, Feb 23, 2007 at 11:56:36AM +0100, Thorsten Leemhuis wrote: > On 23.02.2007 11:35, Axel Thimm wrote: > >On Fri, Feb 23, 2007 at 10:51:18AM +0100, Thorsten Leemhuis wrote: > >>On 23.02.2007 10:32, Axel Thimm wrote: > >>>[...] > >>>I think what you want is to quickly select firmware packages. Maybe > >>>that's better done with having firmwares always prefix the package > >>>name instead with "firmware-"? > >>Sound like a nice idea to me. > >>BTW, do we have a definite description of what a firmware is > >does that fit? > >http://en.wikipedia.org/wiki/Firmware > > Well, sure, but writing a single sentence like > > >>(and what not). Something like "A firmware is uploaded to the flash > >>of a hardware device and executed there *and not* by the operating > >>system on the host cpu" > > might be helpful without much work afaics. Especially the part "not > executed by the operating system on the host cpu" -- that part it not > that obvious in the wikipedia article, but important for us afaics. We should just avoid excluding stuff like open/freebios which is open source firmware executed on the CPU. Anyway, kernel modules need signing off by fesco and there are far less firmwares than kernel modules out there. How about having fesco sign off firmwares, so we don't need to come up with too complex definitions that will later need several adjustement steps etc. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Feb 23 12:50:56 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 23 Feb 2007 06:50:56 -0600 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <45DEB916.2050408@leemhuis.info> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> <45DEB916.2050408@leemhuis.info> Message-ID: <45DEE330.6010501@math.unl.edu> Thorsten Leemhuis wrote: > BTW, do we have a definite description of what a firmware is (and what > not). Something like "A firmware is uploaded to the flash of a hardware > device and executed there *and not* by the operating system on the host > cpu" What we have now is: http://fedoraproject.org/wiki/Packaging/Guidelines#head-adf31c383612aac313719f7b4f8167b7dcf245d2 -- Rex From notting at redhat.com Fri Feb 23 17:33:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Feb 2007 12:33:22 -0500 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <45DEB916.2050408@leemhuis.info> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> <45DEB916.2050408@leemhuis.info> Message-ID: <20070223173322.GA2648@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > BTW, do we have a definite description of what a firmware is See the packaging guidelines. Bill From notting at redhat.com Fri Feb 23 17:36:01 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Feb 2007 12:36:01 -0500 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <20070223093212.GA6561@neu.nirvana> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> Message-ID: <20070223173601.GB2648@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > 1) no one is fond of the Groups tag, but that would be the first > deviation from the set set in stone ages ago for no good cause. And > "System Environment/Base" seems adequate enough to cover both > kernelland and userland firmwares. *shrug* I figured it's best to be more descriptive rather than less. > 2) If we need to define a non-open source license we should drop the > "firmware" part if it. We need to be able to clearly delineate the firmware that is not modifiable/open source. (This is needed to properly word the EULA). As that's the only thing we're shipping that is like that (AFAIK), the license tag is the best place to standardize. > I think what you want is to quickly select firmware packages. Maybe > that's better done with having firmwares always prefix the package > name instead with "firmware-"? It's not really 'firmware' packages per se - something like the zd1211 firmware, which is GPL, doesn't need as strict of control. Moreover, by changing the name, you break the 'follow-upstream' part of the packaging guidelines. Bill From Axel.Thimm at ATrpms.net Fri Feb 23 19:08:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Feb 2007 20:08:37 +0100 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <20070223173601.GB2648@nostromo.devel.redhat.com> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> <20070223173601.GB2648@nostromo.devel.redhat.com> Message-ID: <20070223190837.GH21659@neu.nirvana> On Fri, Feb 23, 2007 at 12:36:01PM -0500, Bill Nottingham wrote: > Moreover, by changing the name, you break the 'follow-upstream' > part of the packaging guidelines. I just say perl-, python-, php-*-, blah-plugin-foo, ruby-, java- and lowercasing, not to mention *-kmod and kmod-*. We're not really following upstream even if the guidelines claim that. It would be interesting to see how many packages are really named according to upstream rules. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Sat Feb 24 01:55:00 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Feb 2007 19:55:00 -0600 Subject: [Fedora-packaging] Executable documentation Message-ID: For some time I've been working under the assumption that executable documentation is a bad idea. rpmlint complains when documentation generates dependencies, and these dependencies are often needless bloat. Lately I'm getting pushback when asking for a quick chmod -x of docs. The usual argument is "It's an example, it's supposed to be executable." Currently I don't see anything in the guidelines that would forbid this as long as it doesn't cause extra dependencies. So, is there concensus that allowing documentation to be executable is OK? Or is it something that should be prohibited. - J< From Fedora at FamilleCollet.com Sat Feb 24 08:21:33 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 24 Feb 2007 09:21:33 +0100 Subject: [Fedora-packaging] Please update PHP PECL Guidelines : [Fwd: [SECURITY] Fedora Core 6 Update: php-5.1.6-3.4.fc6] Message-ID: <45DFF58D.4070704@FamilleCollet.com> --------------------------------------------------------------------- Fedora Update Notification FEDORA-2007-261 2007-02-20 --------------------------------------------------------------------- Product : Fedora Core 6 Name : php Version : 5.1.6 Release : 3.4.fc6 .... --------------------------------------------------------------------- * Fri Feb 16 2007 Joe Orton 5.1.6-3.4.fc6 ... - add php(api), php(zend-abi) provides (#221302) As php(api), php(zend-abi) are now provided on FC >= 6, i think http://fedoraproject.org/wiki/Packaging/PHP#head-435fc0b2b6fa2e807e89b72025848db84fea9d1c should be update to use this new provides (more robust to detect PHP ABI changes) I've just push php-pecl-zip update which use this : %if %{?php_zend_api}0 # Provides by new php-common on FC >= 6 Requires: php(zend-abi) = %{php_zend_api} Requires: php(api) = %{php_core_api} %else # Old Provides Requires: php-api = %{php_apiver} %endif Regards, Remi From Fedora at FamilleCollet.com Sat Feb 24 08:28:01 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 24 Feb 2007 09:28:01 +0100 Subject: [Fedora-packaging] Please update PHP PECL Guidelines : [Fwd: [SECURITY] Fedora Core 6 Update: php-5.1.6-3.4.fc6] In-Reply-To: <45DFF58D.4070704@FamilleCollet.com> References: <45DFF58D.4070704@FamilleCollet.com> Message-ID: <45DFF711.7020502@FamilleCollet.com> > As php(api), php(zend-abi) are now provided on FC >= 6, i think > http://fedoraproject.org/wiki/Packaging/PHP#head-435fc0b2b6fa2e807e89b72025848db84fea9d1c > should be update to use this new provides (more robust to detect PHP ABI changes) Just notice this as be discussed on Fedora Packaging Committee http://fedoraproject.org/wiki/Packaging/IRCLog20070102 From nicolas.mailhot at laposte.net Sun Feb 25 08:30:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 25 Feb 2007 09:30:44 +0100 Subject: [Fedora-packaging] Re: Re: Wrong buildroot ... In-Reply-To: References: <20070210135347.GD21848@neu.nirvana> <1171132904.4306.274.camel@localhost.localdomain> <20070210230507.GC23731@neu.nirvana> <20070212155218.GA25585@redhat.com> <20070212175059.31dee292@python3.es.egwn.lan> Message-ID: <1172392244.25309.2.camel@rousalka.dyndns.org> Le vendredi 16 f?vrier 2007 ? 10:11 +0200, Panu Matilainen a ?crit : > > - %defattr(-,root,root,-) or %defattr(-,root,root,0755) > > Heh, actually this last one item (cause of no-end stupid mistakes) has > actually already been fixed in RPM while we weren't looking. In > /usr/share/doc/rpm-*/CHANGES: > > 4.3.3 -> 4.4: > ... > - silently add default %defattr(-,root,root) for all packages. > ... > > And that indeed seems to be the case. One check-item less in the package > review procedure. Barf, I'd have preferred %defattr(0644,root,root,0755), making the decision to trust upstream permissions (and assigning them to root) an explicit choice. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Sun Feb 25 10:40:56 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 25 Feb 2007 12:40:56 +0200 Subject: [Fedora-packaging] Executable documentation In-Reply-To: References: Message-ID: <200702251240.56529.ville.skytta@iki.fi> On Saturday 24 February 2007, Jason L Tibbitts III wrote: > For some time I've been working under the assumption that executable > documentation is a bad idea. rpmlint complains when documentation > generates dependencies, and these dependencies are often needless > bloat. > > Lately I'm getting pushback when asking for a quick chmod -x of docs. > The usual argument is "It's an example, it's supposed to be > executable." Currently I don't see anything in the guidelines that > would forbid this as long as it doesn't cause extra dependencies. > > So, is there concensus that allowing documentation to be executable is > OK? Or is it something that should be prohibited. I don't see anything wrong with including example scripts etc as executable if they're useful and can be executed as is and don't result in additional dependencies. Note that rpmlint does try to check if a dependency from docs is an additional one or not and suppresses output if it's not, however it doesn't do any depsolving which results in some warnings that can be argued to be false positives. Warnings about doc dependencies such as eg. /bin/sh for any package, or /usr/bin/perl for things that already require perl(...) can IMO be ignored. But the packager needs to keep an eye on possble future package splits etc which may result in the doc dependency previously indirectly satisfied by other dependencies in the package no longer resulting in that, and to act accordingly when/if that happens. From Matt_Domsch at dell.com Sun Feb 25 22:13:20 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 25 Feb 2007 16:13:20 -0600 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <45DEC864.2090902@leemhuis.info> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> <45DEB916.2050408@leemhuis.info> <20070223103542.GB6561@neu.nirvana> <45DEC864.2090902@leemhuis.info> Message-ID: <20070225221320.GB28931@lists.us.dell.com> On Fri, Feb 23, 2007 at 11:56:36AM +0100, Thorsten Leemhuis wrote: > On 23.02.2007 11:35, Axel Thimm wrote: > >On Fri, Feb 23, 2007 at 10:51:18AM +0100, Thorsten Leemhuis wrote: > >>On 23.02.2007 10:32, Axel Thimm wrote: > >>>[...] > >>>I think what you want is to quickly select firmware packages. Maybe > >>>that's better done with having firmwares always prefix the package > >>>name instead with "firmware-"? > >>Sound like a nice idea to me. > >>BTW, do we have a definite description of what a firmware is > >does that fit? > >http://en.wikipedia.org/wiki/Firmware > > Well, sure, but writing a single sentence like > > >>(and what not). Something like "A firmware is uploaded to the flash > >>of a hardware device and executed there *and not* by the operating > >>system on the host cpu" > > might be helpful without much work afaics. Especially the part "not > executed by the operating system on the host cpu" -- that part it not > that obvious in the wikipedia article, but important for us afaics. Just to re-interate that... see fwupdate.com for Dell system BIOS RPMs. Distributable, not modifiable, executed on the host CPU. Name : system_bios_Precision_370 Relocations: (not relocatable) Version : a08 Vendor: Dell Release : 15.1 Build Date: Mon 12 Feb 2007 10:34:36 AM CST Install Date: Sat 24 Feb 2007 07:35:41 PM CST Build Host: mdomsch-pe2850 Group : System Environment/Base Source RPM: system_bios_Precision_370-a08-15.1.src.rpm Size : 459333 License: Proprietary Signature : DSA/SHA1, Tue 13 Feb 2007 12:39:37 PM CST, Key ID e74433e25e3d7775 Summary : BIOS upgrade package for System: Precision_370 Description : This package contains BIOS update version a08 for System Precision_370 One can argue Fedora shouldn't be in the business of distributing these, and I'd agree. (related to another thread on FAB, there shouldn't be a problem with a hardware distributor adding a package to their installs that provides a yum repo file pointing at their tree of firmware though.) I personally like using the license tag to describe rules such as "proprietary, not modifiable, redistributable" rather than overloading the name. In this case, we named them system_bios*, pci_firmware*, and other names that are descriptive. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From tibbs at math.uh.edu Mon Feb 26 01:03:44 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 25 Feb 2007 19:03:44 -0600 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <20070225221320.GB28931@lists.us.dell.com> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> <45DEB916.2050408@leemhuis.info> <20070223103542.GB6561@neu.nirvana> <45DEC864.2090902@leemhuis.info> <20070225221320.GB28931@lists.us.dell.com> Message-ID: >>>>> "MD" == Matt Domsch writes: MD> One can argue Fedora shouldn't be in the business of distributing MD> these, and I'd agree. (related to another thread on FAB, there MD> shouldn't be a problem with a hardware distributor adding a MD> package to their installs that provides a yum repo file pointing MD> at their tree of firmware though.) Well, I've made that argument before and lost. Others couldn't see any reason to have a package that sets up a repository, although it seems pretty obvious to me. - J< From aoliva at redhat.com Mon Feb 26 07:29:40 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 26 Feb 2007 04:29:40 -0300 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <20070223042424.GA23898@nostromo.devel.redhat.com> (Bill Nottingham's message of "Thu\, 22 Feb 2007 23\:24\:24 -0500") References: <20070223042424.GA23898@nostromo.devel.redhat.com> Message-ID: On Feb 23, 2007, Bill Nottingham wrote: > 1) Firmware packages are given the Group: tag of Firmware > 2) The License tag for any firmware that disallows modification should > be set to: > "Redistributable firmware, no modification permitted" Any chance of getting all non-Free firmware to Require: some empty package (say freedom-loss or proprietary-crap :-) such that: - one could yum erase this package and end up without any non-Free Software installed, and - one could easily veirfy that custom distros with a subset of the complete Fedora package set don't include any such proprietary packages? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From bjohnson-dated-1172832473.ba5e95 at symetrix.com Mon Feb 26 09:25:07 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Feb 2007 02:25:07 -0700 Subject: [Fedora-packaging] FE-Legal review Message-ID: I've blocked a submitted package (ntop) on FE-Legal. I'm not sure who to prod regarding "Apache License, Version 2.0, incompatible with GPL" starting at comment 46. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219025#c46 If this is going to be a problem, it looks like I can remove the Apache 2 files (patch them out). I'm assuming that is sufficient and a modified tarball won't be needed. Since someone will ask: No, this is not documentation, it is javascript used by the built-in web server. Can someone who does the FE-Legal reviews take a look at this for me? Thanks. From skvidal at linux.duke.edu Mon Feb 26 13:27:29 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 26 Feb 2007 08:27:29 -0500 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: References: <20070223042424.GA23898@nostromo.devel.redhat.com> Message-ID: <1172496449.25220.0.camel@cutter> On Mon, 2007-02-26 at 04:29 -0300, Alexandre Oliva wrote: > On Feb 23, 2007, Bill Nottingham wrote: > > > 1) Firmware packages are given the Group: tag of Firmware > > > 2) The License tag for any firmware that disallows modification should > > be set to: > > > "Redistributable firmware, no modification permitted" > > Any chance of getting all non-Free firmware to Require: some empty > package (say freedom-loss or proprietary-crap :-) such that: > > - one could yum erase this package and end up without any non-Free > Software installed, and > > - one could easily veirfy that custom distros with a subset of the > complete Fedora package set don't include any such proprietary > packages? I actually like this idea. -sv From paul at city-fan.org Mon Feb 26 13:41:19 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 26 Feb 2007 13:41:19 +0000 Subject: [Fedora-packaging] Executable documentation In-Reply-To: <200702251240.56529.ville.skytta@iki.fi> References: <200702251240.56529.ville.skytta@iki.fi> Message-ID: <45E2E37F.9060503@city-fan.org> Ville Skytt? wrote: > On Saturday 24 February 2007, Jason L Tibbitts III wrote: >> For some time I've been working under the assumption that executable >> documentation is a bad idea. rpmlint complains when documentation >> generates dependencies, and these dependencies are often needless >> bloat. >> >> Lately I'm getting pushback when asking for a quick chmod -x of docs. >> The usual argument is "It's an example, it's supposed to be >> executable." Currently I don't see anything in the guidelines that >> would forbid this as long as it doesn't cause extra dependencies. >> >> So, is there concensus that allowing documentation to be executable is >> OK? Or is it something that should be prohibited. > > I don't see anything wrong with including example scripts etc as executable if > they're useful and can be executed as is and don't result in additional > dependencies. > > Note that rpmlint does try to check if a dependency from docs is an additional > one or not and suppresses output if it's not, however it doesn't do any > depsolving which results in some warnings that can be argued to be false > positives. Warnings about doc dependencies such as eg. /bin/sh for any > package, or /usr/bin/perl for things that already require perl(...) can IMO > be ignored. > > But the packager needs to keep an eye on possble future package splits etc > which may result in the doc dependency previously indirectly satisfied by > other dependencies in the package no longer resulting in that, and to act > accordingly when/if that happens. I agree entirely. So long as the packager is aware of the issues involved and keeps on top of them when updating etc. Disclaimer: I have at least one package with executable docs, so I'm not entirely unbiased. Paul. From fedora at leemhuis.info Mon Feb 26 13:55:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 26 Feb 2007 14:55:48 +0100 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <1172496449.25220.0.camel@cutter> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <1172496449.25220.0.camel@cutter> Message-ID: <45E2E6E4.8020408@leemhuis.info> On 26.02.2007 14:27, seth vidal wrote: > On Mon, 2007-02-26 at 04:29 -0300, Alexandre Oliva wrote: >> On Feb 23, 2007, Bill Nottingham wrote: >>> 1) Firmware packages are given the Group: tag of Firmware >>> 2) The License tag for any firmware that disallows modification should >>> be set to: >>> "Redistributable firmware, no modification permitted" >> Any chance of getting all non-Free firmware to Require: some empty >> package (say freedom-loss or proprietary-crap :-) such that: >> - one could yum erase this package and end up without any non-Free >> Software installed, and >> - one could easily veirfy that custom distros with a subset of the >> complete Fedora package set don't include any such proprietary >> packages? > I actually like this idea. +1 -- but the kernel IIRC includes a lot of firmware files directly. Are there any efforts to strip those out? CU thl From rdieter at math.unl.edu Mon Feb 26 14:01:39 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Feb 2007 08:01:39 -0600 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <45E2E6E4.8020408@leemhuis.info> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <1172496449.25220.0.camel@cutter> <45E2E6E4.8020408@leemhuis.info> Message-ID: <45E2E843.2030706@math.unl.edu> Thorsten Leemhuis wrote: > On 26.02.2007 14:27, seth vidal wrote: >> On Mon, 2007-02-26 at 04:29 -0300, Alexandre Oliva wrote: >>> On Feb 23, 2007, Bill Nottingham wrote: >>>> 1) Firmware packages are given the Group: tag of Firmware >>>> 2) The License tag for any firmware that disallows modification should >>>> be set to: >>>> "Redistributable firmware, no modification permitted" >>> Any chance of getting all non-Free firmware to Require: some empty >>> package (say freedom-loss or proprietary-crap :-) such that: >>> - one could yum erase this package and end up without any non-Free >>> Software installed, and >>> - one could easily veirfy that custom distros with a subset of the >>> complete Fedora package set don't include any such proprietary >>> packages? >> I actually like this idea. > > +1 -- but the kernel IIRC includes a lot of firmware files directly. Are > there any efforts to strip those out? kernel doesn't include non-free ones (I hope). -- Rex From skvidal at linux.duke.edu Mon Feb 26 14:05:17 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 26 Feb 2007 09:05:17 -0500 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <45E2E843.2030706@math.unl.edu> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <1172496449.25220.0.camel@cutter> <45E2E6E4.8020408@leemhuis.info> <45E2E843.2030706@math.unl.edu> Message-ID: <1172498717.25220.9.camel@cutter> On Mon, 2007-02-26 at 08:01 -0600, Rex Dieter wrote: > Thorsten Leemhuis wrote: > > On 26.02.2007 14:27, seth vidal wrote: > >> On Mon, 2007-02-26 at 04:29 -0300, Alexandre Oliva wrote: > >>> On Feb 23, 2007, Bill Nottingham wrote: > >>>> 1) Firmware packages are given the Group: tag of Firmware > >>>> 2) The License tag for any firmware that disallows modification should > >>>> be set to: > >>>> "Redistributable firmware, no modification permitted" > >>> Any chance of getting all non-Free firmware to Require: some empty > >>> package (say freedom-loss or proprietary-crap :-) such that: > >>> - one could yum erase this package and end up without any non-Free > >>> Software installed, and > >>> - one could easily veirfy that custom distros with a subset of the > >>> complete Fedora package set don't include any such proprietary > >>> packages? > >> I actually like this idea. > > > > +1 -- but the kernel IIRC includes a lot of firmware files directly. Are > > there any efforts to strip those out? > > kernel doesn't include non-free ones (I hope). That's correct. From what's been said the kernel has gpl'd firmware only. now it might be a giant hexdump that's gpl'd but the point is still the same. -sv From Axel.Thimm at ATrpms.net Mon Feb 26 14:09:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Feb 2007 15:09:32 +0100 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <45E2E843.2030706@math.unl.edu> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <1172496449.25220.0.camel@cutter> <45E2E6E4.8020408@leemhuis.info> <45E2E843.2030706@math.unl.edu> Message-ID: <20070226140932.GC8225@neu.nirvana> On Mon, Feb 26, 2007 at 08:01:39AM -0600, Rex Dieter wrote: > Thorsten Leemhuis wrote: > >On 26.02.2007 14:27, seth vidal wrote: > >>On Mon, 2007-02-26 at 04:29 -0300, Alexandre Oliva wrote: > >>>On Feb 23, 2007, Bill Nottingham wrote: > >>>>1) Firmware packages are given the Group: tag of Firmware > >>>>2) The License tag for any firmware that disallows modification should > >>>> be set to: > >>>> "Redistributable firmware, no modification permitted" > >>>Any chance of getting all non-Free firmware to Require: some empty > >>>package (say freedom-loss or proprietary-crap :-) such that: > >>>- one could yum erase this package and end up without any non-Free > >>>Software installed, and > >>>- one could easily veirfy that custom distros with a subset of the > >>>complete Fedora package set don't include any such proprietary > >>>packages? > >>I actually like this idea. > > > >+1 -- but the kernel IIRC includes a lot of firmware files directly. Are > >there any efforts to strip those out? > > kernel doesn't include non-free ones (I hope). Wasn't that why Debian Sarge was stalled for an age and a half (among other)? People discussing riping out the firmware blobs? Maybe we should avoid discussing firmware in the kernel sources otherwise F7 may slip, too. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Feb 26 14:58:08 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 26 Feb 2007 15:58:08 +0100 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <45E2E843.2030706@math.unl.edu> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <1172496449.25220.0.camel@cutter> <45E2E6E4.8020408@leemhuis.info> <45E2E843.2030706@math.unl.edu> Message-ID: <45E2F580.7020903@leemhuis.info> On 26.02.2007 15:01, Rex Dieter wrote: > Thorsten Leemhuis wrote: >> On 26.02.2007 14:27, seth vidal wrote: >>> On Mon, 2007-02-26 at 04:29 -0300, Alexandre Oliva wrote: >>>> On Feb 23, 2007, Bill Nottingham wrote: >>>>> 1) Firmware packages are given the Group: tag of Firmware >>>>> 2) The License tag for any firmware that disallows modification should >>>>> be set to: >>>>> "Redistributable firmware, no modification permitted" >>>> Any chance of getting all non-Free firmware to Require: some empty >>>> package (say freedom-loss or proprietary-crap :-) such that: >>>> - one could yum erase this package and end up without any non-Free >>>> Software installed, and >>>> - one could easily veirfy that custom distros with a subset of the >>>> complete Fedora package set don't include any such proprietary >>>> packages? >>> I actually like this idea. >> +1 -- but the kernel IIRC includes a lot of firmware files directly. Are >> there any efforts to strip those out? > kernel doesn't include non-free ones (I hope). Well, sure, the firmwares in the kernel are are GPL, but are they really "non-free"? That afaics depends on the definition of "free". Anyway, it's not that important for Fedora now, it was more a general question. CU thl From rdieter at math.unl.edu Mon Feb 26 15:03:38 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Feb 2007 09:03:38 -0600 Subject: [Fedora-packaging] Re: Executable documentation References: Message-ID: Jason L Tibbitts III wrote: > For some time I've been working under the assumption that executable > documentation is a bad idea. imo, executable %doc's are ok, just not in %_datadir/%_docdir. -- Rex From tibbs at math.uh.edu Mon Feb 26 15:13:16 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Feb 2007 09:13:16 -0600 Subject: [Fedora-packaging] Re: Executable documentation In-Reply-To: References: Message-ID: >>>>> "RD" == Rex Dieter writes: RD> imo, executable %doc's are ok, just not in %_datadir/%_docdir. Then where should they be? %_bindir? - J< From rdieter at math.unl.edu Mon Feb 26 15:18:20 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Feb 2007 09:18:20 -0600 Subject: [Fedora-packaging] Re: Executable documentation In-Reply-To: References: Message-ID: <45E2FA3C.7010707@math.unl.edu> Jason L Tibbitts III wrote: >>>>>> "RD" == Rex Dieter writes: > > RD> imo, executable %doc's are ok, just not in %_datadir/%_docdir. > > Then where should they be? %_bindir? or under %_libdir somewhere. -- Rex From paul at city-fan.org Mon Feb 26 15:20:57 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 26 Feb 2007 15:20:57 +0000 Subject: [Fedora-packaging] Re: Executable documentation In-Reply-To: <45E2FA3C.7010707@math.unl.edu> References: <45E2FA3C.7010707@math.unl.edu> Message-ID: <45E2FAD9.4050000@city-fan.org> Rex Dieter wrote: > Jason L Tibbitts III wrote: >>>>>>> "RD" == Rex Dieter writes: >> >> RD> imo, executable %doc's are ok, just not in %_datadir/%_docdir. >> >> Then where should they be? %_bindir? > > or under %_libdir somewhere. What's wrong with having them under %_docdir? Typically they will be example programs referred to from other files (e.g. READMEs) in %_docdir and I think it makes sense to keep them together. Paul. From rdieter at math.unl.edu Mon Feb 26 15:26:42 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Feb 2007 09:26:42 -0600 Subject: [Fedora-packaging] Re: Executable documentation In-Reply-To: <45E2FAD9.4050000@city-fan.org> References: <45E2FA3C.7010707@math.unl.edu> <45E2FAD9.4050000@city-fan.org> Message-ID: <45E2FC32.6020706@math.unl.edu> Paul Howarth wrote: > Rex Dieter wrote: >> Jason L Tibbitts III wrote: >>>>>>>> "RD" == Rex Dieter writes: >>> >>> RD> imo, executable %doc's are ok, just not in %_datadir/%_docdir. >>> >>> Then where should they be? %_bindir? >> >> or under %_libdir somewhere. > > What's wrong with having them under %_docdir? I was speaking in the context of binary executables, and putting them under %_datadir doesn't mesh with the intent of arch-independent data and the FHS. -- Rex From paul at city-fan.org Mon Feb 26 15:35:36 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 26 Feb 2007 15:35:36 +0000 Subject: [Fedora-packaging] Re: Executable documentation In-Reply-To: <45E2FC32.6020706@math.unl.edu> References: <45E2FA3C.7010707@math.unl.edu> <45E2FAD9.4050000@city-fan.org> <45E2FC32.6020706@math.unl.edu> Message-ID: <45E2FE48.4090702@city-fan.org> Rex Dieter wrote: > Paul Howarth wrote: >> Rex Dieter wrote: >>> Jason L Tibbitts III wrote: >>>>>>>>> "RD" == Rex Dieter writes: >>>> >>>> RD> imo, executable %doc's are ok, just not in %_datadir/%_docdir. >>>> >>>> Then where should they be? %_bindir? >>> >>> or under %_libdir somewhere. >> >> What's wrong with having them under %_docdir? > > I was speaking in the context of binary executables, and putting them > under %_datadir doesn't mesh with the intent of arch-independent data > and the FHS. So noarch stuff like perl scripts would be OK? Paul. From rdieter at math.unl.edu Mon Feb 26 15:42:04 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Feb 2007 09:42:04 -0600 Subject: [Fedora-packaging] Re: Executable documentation In-Reply-To: <45E2FE48.4090702@city-fan.org> References: <45E2FA3C.7010707@math.unl.edu> <45E2FAD9.4050000@city-fan.org> <45E2FC32.6020706@math.unl.edu> <45E2FE48.4090702@city-fan.org> Message-ID: <45E2FFCC.9090109@math.unl.edu> Paul Howarth wrote: > Rex Dieter wrote: >>> What's wrong with having them under %_docdir? >> I was speaking in the context of binary executables, and putting them >> under %_datadir doesn't mesh with the intent of arch-independent data >> and the FHS. > So noarch stuff like perl scripts would be OK? sounds ok to me. -- Rex From notting at redhat.com Mon Feb 26 15:45:02 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 26 Feb 2007 10:45:02 -0500 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <1172496449.25220.0.camel@cutter> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <1172496449.25220.0.camel@cutter> Message-ID: <20070226154502.GA24950@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > > Any chance of getting all non-Free firmware to Require: some empty > > package (say freedom-loss or proprietary-crap :-) such that: > > > > - one could yum erase this package and end up without any non-Free > > Software installed, and > > > > - one could easily veirfy that custom distros with a subset of the > > complete Fedora package set don't include any such proprietary > > packages? > > I actually like this idea. Isn't it easy enough to query by license? Bill From katzj at redhat.com Mon Feb 26 16:04:57 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Feb 2007 11:04:57 -0500 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: References: <20070223042424.GA23898@nostromo.devel.redhat.com> Message-ID: <1172505897.12387.8.camel@erebor.boston.redhat.com> On Mon, 2007-02-26 at 04:29 -0300, Alexandre Oliva wrote: > On Feb 23, 2007, Bill Nottingham wrote: > > 1) Firmware packages are given the Group: tag of Firmware > > > 2) The License tag for any firmware that disallows modification should > > be set to: > > > "Redistributable firmware, no modification permitted" > > Any chance of getting all non-Free firmware to Require: some empty > package (say freedom-loss or proprietary-crap :-) such that: > > - one could yum erase this package and end up without any non-Free > Software installed, and > > - one could easily veirfy that custom distros with a subset of the > complete Fedora package set don't include any such proprietary > packages? The entire goal of standardizing on a specific license tag be used is that it's easy to have a simple script for query/removing/installing or whatnot and _not_ have to do magic packages like this. Maintaining such a package is always and without fail an absolute nitemare to do. Jeremy From notting at redhat.com Mon Feb 26 16:48:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 26 Feb 2007 11:48:16 -0500 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <20070223190837.GH21659@neu.nirvana> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223093212.GA6561@neu.nirvana> <20070223173601.GB2648@nostromo.devel.redhat.com> <20070223190837.GH21659@neu.nirvana> Message-ID: <20070226164816.GB24833@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > > Moreover, by changing the name, you break the 'follow-upstream' > > part of the packaging guidelines. > > I just say perl-, python-, php-*-, blah-plugin-foo, ruby-, java- and > lowercasing, not to mention *-kmod and kmod-*. We're not really > following upstream even if the guidelines claim that. It would be > interesting to see how many packages are really named according to > upstream rules. True. I suppose having them named firmware-* makes it easier for pakcage installers & manifests as well, so they can glob it. Bill From ville.skytta at iki.fi Mon Feb 26 17:27:48 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 26 Feb 2007 19:27:48 +0200 Subject: [Fedora-packaging] Re: Firmware packaging, v2 In-Reply-To: <20070226164816.GB24833@nostromo.devel.redhat.com> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070223190837.GH21659@neu.nirvana> <20070226164816.GB24833@nostromo.devel.redhat.com> Message-ID: <200702261927.49343.ville.skytta@iki.fi> On Monday 26 February 2007, Bill Nottingham wrote: > > True. I suppose having them named firmware-* makes it easier for > pakcage installers & manifests as well, so they can glob it. *-firmware would sound better to me [1]. It would have the slight drawback that all firmware packages wouldn't sit next to each other in alphabetical listings, but... shrug. [1] Usually roughly foo-bar: "bar" for "foo", bar-foo: "foo" for "bar" From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 26 17:33:10 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 26 Feb 2007 18:33:10 +0100 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <20070223042424.GA23898@nostromo.devel.redhat.com> References: <20070223042424.GA23898@nostromo.devel.redhat.com> Message-ID: <20070226183310.49f16057@python3.es.egwn.lan> Bill Nottingham wrote : > Just a minor edit to the previous proposal. > > I'd like the firmware section of the packaging guidelines modified > to add: > > 1) Firmware packages are given the Group: tag of Firmware > > 2) The License tag for any firmware that disallows modification should > be set to: > > "Redistributable firmware, no modification permitted" > > I'd write something for the PackagingDrafts, but it's locked down. > Can we get this approved? I just caught up on the entire discussion... here's my own POV : - I don't really care about the License nor Group tags content. - The "firmware-" prefixing idea isn't bad, although "-firmware" postfixing sort of like "-libs" or "-devel" follows normal sentences some more ("the foo firmware" -> foo-firmware), so I'd tend to prefer that. Just another question : Intel has named its latest released file a "microcode"... is there any major difference with what "firmware" refers to? (I don't really know) If not, or not much, "firmware" definitely still makes more sense, especially given the install location of the files... /lib/firmware/ :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.07 0.10 0.17 From mattdm at mattdm.org Mon Feb 26 17:40:54 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 26 Feb 2007 12:40:54 -0500 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <1172505897.12387.8.camel@erebor.boston.redhat.com> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <1172505897.12387.8.camel@erebor.boston.redhat.com> Message-ID: <20070226174054.GA28954@jadzia.bu.edu> On Mon, Feb 26, 2007 at 11:04:57AM -0500, Jeremy Katz wrote: > > Any chance of getting all non-Free firmware to Require: some empty > > package (say freedom-loss or proprietary-crap :-) such that: > > - one could yum erase this package and end up without any non-Free > > Software installed, and > > - one could easily veirfy that custom distros with a subset of the > > complete Fedora package set don't include any such proprietary > > packages? > The entire goal of standardizing on a specific license tag be used is > that it's easy to have a simple script for query/removing/installing or > whatnot and _not_ have to do magic packages like this. Maintaining such > a package is always and without fail an absolute nitemare to do. Except, this magical package is backwards from the typical "metapackage" kludge -- other things require *it*, rather than the other way around. So it requires very very little maintenance. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 26 18:15:37 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 26 Feb 2007 19:15:37 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070217034851.GB13491@neu.nirvana> References: <200702161800.40666.jkeating@redhat.com> <20070217034851.GB13491@neu.nirvana> Message-ID: <20070226191537.553edbb2@python3.es.egwn.lan> Axel Thimm wrote : > On Fri, Feb 16, 2007 at 07:15:22PM -0600, Rex Dieter wrote: > > Jason L Tibbitts III wrote: > > > Here's another possibly related question I found while grepping > > > through core package specs: > > > > > > Do we care about use of %{_initrddir} versus > > > %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other? > > > > imo, the former, since that is precisely what it exists for. > > While at it could we have the typo in the macro fixed? We can keep the > old one indefinitely around for compatibility's sake. Yeah, *please* don't go deciding to use a macro which has a broken and confusing name. I'd suggest either : - Using /etc/rc.d/init.d/foo "hardcoded" in %files (as Bill writes, the path is pretty much written in stone). - Using a new "fixed" macro for people who want that (useless?) warm fuzzy feeling lines beginning with "%" give them. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.13 0.12 0.15 From Axel.Thimm at ATrpms.net Mon Feb 26 18:28:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Feb 2007 19:28:20 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070226191537.553edbb2@python3.es.egwn.lan> References: <200702161800.40666.jkeating@redhat.com> <20070217034851.GB13491@neu.nirvana> <20070226191537.553edbb2@python3.es.egwn.lan> Message-ID: <20070226182820.GM8225@neu.nirvana> On Mon, Feb 26, 2007 at 07:15:37PM +0100, Matthias Saou wrote: > Axel Thimm wrote : > > > On Fri, Feb 16, 2007 at 07:15:22PM -0600, Rex Dieter wrote: > > > Jason L Tibbitts III wrote: > > > > Here's another possibly related question I found while grepping > > > > through core package specs: > > > > > > > > Do we care about use of %{_initrddir} versus > > > > %{_sysconfdir}/rc.d/init.d/? Is one preferred over the other? > > > > > > imo, the former, since that is precisely what it exists for. > > > > While at it could we have the typo in the macro fixed? We can keep the > > old one indefinitely around for compatibility's sake. > > Yeah, *please* don't go deciding to use a macro which has a broken and > confusing name. I'd suggest either : > - Using /etc/rc.d/init.d/foo "hardcoded" in %files (as Bill writes, the > path is pretty much written in stone). Well, /usr and /etc are even deeper carved in that stone, but we wouldn't conclude that using the respective macros is therefore even less important. > - Using a new "fixed" macro for people who want that (useless?) warm > fuzzy feeling lines beginning with "%" give them. I vote for +%_initdir %{_sysconfdir}/rc.d/init.d +# ancient typo kept for compatibily purposes %_initrddir %{_sysconfdir}/rc.d/init.d It's the natural naming and already in use at several places besides ATrpms: http://www.google.com/search?q=_initdir+-site%3Aatrpms.net -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Feb 26 18:33:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 26 Feb 2007 19:33:44 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070226182820.GM8225@neu.nirvana> References: <200702161800.40666.jkeating@redhat.com> <20070217034851.GB13491@neu.nirvana> <20070226191537.553edbb2@python3.es.egwn.lan> <20070226182820.GM8225@neu.nirvana> Message-ID: <1172514824.19863.1.camel@rousalka.dyndns.org> Le lundi 26 f?vrier 2007 ? 19:28 +0100, Axel Thimm a ?crit : > I vote for > > +%_initdir %{_sysconfdir}/rc.d/init.d > +# ancient typo kept for compatibily purposes > %_initrddir %{_sysconfdir}/rc.d/init.d I vote for waiting till the new init system in F8 makes it clear if %{_sysconfdir}/rc.d/init.d will even be used anymore -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 26 18:35:20 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 26 Feb 2007 19:35:20 +0100 Subject: [Fedora-packaging] Requires(post{,un}) on something in coreutils In-Reply-To: <20070209193032.GH1706@redhat.com> References: <20070209193032.GH1706@redhat.com> Message-ID: <20070226193520.401f7f40@python3.es.egwn.lan> Andrew Overholt wrote : > Are Requires(post{,un}) needed for things in coreutils? >From the rest of the discussion, the answer seems to be "yes" as of today. But what you'd want for tomorrow is having the dependencies from a run of "bash --rpm-requires" on the scriplets be automatically added to the package's Requires(...). It's pretty silly to still be doing all of these pre/post/... requirements manually, especially given that the vast majority of scriplets are the default (shell), and that the mechanism to fix this as been there for ages in both bash and rpm... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.14 0.17 0.17 From nicolas.mailhot at laposte.net Mon Feb 26 18:37:15 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 26 Feb 2007 19:37:15 +0100 Subject: [Fedora-packaging] Firmware packaging, v2 In-Reply-To: <20070226183310.49f16057@python3.es.egwn.lan> References: <20070223042424.GA23898@nostromo.devel.redhat.com> <20070226183310.49f16057@python3.es.egwn.lan> Message-ID: <1172515035.19863.4.camel@rousalka.dyndns.org> BTW, the package grouping need seems very similar to the one of the java folks. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Mon Feb 26 18:38:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Feb 2007 19:38:07 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <1172514824.19863.1.camel@rousalka.dyndns.org> References: <200702161800.40666.jkeating@redhat.com> <20070217034851.GB13491@neu.nirvana> <20070226191537.553edbb2@python3.es.egwn.lan> <20070226182820.GM8225@neu.nirvana> <1172514824.19863.1.camel@rousalka.dyndns.org> Message-ID: <20070226183807.GN8225@neu.nirvana> On Mon, Feb 26, 2007 at 07:33:44PM +0100, Nicolas Mailhot wrote: > Le lundi 26 f?vrier 2007 ? 19:28 +0100, Axel Thimm a ?crit : > > > I vote for > > > > +%_initdir %{_sysconfdir}/rc.d/init.d > > +# ancient typo kept for compatibily purposes > > %_initrddir %{_sysconfdir}/rc.d/init.d > > I vote for waiting till the new init system in F8 makes it clear if > %{_sysconfdir}/rc.d/init.d will even be used anymore Wouldn't the initfiles have to be installed somewhere? And in that case if we cater early enough we simply ship F8 with a new _initdir value pointing to the new preferred value. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Feb 26 18:52:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 13:52:01 -0500 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <200702161800.40666.jkeating@redhat.com> References: <200702161800.40666.jkeating@redhat.com> Message-ID: <200702261352.01316.jkeating@redhat.com> On Friday 16 February 2007 18:00, Jesse Keating wrote: > After repeated (heated) discussions over init scripts, I wanted to guideify > my thoughts (and others) on this. ?Can we have some discussion over this > draft and vote at next meeting? > > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts There seems to be a split as to whether or not these are config files. I could be convinced to allow them to be config (without noreplace) to preserve admin settings should they make any changes, but still allowing us to get new init files into place. If we go with this, we need to make rpmlint not balk about executables in /etc marked as config and such. I'd still prefer that these files aren't marked as %config. Perhaps a new init system will allow for us to place these files somewhere other than /etc and really drive the point home that these files are not for configuration. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Feb 26 19:00:14 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 26 Feb 2007 20:00:14 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070226183807.GN8225@neu.nirvana> References: <200702161800.40666.jkeating@redhat.com> <20070217034851.GB13491@neu.nirvana> <20070226191537.553edbb2@python3.es.egwn.lan> <20070226182820.GM8225@neu.nirvana> <1172514824.19863.1.camel@rousalka.dyndns.org> <20070226183807.GN8225@neu.nirvana> Message-ID: <1172516415.19863.7.camel@rousalka.dyndns.org> Le lundi 26 f?vrier 2007 ? 19:38 +0100, Axel Thimm a ?crit : > On Mon, Feb 26, 2007 at 07:33:44PM +0100, Nicolas Mailhot wrote: > > Le lundi 26 f?vrier 2007 ? 19:28 +0100, Axel Thimm a ?crit : > > > > > I vote for > > > > > > +%_initdir %{_sysconfdir}/rc.d/init.d > > > +# ancient typo kept for compatibily purposes > > > %_initrddir %{_sysconfdir}/rc.d/init.d > > > > I vote for waiting till the new init system in F8 makes it clear if > > %{_sysconfdir}/rc.d/init.d will even be used anymore > > Wouldn't the initfiles have to be installed somewhere? And in that > case if we cater early enough we simply ship F8 with a new _initdir > value pointing to the new preferred value. In that case it will be easier for everyone if the old macro points to the legacy init & the new to the new one, instead of muddying the waters with a premature change -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 26 19:00:55 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 26 Feb 2007 20:00:55 +0100 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <200702261352.01316.jkeating@redhat.com> References: <200702161800.40666.jkeating@redhat.com> <200702261352.01316.jkeating@redhat.com> Message-ID: <20070226200055.3ff2579e@python3.es.egwn.lan> Jesse Keating wrote : > I'd still prefer that these files aren't marked as %config. Perhaps a new > init system will allow for us to place these files somewhere other than /etc > and really drive the point home that these files are not for configuration. Same here. Those are scripts, not config files... and marking them as such encourages people to edit them, which is not a good idea, since those files mostly contain code and not configuration, thus a later version is much more likely to break. Not only because of changed configuration options, but because of changed interaction between the init script and what it runs (like renamed command line options for a daemon it starts, running a daemon as root which drop privileges alone or directly launching it as a user etc.). At worst, I'd force new packages to _never_ mark them as %config and leave existing packages with bits of config in their init script as they are, clearly identifying them somewhere in the wiki if necessary, until we switch to a new init system. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.44 0.25 0.19 From wart at kobold.org Mon Feb 26 19:01:23 2007 From: wart at kobold.org (Michael Thomas) Date: Mon, 26 Feb 2007 11:01:23 -0800 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <45D3A413.8040606@kobold.org> References: <45D3A413.8040606@kobold.org> Message-ID: <45E32E83.1030200@kobold.org> Would it be possible to add a discussion of this draft to the agenda for tomorrow's packaging meeting? I'd hate for it to be dead in the water due to lack of interest. --Wart Michael Thomas wrote: > I sent this proposal to f-m-l about a week ago to gather comments, and > there were no serious disagreements with the proposal which have not yet > been addressed (thanks to Tibbs and Toshio for their feedback). > > Basically, I want to establish a set of guidelines for packaging Tcl > extensions, as we already have guidelines for other popular scripting > languages. In addition to making Tcl packages more consistent with each > other, it will also help work toward fixing my pet-peeve bug (bz #226893) > > http://fedoraproject.org/wiki/PackagingDrafts/Tcl > > Please let me know if I need to do anything to help get these draft > guidelines adopted. > > Thanks, > > --Wart > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 26 19:13:54 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 26 Feb 2007 20:13:54 +0100 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <45D3A413.8040606@kobold.org> References: <45D3A413.8040606@kobold.org> Message-ID: <20070226201354.0bd51344@python3.es.egwn.lan> Michael Thomas wrote : > http://fedoraproject.org/wiki/PackagingDrafts/Tcl Quick comment : You should add the "= %{version}-%{release}" to the "Provides:" in your document. Otherwise, Tcl seems completely broken when it comes to multilib... [1] and you seem to be aware of the major issues as the TODO section shows. But it contains tasks so critical that I wouldn't bother trying to push these packaging rules forward until they are taken care of. For instance, replacing the "/usr/lib/tcl8.4 -> /usr/share/tcl8.4" symlink with a real directory is... errr... pretty much impossible for rpm to do. You might be able to hack around it, but it'll be ugly. Good luck! :-) Matthias [1] https://bugzilla.redhat.com/228177 -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.14 0.15 0.16 From rdieter at math.unl.edu Mon Feb 26 19:25:47 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Feb 2007 13:25:47 -0600 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <45E32E83.1030200@kobold.org> References: <45D3A413.8040606@kobold.org> <45E32E83.1030200@kobold.org> Message-ID: <45E3343B.9030007@math.unl.edu> Michael Thomas wrote: > Would it be possible to add a discussion of this draft to the agenda for > tomorrow's packaging meeting? I'd hate for it to be dead in the water > due to lack of interest. Afaik, the PC is generally in favor of the proposal, pending official buy-in/support from the Tcl maintainer. -- Rex From wart at kobold.org Mon Feb 26 19:50:19 2007 From: wart at kobold.org (Michael Thomas) Date: Mon, 26 Feb 2007 11:50:19 -0800 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <20070226201354.0bd51344@python3.es.egwn.lan> References: <45D3A413.8040606@kobold.org> <20070226201354.0bd51344@python3.es.egwn.lan> Message-ID: <45E339FB.7040404@kobold.org> Matthias Saou wrote: > Michael Thomas wrote : > >> http://fedoraproject.org/wiki/PackagingDrafts/Tcl > > Quick comment : You should add the "= %{version}-%{release}" to the > "Provides:" in your document. Fixed. > Otherwise, Tcl seems completely broken when it comes to multilib... [1] > and you seem to be aware of the major issues as the TODO section shows. > But it contains tasks so critical that I wouldn't bother trying to push > these packaging rules forward until they are taken care of. For > instance, replacing the "/usr/lib/tcl8.4 -> /usr/share/tcl8.4" > symlink with a real directory is... errr... pretty much impossible for > rpm to do. You might be able to hack around it, but it'll be ugly. > > Good luck! :-) > Matthias > > [1] https://bugzilla.redhat.com/228177 Yes, multilib is broken in Tcl, partially because of the symbolic link from /usr/lib/tcl8.4 -> /usr/share/tcl8.4. Even on x86_64, the link is /usr/lib, not /usr/lib64. The tk spec file used to do the same thing, but it was fixed by adding a scriptlet in %pre to remove the symlink: [ ! -h %{_prefix}/%{_lib}/%{name}%{majorver} ] || rm %{_prefix}/%{_lib}/%{name}%{majorver} I presume the same could be done with Tcl. There's really one main task that needs to be done before tcl extensions could be modified for the new guidelines, and that is to add %{_libdir}/tcl%{majorver} to the default package path. This is trivially fixed by modifying one of the patches in the tcl package, but I haven't been able to convince the Tcl maintainer to include it yet. I think that this, along with the symbolic link problem, will fix the multilib problem, since all arch-specific extensions will now be installed into %{_libdir}/tcl%{majorver} instead of %{_datadir}/tcl%{majorver}. --Wart From sander at hoentjen.eu Mon Feb 26 19:57:12 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Mon, 26 Feb 2007 20:57:12 +0100 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <20070226201354.0bd51344@python3.es.egwn.lan> References: <45D3A413.8040606@kobold.org> <20070226201354.0bd51344@python3.es.egwn.lan> Message-ID: <1172519832.10152.1.camel@peecee.hoentjen.eu> On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote: > Michael Thomas wrote : > > > http://fedoraproject.org/wiki/PackagingDrafts/Tcl > > Quick comment : You should add the "= %{version}-%{release}" to the > "Provides:" in your document. > > Otherwise, Tcl seems completely broken when it comes to multilib... [1] > and you seem to be aware of the major issues as the TODO section shows. > But it contains tasks so critical that I wouldn't bother trying to push > these packaging rules forward until they are taken care of. For > instance, replacing the "/usr/lib/tcl8.4 -> /usr/share/tcl8.4" > symlink with a real directory is... errr... pretty much impossible for > rpm to do. You might be able to hack around it, but it'll be ugly. I thought about it and it might be best if this was done during the move to 8.5. That way you don't really have to deal with it, the first 8.5 package just has to use the new way. From ville.skytta at iki.fi Mon Feb 26 20:04:50 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 26 Feb 2007 22:04:50 +0200 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <200702261352.01316.jkeating@redhat.com> References: <200702161800.40666.jkeating@redhat.com> <200702261352.01316.jkeating@redhat.com> Message-ID: <200702262204.51251.ville.skytta@iki.fi> On Monday 26 February 2007, Jesse Keating wrote: > I'd still prefer that these files aren't marked as %config. +1 > Perhaps a new > init system will allow for us to place these files somewhere other than > /etc and really drive the point home that these files are not for > configuration. Just a FYI, LSB doesn't obviously necessarily apply to everything, but here's some related pointers, they seem to be thinking about related things for future LSB revisions. http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/etc.html http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbinstall.html And BTW, for what it's worth, it's /etc/init.d, not /etc/rc.d/init.d in LSB - so it might not hurt to treat /etc/init.d as the "canonical" path in Fedora wherever it is hardcoded into even though there is the symlink between the two. From tcallawa at redhat.com Mon Feb 26 20:17:57 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 26 Feb 2007 14:17:57 -0600 Subject: [Fedora-packaging] FE-Legal review In-Reply-To: References: Message-ID: <1172521077.21615.8.camel@localhost.localdomain> On Mon, 2007-02-26 at 02:25 -0700, Bernard Johnson wrote: > I've blocked a submitted package (ntop) on FE-Legal. I'm not sure who > to prod regarding "Apache License, Version 2.0, incompatible with GPL" > starting at comment 46. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219025#c46 > > If this is going to be a problem, it looks like I can remove the Apache > 2 files (patch them out). I'm assuming that is sufficient and a > modified tarball won't be needed. > > Since someone will ask: No, this is not documentation, it is javascript > used by the built-in web server. > > Can someone who does the FE-Legal reviews take a look at this for me? Yes, but I just got back to the US, and I'm really mentally and physically exhausted. I'll look at this sometime this week. ~spot From wart at kobold.org Mon Feb 26 22:27:31 2007 From: wart at kobold.org (Michael Thomas) Date: Mon, 26 Feb 2007 14:27:31 -0800 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <1172519832.10152.1.camel@peecee.hoentjen.eu> References: <45D3A413.8040606@kobold.org> <20070226201354.0bd51344@python3.es.egwn.lan> <1172519832.10152.1.camel@peecee.hoentjen.eu> Message-ID: <45E35ED3.6080708@kobold.org> Sander Hoentjen wrote: > On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote: >> Michael Thomas wrote : >> >>> http://fedoraproject.org/wiki/PackagingDrafts/Tcl >> Quick comment : You should add the "= %{version}-%{release}" to the >> "Provides:" in your document. >> >> Otherwise, Tcl seems completely broken when it comes to multilib... [1] >> and you seem to be aware of the major issues as the TODO section shows. >> But it contains tasks so critical that I wouldn't bother trying to push >> these packaging rules forward until they are taken care of. For >> instance, replacing the "/usr/lib/tcl8.4 -> /usr/share/tcl8.4" >> symlink with a real directory is... errr... pretty much impossible for >> rpm to do. You might be able to hack around it, but it'll be ugly. > > I thought about it and it might be best if this was done during the move > to 8.5. That way you don't really have to deal with it, the first 8.5 > package just has to use the new way. Yes, the 8.5 upgrade might be the best time to make the change with the link. The other two items above it in the list in the guidelines can still be done pre-8.5, though, and would allow existing extensions to be migrated to these new guidelines ahead of the 8.5 release. It would be nice to do the upgrade to 8.5 before F7, but upstream is not very responsive on giving updated estimates on the final 8.5 release date. :( --Wart From Axel.Thimm at ATrpms.net Tue Feb 27 16:12:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 27 Feb 2007 17:12:48 +0100 Subject: [Fedora-packaging] Re: Stopping the mandatory buildroot insanity In-Reply-To: <20070222202138.GC2096@neu.nirvana> References: <20070220102111.GA30283@neu.nirvana> <20070222202138.GC2096@neu.nirvana> Message-ID: <20070227161248.GD3516@neu.nirvana> On Thu, Feb 22, 2007 at 09:21:38PM +0100, Axel Thimm wrote: > spot asked me to draft something in the wiki about pushing all > responsibility to (grown-up) packagers while still presenting a couple > of sane buildroots as a guideline. > > The outcome is on http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot: Matthias Saou made some changes cleaning up my e-glish and clarifying the one and other bit. In case you had made up your mind already and don't want to feel like voting for something changing underneath your feet I placed the changed content bits underneath the original proposal, see also http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot?action=diff&rev2=4&rev1=3 > > [[Anchor(BuildRoot)]] > > == Build root tag == > > > > The ''Build``Root'' MUST be below %{_tmppath} and MUST use > > %{name}, %{version} and %{release}. It also may make use of > > ''mktemp'' since this is guaranteed to exist on any system. Other > > than that packagers are free to use any sane ''Build``Root''. => The ''!BuildRoot'' value MUST be below `%{_tmppath}/` and MUST contain at least `%{name}`, `%{version}` and `%{release}`. It may invoke `mktemp` since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''!BuildRoot''. > > The ''recommended'' values for the ''Build``Root'' tag are (in descending order of preference) > > {{{ > > %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) > > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > %{_tmppath}/%{name}-%{version}-%{release}-root > > }}} > > At one point, this was a mandatory value, but it is now left to the packager. => At one point, the second was a mandatory value, but it is now left to the packager to decide. If unsure, simply pick the first. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 16:43:08 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 17:43:08 +0100 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <45E35ED3.6080708@kobold.org> References: <45D3A413.8040606@kobold.org> <20070226201354.0bd51344@python3.es.egwn.lan> <1172519832.10152.1.camel@peecee.hoentjen.eu> <45E35ED3.6080708@kobold.org> Message-ID: <20070227174308.31f7ec90@python3.es.egwn.lan> Michael Thomas wrote : > Sander Hoentjen wrote: > > On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote: > >> Michael Thomas wrote : > >> > >>> http://fedoraproject.org/wiki/PackagingDrafts/Tcl > >> Quick comment : You should add the "= %{version}-%{release}" to the > >> "Provides:" in your document. > >> > >> Otherwise, Tcl seems completely broken when it comes to multilib... [1] > >> and you seem to be aware of the major issues as the TODO section shows. > >> But it contains tasks so critical that I wouldn't bother trying to push > >> these packaging rules forward until they are taken care of. For > >> instance, replacing the "/usr/lib/tcl8.4 -> /usr/share/tcl8.4" > >> symlink with a real directory is... errr... pretty much impossible for > >> rpm to do. You might be able to hack around it, but it'll be ugly. > > > > I thought about it and it might be best if this was done during the move > > to 8.5. That way you don't really have to deal with it, the first 8.5 > > package just has to use the new way. > > Yes, the 8.5 upgrade might be the best time to make the change with the > link. The other two items above it in the list in the guidelines can > still be done pre-8.5, though, and would allow existing extensions to be > migrated to these new guidelines ahead of the 8.5 release. > > It would be nice to do the upgrade to 8.5 before F7, but upstream is not > very responsive on giving updated estimates on the final 8.5 release > date. :( Actually, the "merge review" might be good for the change, and I see you're actively participating in it. I've made this bug depend on it, since I have "metakit" containing a tcl shared library which needs this fixed : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228177 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.39 0.28 0.20 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 16:45:19 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 17:45:19 +0100 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <200702262204.51251.ville.skytta@iki.fi> References: <200702161800.40666.jkeating@redhat.com> <200702261352.01316.jkeating@redhat.com> <200702262204.51251.ville.skytta@iki.fi> Message-ID: <20070227174519.5e5d77f7@python3.es.egwn.lan> Ville Skytt? wrote : > And BTW, for what it's worth, it's /etc/init.d, not /etc/rc.d/init.d in LSB - > so it might not hurt to treat /etc/init.d as the "canonical" path in Fedora > wherever it is hardcoded into even though there is the symlink between the > two. Argh! I could have sworn I had read the opposite somewhere, and have been changing my spec files ever since. Here too, we need to document clearly which one we should use, even though the symlink won't be removed anytime soon... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.33 0.27 0.20 From Axel.Thimm at ATrpms.net Tue Feb 27 16:56:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 27 Feb 2007 17:56:25 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070227174519.5e5d77f7@python3.es.egwn.lan> References: <200702161800.40666.jkeating@redhat.com> <200702261352.01316.jkeating@redhat.com> <200702262204.51251.ville.skytta@iki.fi> <20070227174519.5e5d77f7@python3.es.egwn.lan> Message-ID: <20070227165625.GG3516@neu.nirvana> On Tue, Feb 27, 2007 at 05:45:19PM +0100, Matthias Saou wrote: > Ville Skytt? wrote : > > > And BTW, for what it's worth, it's /etc/init.d, not /etc/rc.d/init.d in LSB - > > so it might not hurt to treat /etc/init.d as the "canonical" path in Fedora > > wherever it is hardcoded into even though there is the symlink between the > > two. > > Argh! I could have sworn I had read the opposite somewhere, Me, too. Obviously not from the LSB, I wonder where we picked that up? > and have been changing my spec files ever since. Here too, we need > to document clearly which one we should use, even though the symlink > won't be removed anytime soon... Change them to use %{_initdir} and have redhat-rpm-config's maintainer fix it. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Feb 27 17:00:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Feb 2007 12:00:06 -0500 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <20070227174519.5e5d77f7@python3.es.egwn.lan> References: <200702161800.40666.jkeating@redhat.com> <200702261352.01316.jkeating@redhat.com> <200702262204.51251.ville.skytta@iki.fi> <20070227174519.5e5d77f7@python3.es.egwn.lan> Message-ID: <20070227170006.GB24137@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > Argh! I could have sworn I had read the opposite somewhere, and have > been changing my spec files ever since. Here too, we need to document > clearly which one we should use, even though the symlink won't be > removed anytime soon... Not won't, *can't*. If you want to remove the symlink, you need a compatibility symlink in the other way. At that point, you have 1) a package that moves its script from /etc/rc.d/init.d -> /etc/init.d 2) a package that removes the /etc/init.d symlink and replaces it with the directory. Watch the RPM state machine.... 1) Processing upgrade of package foo.. /etc/init.d/foo <- new file in new path, will write /etc/rc.d/init.d/foo <- old file in old directory, will remove 2) Pre transaction: /etc/init.d symlink removed, /etc/rc.d/init.d directory moved to /etc/init.d. /etc/rc.d/init.d symlink created 3) Transaction is run /etc/init.d/foo is written /etc/rc.d/init.d/foo is removed - Oops, that follows the symlink and we remove the file we just wrote. Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 17:01:43 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 18:01:43 +0100 Subject: [Fedora-packaging] Re: Draft: Init Scripts In-Reply-To: <20070227165625.GG3516@neu.nirvana> References: <200702161800.40666.jkeating@redhat.com> <200702261352.01316.jkeating@redhat.com> <200702262204.51251.ville.skytta@iki.fi> <20070227174519.5e5d77f7@python3.es.egwn.lan> <20070227165625.GG3516@neu.nirvana> Message-ID: <20070227180143.06c3b296@python3.es.egwn.lan> Axel Thimm wrote : > On Tue, Feb 27, 2007 at 05:45:19PM +0100, Matthias Saou wrote: > > Ville Skytt? wrote : > > > > > And BTW, for what it's worth, it's /etc/init.d, not /etc/rc.d/init.d in LSB - > > > so it might not hurt to treat /etc/init.d as the "canonical" path in Fedora > > > wherever it is hardcoded into even though there is the symlink between the > > > two. > > > > Argh! I could have sworn I had read the opposite somewhere, > > Me, too. Obviously not from the LSB, I wonder where we picked that up? > > > and have been changing my spec files ever since. Here too, we need > > to document clearly which one we should use, even though the symlink > > won't be removed anytime soon... > > Change them to use %{_initdir} and have redhat-rpm-config's maintainer > fix it. :) I usually don't do this, but : +1 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.80 0.36 0.23 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 17:07:13 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 18:07:13 +0100 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <20070227170006.GB24137@nostromo.devel.redhat.com> References: <200702161800.40666.jkeating@redhat.com> <200702261352.01316.jkeating@redhat.com> <200702262204.51251.ville.skytta@iki.fi> <20070227174519.5e5d77f7@python3.es.egwn.lan> <20070227170006.GB24137@nostromo.devel.redhat.com> Message-ID: <20070227180713.210ceb53@python3.es.egwn.lan> Bill Nottingham wrote : > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > Argh! I could have sworn I had read the opposite somewhere, and have > > been changing my spec files ever since. Here too, we need to document > > clearly which one we should use, even though the symlink won't be > > removed anytime soon... > > Not won't, *can't*. > > If you want to remove the symlink, you need a compatibility symlink > in the other way. Hehe, but you're thinking in terms of today's rpm. Discussing stuff with Jeff at the FOSDEM this week-end, he already has a way of dealing with this well known limitation, which (from what I've understood) would basically be a "pre everything" approach. A similar "post everything" approach and a little magic could also nicely solve the icon caches, mime types, menus etc. performance problems. Which is why I didn't say "never", but "anytime soon" ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.29 0.29 0.21 From notting at redhat.com Tue Feb 27 17:33:12 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Feb 2007 12:33:12 -0500 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <20070227180713.210ceb53@python3.es.egwn.lan> References: <200702161800.40666.jkeating@redhat.com> <200702261352.01316.jkeating@redhat.com> <200702262204.51251.ville.skytta@iki.fi> <20070227174519.5e5d77f7@python3.es.egwn.lan> <20070227170006.GB24137@nostromo.devel.redhat.com> <20070227180713.210ceb53@python3.es.egwn.lan> Message-ID: <20070227173312.GB24834@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > Hehe, but you're thinking in terms of today's rpm. Discussing stuff > with Jeff at the FOSDEM this week-end, he already has a way of dealing > with this well known limitation, which (from what I've understood) would > basically be a "pre everything" approach. A similar "post everything" > approach and a little magic could also nicely solve the icon caches, > mime types, menus etc. performance problems. Well, the approach I posted was what happens *with* pre-transaction syscalls, as they were implemented by Jeff. What needs to happen is that the pre-transaction stuff needs to run before the transaction is even computed, which makes it messy. Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 17:42:43 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 18:42:43 +0100 Subject: [Fedora-packaging] Draft: Init Scripts In-Reply-To: <20070227173312.GB24834@nostromo.devel.redhat.com> References: <200702161800.40666.jkeating@redhat.com> <200702261352.01316.jkeating@redhat.com> <200702262204.51251.ville.skytta@iki.fi> <20070227174519.5e5d77f7@python3.es.egwn.lan> <20070227170006.GB24137@nostromo.devel.redhat.com> <20070227180713.210ceb53@python3.es.egwn.lan> <20070227173312.GB24834@nostromo.devel.redhat.com> Message-ID: <20070227184243.2f5b9c63@python3.es.egwn.lan> Bill Nottingham wrote : > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > Hehe, but you're thinking in terms of today's rpm. Discussing stuff > > with Jeff at the FOSDEM this week-end, he already has a way of dealing > > with this well known limitation, which (from what I've understood) would > > basically be a "pre everything" approach. A similar "post everything" > > approach and a little magic could also nicely solve the icon caches, > > mime types, menus etc. performance problems. > > Well, the approach I posted was what happens *with* pre-transaction > syscalls, as they were implemented by Jeff. What needs to happen is > that the pre-transaction stuff needs to run before the transaction > is even computed, which makes it messy. Not "pre transaction", but "pre everything" indeed. He mentioned that the idea was to fix exactly this scenario (from what I understood), but I didn't catch the details. Anyway, "not anytime soon" still stands, and even includes "never" ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.11 0.23 0.32 From wart at kobold.org Tue Feb 27 19:30:42 2007 From: wart at kobold.org (Wart) Date: Tue, 27 Feb 2007 11:30:42 -0800 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <20070227174308.31f7ec90@python3.es.egwn.lan> References: <45D3A413.8040606@kobold.org> <20070226201354.0bd51344@python3.es.egwn.lan> <1172519832.10152.1.camel@peecee.hoentjen.eu> <45E35ED3.6080708@kobold.org> <20070227174308.31f7ec90@python3.es.egwn.lan> Message-ID: <45E486E2.7000305@kobold.org> Matthias Saou wrote: > Michael Thomas wrote : > >> Sander Hoentjen wrote: >>> On Mon, 2007-02-26 at 20:13 +0100, Matthias Saou wrote: >>>> Michael Thomas wrote : >>>> >>>>> http://fedoraproject.org/wiki/PackagingDrafts/Tcl >>>> Quick comment : You should add the "= %{version}-%{release}" to the >>>> "Provides:" in your document. >>>> >>>> Otherwise, Tcl seems completely broken when it comes to multilib... [1] >>>> and you seem to be aware of the major issues as the TODO section shows. >>>> But it contains tasks so critical that I wouldn't bother trying to push >>>> these packaging rules forward until they are taken care of. For >>>> instance, replacing the "/usr/lib/tcl8.4 -> /usr/share/tcl8.4" >>>> symlink with a real directory is... errr... pretty much impossible for >>>> rpm to do. You might be able to hack around it, but it'll be ugly. >>> I thought about it and it might be best if this was done during the move >>> to 8.5. That way you don't really have to deal with it, the first 8.5 >>> package just has to use the new way. >> Yes, the 8.5 upgrade might be the best time to make the change with the >> link. The other two items above it in the list in the guidelines can >> still be done pre-8.5, though, and would allow existing extensions to be >> migrated to these new guidelines ahead of the 8.5 release. >> >> It would be nice to do the upgrade to 8.5 before F7, but upstream is not >> very responsive on giving updated estimates on the final 8.5 release >> date. :( > > Actually, the "merge review" might be good for the change, and I see > you're actively participating in it. I've made this bug depend on it, > since I have "metakit" containing a tcl shared library which needs this > fixed : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228177 I took a closer look at the metakit bug, and it seems that it's partially a bug in metakit, because it's using a hardcoded path to /usr/lib/tcl8.4 as its installation directory. I updated the bug report with additional notes on a workaround. Tcl's multilib support isn't actually broken, because it already looks for extensions in %{_libdir}. Only extensions that install into %{_libdir}/tcl8.4 will be broken for multilib, but they will have other problems because %{_libdir}/tcl8.4 isn't in Tcl's package path on x86_64 anyway. I'm glad you brought up the multilib issue, though. It's something that I hadn't considered, and is something that _will_ be broken by the draft guidelines until that symlink is removed. I've updated the guidelines to reflect that the symlink removal is now a _must_ item to fix. As I see it now, in order to adopt the draft guidelines, Bugs #227725 and #227200 need to be fixed. Is the merge review the correct place to fix these bugs? Would it be better to wait for Tcl 8.5, when many extensions will have to be rebuilt anyway? Should any of this be fixed in time for F7? (I think so) Are these questions better suited for f-m-l instead? --Wart From rdieter at math.unl.edu Tue Feb 27 19:36:43 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Feb 2007 13:36:43 -0600 Subject: [Fedora-packaging] Tcl packaging guidelines proposal In-Reply-To: <45E486E2.7000305@kobold.org> References: <45D3A413.8040606@kobold.org> <20070226201354.0bd51344@python3.es.egwn.lan> <1172519832.10152.1.camel@peecee.hoentjen.eu> <45E35ED3.6080708@kobold.org> <20070227174308.31f7ec90@python3.es.egwn.lan> <45E486E2.7000305@kobold.org> Message-ID: <45E4884B.7000506@math.unl.edu> Wart wrote: > As I see it now, in order to adopt the draft guidelines, Bugs #227725 > and #227200 need to be fixed. > > Is the merge review the correct place to fix these bugs? > > Would it be better to wait for Tcl 8.5, when many extensions will > have to be rebuilt anyway? > > Should any of this be fixed in time for F7? (I think so) > > Are these questions better suited for f-m-l instead? These last few questions, yes, imo. -- Rex From notting at redhat.com Tue Feb 27 20:00:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Feb 2007 15:00:42 -0500 Subject: [Fedora-packaging] Firmware packaging, v3 Message-ID: <20070227200042.GA3703@nostromo.devel.redhat.com> Changes: - don't worry about group - tweak license wording - use -firmware naming Here's the updated firmware packaging proposal. Comments? Can we get this approved - there are packages that meet the existing firmware guidelines that are waiting on packging guidelines for approval. Bill -------------- next part -------------- 1) The License tag for any firmware that disallows modification should be set to: "Redistributable, no modification permitted" 2) Firmware packages should be named -firmware, where is the driver or other hardware component that the firmware is for. From tibbs at math.uh.edu Wed Feb 28 05:06:10 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Feb 2007 23:06:10 -0600 Subject: [Fedora-packaging] Configuration files in /usr Message-ID: Any opinions on %config files in /usr? This seems to violate all sorts of common sense surrounding shared or read only /usr, but does not seem to be mentioned in the guidelines. An example package is hwdata: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225893 Patrice mentions in that bug that FHS covers us here, but the guideline only asks that deviations from FHS be rationalized. - J< From rc040203 at freenet.de Wed Feb 28 05:46:28 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 28 Feb 2007 06:46:28 +0100 Subject: [Fedora-packaging] Configuration files in /usr In-Reply-To: References: Message-ID: <1172641589.15418.73.camel@mccallum.corsepiu.local> On Tue, 2007-02-27 at 23:06 -0600, Jason L Tibbitts III wrote: > Any opinions on %config files in /usr? This seems to violate all > sorts of common sense surrounding shared or read only /usr, but does > not seem to be mentioned in the guidelines. This question seems overly simplistic to me. 1. "%config" doesn't necessarily mean this file to be a configuration file. It means, the packager has taken into account that users can have customized certain files and wants to play it nice to those users and wants to avoid trashing their work. It's essentially the same rationale, as why I consider FPC's decision to drop %config on init-scripts a fault. 2. There exist real (designed to be user-customizable) config files, which for traditional reasons live outside of /etc. Pedantically speaking these should not live outside of /etc, but in practice you can't change them, at least not easily and at least not "immediately". 3. There is a flaw/leak/gap inside of the FHS: /etc only covers "Host-specific system configuration" and doesn't cover "site-wide configuration", while /usr/share is supposed to take "arch-independent files". This has lead to problems when it comes to site-wide config files, because /etc definitely is not the correct place to put them. > An example package is hwdata: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225893 > > Patrice mentions in that bug that FHS covers us here, but the > guideline only asks that deviations from FHS be rationalized. In this particular case, I agree with the packager to make these files %config. Most users won't touch them, therefore won't see any effects. But those who touched them (E.g. because they add an usb-id for this freaking bleeding edge usb-device they just installed), will be grateful when rpm doesn't throw away their work on update. Ralf From fedora at leemhuis.info Wed Feb 28 06:31:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Feb 2007 07:31:36 +0100 Subject: [Fedora-packaging] Firmware packaging, v3 In-Reply-To: <20070227200042.GA3703@nostromo.devel.redhat.com> References: <20070227200042.GA3703@nostromo.devel.redhat.com> Message-ID: <45E521C8.50103@leemhuis.info> On 27.02.2007 21:00, Bill Nottingham wrote: > > - use -firmware naming > [...] > 2) Firmware packages should be named -firmware, where is the > driver or other hardware component that the firmware is for. I think it's totally confusing to have prefixes ( say {gnome,python,perl,kde,xfce,kmod,whatever}-foo) everywhere else, but use a postfix in this case. Sticking to one scheme would be nice. CU thl From nicolas.mailhot at laposte.net Wed Feb 28 06:49:49 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Feb 2007 07:49:49 +0100 Subject: [Fedora-packaging] Firmware packaging, v3 In-Reply-To: <45E521C8.50103@leemhuis.info> References: <20070227200042.GA3703@nostromo.devel.redhat.com> <45E521C8.50103@leemhuis.info> Message-ID: <1172645389.27148.27.camel@rousalka.dyndns.org> Le mercredi 28 f?vrier 2007 ? 07:31 +0100, Thorsten Leemhuis a ?crit : > On 27.02.2007 21:00, Bill Nottingham wrote: > > > > - use -firmware naming > > [...] > > 2) Firmware packages should be named -firmware, where is the > > driver or other hardware component that the firmware is for. > > I think it's totally confusing to have prefixes ( say > {gnome,python,perl,kde,xfce,kmod,whatever}-foo) everywhere else, but use > a postfix in this case. Sticking to one scheme would be nice. We're not having prefixes everywhere else, we have a huge postfix use. So far prefixes are mostly used to group different bits of the same thing while postfixes are more a categorisation, so firmware fits there nicely -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Wed Feb 28 07:24:05 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 28 Feb 2007 09:24:05 +0200 Subject: [Fedora-packaging] Firmware packaging, v3 In-Reply-To: <20070227200042.GA3703@nostromo.devel.redhat.com> References: <20070227200042.GA3703@nostromo.devel.redhat.com> Message-ID: <200702280924.05301.ville.skytta@iki.fi> On Tuesday 27 February 2007, Bill Nottingham wrote: > Here's the updated firmware packaging proposal. Comments? +1 From Axel.Thimm at ATrpms.net Wed Feb 28 08:08:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 28 Feb 2007 09:08:21 +0100 Subject: [Fedora-packaging] Re: Firmware packaging, v3 In-Reply-To: <200702280924.05301.ville.skytta@iki.fi> References: <20070227200042.GA3703@nostromo.devel.redhat.com> <200702280924.05301.ville.skytta@iki.fi> Message-ID: <20070228080821.GB20852@neu.nirvana> On Wed, Feb 28, 2007 at 09:24:05AM +0200, Ville Skytt? wrote: > On Tuesday 27 February 2007, Bill Nottingham wrote: > > > Here's the updated firmware packaging proposal. Comments? > > +1 +1 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 28 10:03:23 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 28 Feb 2007 11:03:23 +0100 Subject: [Fedora-packaging] Firmware packaging, v3 In-Reply-To: <1172645389.27148.27.camel@rousalka.dyndns.org> References: <20070227200042.GA3703@nostromo.devel.redhat.com> <45E521C8.50103@leemhuis.info> <1172645389.27148.27.camel@rousalka.dyndns.org> Message-ID: <20070228110323.3d4f1523@python3.es.egwn.lan> Nicolas Mailhot wrote : > Le mercredi 28 f?vrier 2007 ? 07:31 +0100, Thorsten Leemhuis a ?crit : > > On 27.02.2007 21:00, Bill Nottingham wrote: > > > > > > - use -firmware naming > > > [...] > > > 2) Firmware packages should be named -firmware, where is the > > > driver or other hardware component that the firmware is for. > > > > I think it's totally confusing to have prefixes ( say > > {gnome,python,perl,kde,xfce,kmod,whatever}-foo) everywhere else, but use > > a postfix in this case. Sticking to one scheme would be nice. > > We're not having prefixes everywhere else, we have a huge postfix use. > So far prefixes are mostly used to group different bits of the same > thing while postfixes are more a categorisation, so firmware fits there > nicely Yup. Think -devel, -libs, and also check what Ville already answered about this : "Usually roughly foo-bar: 'bar' for 'foo'", which I agree to and makes me prefer having "firmware" as the suffix. All of Bill's proposal looks fine to me. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.18 0.16 0.17 From pertusus at free.fr Wed Feb 28 10:33:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 28 Feb 2007 11:33:45 +0100 Subject: [Fedora-packaging] Configuration files in /usr In-Reply-To: <1172641589.15418.73.camel@mccallum.corsepiu.local> References: <1172641589.15418.73.camel@mccallum.corsepiu.local> Message-ID: <20070228103345.GA2903@free.fr> On Wed, Feb 28, 2007 at 06:46:28AM +0100, Ralf Corsepius wrote: > On Tue, 2007-02-27 at 23:06 -0600, Jason L Tibbitts III wrote: > > Any opinions on %config files in /usr? This seems to violate all > > sorts of common sense surrounding shared or read only /usr, but does > > not seem to be mentioned in the guidelines. > This question seems overly simplistic to me. > > 1. "%config" doesn't necessarily mean this file to be a configuration > file. It means, the packager has taken into account that users can have > customized certain files and wants to play it nice to those users and > wants to avoid trashing their work. What users should customize and what they shouldn't touch should be well separated in my opinion. Users should always be able to add their own customizations without touching the defaults which are set by the vendor/packager/upstream. Having %config files in %_datadir often means that there is no easy way to override the default conf. Marking those files %config might be better than nothing, but allowing users to override/add stuff is even better. > 3. There is a flaw/leak/gap inside of the FHS: /etc only covers > "Host-specific system configuration" and doesn't cover "site-wide > configuration", while /usr/share is supposed to take "arch-independent > files". This has lead to problems when it comes to site-wide config > files, because /etc definitely is not the correct place to put them. That's a good point, but in general this is not the real issue. It adds another location where apps using the config should search but at least some data/config files should be left under the vendor control. For a virtual example, we could have # vendor %_datadir/%name/the_data_or_conf.cnf # site wide %config(noreplace) %_datadir/%name/custom/the_data_or_conf.cnf # local %config(noreplace) %_sysconfdir/%name/the_data_or_conf.cnf > In this particular case, I agree with the packager to make these files > %config. Most users won't touch them, therefore won't see any effects. > But those who touched them (E.g. because they add an usb-id for this > freaking bleeding edge usb-device they just installed), will be grateful > when rpm doesn't throw away their work on update. It would be much better if the user could add this usb id in another file, be it in /etc for local customization or soewhere else below /usr for site-wide customization. In any case, I admit that I may be using the wrong argument (compliance to FHS) to chase another issue (no distinction between user and vendor data), because in most cases defaults are in %_datadir while customizations are in %_sysconfdir. And indeed I see no reason why we should necessarily ship only packages that separate clearly vendor and user config -- still it could be something we want to consider when doing reviews. As a first note, it is not always relevant to distinguish between vendor and user conf, in many case the vendor conf is of no use. As a second side note, there are cases where the vendor files are in %_sysconfdir but cannot be kept when customizing, losing the vendor defaults. In that case there may be something wrong though there won't be FHS/rpmlint warning issues. Last I think that hwdata falls in the case where distinction between vendor and user data is relevant. -- Pat From tcallawa at redhat.com Wed Feb 28 10:38:54 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 28 Feb 2007 04:38:54 -0600 Subject: [Fedora-packaging] Re: Firmware packaging, v3 In-Reply-To: <20070228080821.GB20852@neu.nirvana> References: <20070227200042.GA3703@nostromo.devel.redhat.com> <200702280924.05301.ville.skytta@iki.fi> <20070228080821.GB20852@neu.nirvana> Message-ID: <1172659134.6576.0.camel@localhost.localdomain> On Wed, 2007-02-28 at 09:08 +0100, Axel Thimm wrote: > On Wed, Feb 28, 2007 at 09:24:05AM +0200, Ville Skytt? wrote: > > On Tuesday 27 February 2007, Bill Nottingham wrote: > > > > > Here's the updated firmware packaging proposal. Comments? > > > > +1 > > +1 +1