From jonathan.underwood at gmail.com Fri Jun 1 23:57:25 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 2 Jun 2007 00:57:25 +0100 Subject: [Fedora-packaging] Packaging guidelines for Emacsen add-on packages In-Reply-To: <465F1224.5090203@math.unl.edu> References: <645d17210705070855j1c76a34eoc4f9f65cae2766ec@mail.gmail.com> <1180619950.6254.552.camel@localhost.localdomain> <645d17210705310721rea57446o344360b376e73837@mail.gmail.com> <200705312117.48993.ville.skytta@iki.fi> <465F1224.5090203@math.unl.edu> Message-ID: <645d17210706011657t2610d1fh7dece75cea9da2e7@mail.gmail.com> On 31/05/07, Rex Dieter wrote: > Ville Skytt? wrote: > > Instead, how about adding some pkgconfig files > > which are generated during build and thus we have complete control over their > > contents? > > Much better (or some other equivalent mechanism not involving rpm queries). OK, have filed a BZ requesting that this approach be adopted in Emacs. Once that is done we will be able to move forward. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242176 Until that bug, and this one: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239374 progress further, I don't think I can finish the draft, so there's no point bringing this before the packaging committee just yet. J. I don > > -- Rex > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From pertusus at free.fr Sat Jun 2 10:01:17 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 12:01:17 +0200 Subject: [Fedora-packaging] tricks for multilib proposal In-Reply-To: <20070527114637.GB3443@ryvius.pekin.waw.pl> References: <20070526130543.GD3105@free.fr> <20070527114637.GB3443@ryvius.pekin.waw.pl> Message-ID: <20070602100117.GG11101@free.fr> On Sun, May 27, 2007 at 01:46:37PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > How about http://fedoraproject.org/wiki/PackagingDrafts/Multilib ? I put it on http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks Comments welcome. -- Pat From rjones at redhat.com Sat Jun 2 14:21:32 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 02 Jun 2007 15:21:32 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <1180575644.20096.105.camel@localhost.localdomain> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> <465D86DE.8080505@redhat.com> <1180575644.20096.105.camel@localhost.localdomain> Message-ID: <46617CEC.3050404@redhat.com> Toshio Kuratomi wrote: > If you, G?rard, Hans, and the other people working on OCaml think the > guidelines are ready we can discuss and vote to include them at next > week's packaging meeting. The committee is meeting at Tuesday at 17:00 > UTC for about an hour in #fedora-meeting on freenode IRC. It's in my diary. >> (3) OCaml contains a native code compiler, but that compiler hasn't been >> ported to all architectures that Fedora supports. It has a bytecode >> compiler which works everywhere (but is interpreted and hence slow). I >> haven't been very careful about detecting if native code is supported on >> the current architecture. >> >> --> ExcludeArch and/or lots of nasty %ifarch sections in %files. >> >> --> I don't have a non-native arch to test on. >> > What's missing? ppc64? Is there a possibility of support being added > upstream? I can't think of any other packages/languages that have this > problem offhand. We may need to do something nasty with subpackages and > %ifarch but I'd rather avoid that if possible. I don't know how > possible that is, though. I ended up copying the solution that Debian use -- when building detect if ocamlopt (the native code compiler) is available. http://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=show#head-14a9d22bff07b51f58d01bb4e79bcbe98e426a7c I built four packages this way, testing on a "simulated" bytecode-only architecture. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From pertusus at free.fr Sat Jun 2 17:58:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 19:58:06 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs updated Message-ID: <20070602175806.GE2840@free.fr> Hello, Here is an updated version of the paragraph about shipping static numerical libs taking into account the comments on the first version. The objective is to have this included in http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges at the end of 'Packaging Static Libraries'. * in the case of user compiled programs doing numerical computations or data analysis, using static libraries may be useful. Indeed it allows to build static executables that have more chance to be run on other platforms than the box they were compiled in, that have different dynamic library versions or even that don't have the library installed at all. At the same time those applications, in general, don't need the features brought in by shared libraries (no need for nss, no security issue, no need for iconv...). Therefore it may be acceptable or even desirable to ship static libraries for numerical and data processing libraries to help users needing to link statically their locally compiled executables. The static libraries still need to be in separate sub-packages and this doesn't means that the executables packaged in Fedora should be link statically, this is only for users linking locally their own programs. Some packagers feel that this is not the right solution for locally compiled programs portability, since it is not general (doesn't work with nss, iconv...). However a general solution doesn't seems to exist yet. -- Pat From Axel.Thimm at ATrpms.net Sat Jun 2 18:13:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Jun 2007 20:13:08 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs updated In-Reply-To: <20070602175806.GE2840@free.fr> References: <20070602175806.GE2840@free.fr> Message-ID: <20070602181308.GI7159@neu.nirvana> On Sat, Jun 02, 2007 at 07:58:06PM +0200, Patrice Dumas wrote: > Hello, > > Here is an updated version of the paragraph about shipping static > numerical libs taking into account the comments on the first version. > > The objective is to have this included in > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges > > at the end of 'Packaging Static Libraries'. > > > * in the case of user compiled programs doing numerical computations or > data analysis, using static libraries may be useful. Indeed it allows > to build static executables that have more chance to be run on other > platforms than the box they were compiled in, that have different > dynamic library versions or even that don't have the library installed > at all. At the same time those applications, in general, don't need > the features brought in by shared libraries (no need for nss, no > security issue, no need for iconv...). Therefore it may be acceptable > or even desirable to ship static libraries for numerical and data > processing libraries to help users needing to link statically their > locally compiled executables. The static libraries still need to be > in separate sub-packages and this doesn't means that the executables > packaged in Fedora should be link statically, this is only for users > linking locally their own programs. > > Some packagers feel that this is not the right solution for locally > compiled programs portability, since it is not general (doesn't work > with nss, iconv...). However a general solution doesn't seems to exist > yet. > I like 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 tibbs at math.uh.edu Sat Jun 2 18:59:41 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jun 2007 13:59:41 -0500 Subject: [Fedora-packaging] paragraph on shipping static numerical libs updated In-Reply-To: <20070602175806.GE2840@free.fr> References: <20070602175806.GE2840@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> Here is an updated version of the paragraph about shipping PD> static numerical libs taking into account the comments on the PD> first version. I can get behind this. I have no problem with us shipping static libraries if it helps the users as long as we're not shipping statically linked programs. However, we certainly shouldn't try to "sell" static linking as a general solution, and I don't think this draft does. These two paragraphs can't just be pasted into the existing guidelines, however, as that would result in a somewhat contradictory text. I'd like to see the complete "Exclusion of Static Libraries" section (which will probably need a rename to continue making sense) before we vote on anything. I also wonder if it would be appropriate to include a statement that package submitters should explain in the spec the reason why static libraries are being packaged. - J< From Axel.Thimm at ATrpms.net Sat Jun 2 19:18:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Jun 2007 21:18:17 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs updated In-Reply-To: References: <20070602175806.GE2840@free.fr> Message-ID: <20070602191817.GL7159@neu.nirvana> On Sat, Jun 02, 2007 at 01:59:41PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> Here is an updated version of the paragraph about shipping > PD> static numerical libs taking into account the comments on the > PD> first version. > > I also wonder if it would be appropriate to include a statement that > package submitters should explain in the spec the reason why static > libraries are being packaged. I think this is nice OTOH, but difficult to foresee OTOH. Some libs are quite easy to identify as scientific/numeric consumable, but other non-numeric ones can also be required for the numerical application. -- 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 Jun 2 21:08:32 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jun 2007 16:08:32 -0500 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs updated In-Reply-To: <20070602191817.GL7159@neu.nirvana> References: <20070602175806.GE2840@free.fr> <20070602191817.GL7159@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> I think this is nice OTOH, but difficult to foresee OTOH. Well, at some point you have to know you need a static library, because you'll put the necessary bits in the spec to make it happen. I see no reason a comment explaining the need couldn't be added at that time. And if someone doesn't know that the static library is needed, it probably shouldn't be packaged. - J< From pertusus at free.fr Sat Jun 2 21:14:25 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 2 Jun 2007 23:14:25 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs updated In-Reply-To: References: <20070602175806.GE2840@free.fr> Message-ID: <20070602211424.GA5154@free.fr> On Sat, Jun 02, 2007 at 01:59:41PM -0500, Jason L Tibbitts III wrote: > > I also wonder if it would be appropriate to include a statement that > package submitters should explain in the spec the reason why static > libraries are being packaged. I think it should be in order, but I don't think it deserves to be said especially for this case, since in my opinion everytime there is deviation from the guidelines it should be explained in a comment. -- Pat From Axel.Thimm at ATrpms.net Sat Jun 2 21:19:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Jun 2007 23:19:32 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs updated In-Reply-To: References: <20070602175806.GE2840@free.fr> <20070602191817.GL7159@neu.nirvana> Message-ID: <20070602211932.GP7159@neu.nirvana> On Sat, Jun 02, 2007 at 04:08:32PM -0500, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> I think this is nice OTOH, but difficult to foresee OTOH. > > Well, at some point you have to know you need a static library, > because you'll put the necessary bits in the spec to make it happen. The problem is that the packager of libfoofastmem may not know that building the unpackaged supernumberbar and bazcrunch requires libfoofastmem. E.g. the people that know where a static lib is needed are not the packagers, but the consumers. > I see no reason a comment explaining the need couldn't be added at > that time. > > And if someone doesn't know that the static library is needed, it > probably shouldn't be packaged. The packager of libfoofastmem may not be interested in any numeric stuff at all, he may need libfoofastmem for a fuse tmpfs module and not ever having thought about other consumers. E.g. the knowledge to document the use of static libs implies that reverse build dependencies of unpackaged software are known to the consumed party, which must not be the case. -- 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 Jun 2 21:24:07 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jun 2007 16:24:07 -0500 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs updated In-Reply-To: <20070602211932.GP7159@neu.nirvana> References: <20070602175806.GE2840@free.fr> <20070602191817.GL7159@neu.nirvana> <20070602211932.GP7159@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> The problem is that the packager of libfoofastmem may not know AT> that building the unpackaged supernumberbar and bazcrunch requires AT> libfoofastmem. E.g. the people that know where a static lib is AT> needed are not the packagers, but the consumers. That line of reasoning leads to us shipping every static library we possibly can, just because something we don't know about might use it. Either the packager knows the static library is needed, or someone's going to have to tell them it's needed. - J< From Axel.Thimm at ATrpms.net Sat Jun 2 21:31:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Jun 2007 23:31:05 +0200 Subject: [Fedora-packaging] Re: paragraph on shipping static numerical libs updated In-Reply-To: References: <20070602175806.GE2840@free.fr> <20070602191817.GL7159@neu.nirvana> <20070602211932.GP7159@neu.nirvana> Message-ID: <20070602213105.GQ7159@neu.nirvana> On Sat, Jun 02, 2007 at 04:24:07PM -0500, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> The problem is that the packager of libfoofastmem may not know > AT> that building the unpackaged supernumberbar and bazcrunch requires > AT> libfoofastmem. E.g. the people that know where a static lib is > AT> needed are not the packagers, but the consumers. > > That line of reasoning leads to us shipping every static library we > possibly can, just because something we don't know about might use it. Yes, that's correct. > Either the packager knows the static library is needed, or someone's > going to have to tell them it's needed. Let's try this that way, e.g. act on demand. Maybe that should be briefly mentioned in the guideline as well: If users notice that they require a static lib they should contact the maintainer and give the reason both for the maintainer to decide, as well as for the comment. -- 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 Sun Jun 3 08:02:39 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 10:02:39 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs updated In-Reply-To: <20070602175806.GE2840@free.fr> References: <20070602175806.GE2840@free.fr> Message-ID: <1180857760.12595.514.camel@mccallum.corsepiu.local> On Sat, 2007-06-02 at 19:58 +0200, Patrice Dumas wrote: > Hello, > > Here is an updated version of the paragraph about shipping static > numerical libs taking into account the comments on the first version. > > The objective is to have this included in > > http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges > > at the end of 'Packaging Static Libraries'. > > > * in the case of user compiled programs doing numerical computations or > data analysis, using static libraries may be useful. Indeed it allows > to build static executables that have more chance to be run on other > platforms than the box they were compiled in, that have different > dynamic library versions or even that don't have the library installed > at all. At the same time those applications, in general, don't need > the features brought in by shared libraries (no need for nss, no > security issue, no need for iconv...). Therefore it may be acceptable > or even desirable to ship static libraries for numerical and data > processing libraries to help users needing to link statically their > locally compiled executables. The static libraries still need to be > in separate sub-packages and this doesn't means that the executables > packaged in Fedora should be link statically, this is only for users > linking locally their own programs. > > Some packagers feel that this is not the right solution for locally > compiled programs portability, since it is not general (doesn't work > with nss, iconv...). However a general solution doesn't seems to exist > yet. -1 1. This proposal is not in the distro's interest, because it causes additional bloat. 2. This proposal's focus on "numerical libs" is silly. It tries to implement a special exception into the FPC based on an application domain, while the problem actually is application domain independent. The real problem is: Cross-distro packaging of local packages, which some people (bogusly) try to approach static linkage. Ralf From pertusus at free.fr Sun Jun 3 10:02:25 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 3 Jun 2007 12:02:25 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs updated In-Reply-To: <1180857760.12595.514.camel@mccallum.corsepiu.local> References: <20070602175806.GE2840@free.fr> <1180857760.12595.514.camel@mccallum.corsepiu.local> Message-ID: <20070603100224.GG2826@free.fr> On Sun, Jun 03, 2007 at 10:02:39AM +0200, Ralf Corsepius wrote: > > -1 > > 1. This proposal is not in the distro's interest, because it causes > additional bloat. I forgot to add that, I'll do another try later. > 2. This proposal's focus on "numerical libs" is silly. > It tries to implement a special exception into the FPC based on an > application domain, while the problem actually is application domain > independent. > > The real problem is: Cross-distro packaging of local packages, which > some people (bogusly) try to approach static linkage. This issue is addressed by the new paragraph, isn't it? Anyway I don't care about not having it in the guidelines, I can put it in my personal page in the wiki (although such thing doesn't exist yet). It is not really an exception, since this exception is already accepted since FESCO ratified the original proposal (unless I missed something). It is more a precision. -- Pat From rc040203 at freenet.de Sun Jun 3 11:32:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 13:32:06 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs updated In-Reply-To: <20070603100224.GG2826@free.fr> References: <20070602175806.GE2840@free.fr> <1180857760.12595.514.camel@mccallum.corsepiu.local> <20070603100224.GG2826@free.fr> Message-ID: <1180870326.12595.560.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 12:02 +0200, Patrice Dumas wrote: > On Sun, Jun 03, 2007 at 10:02:39AM +0200, Ralf Corsepius wrote: > > > > -1 > > > > 1. This proposal is not in the distro's interest, because it causes > > additional bloat. > > I forgot to add that, I'll do another try later. > > > 2. This proposal's focus on "numerical libs" is silly. > > It tries to implement a special exception into the FPC based on an > > application domain, while the problem actually is application domain > > independent. > > > > The real problem is: Cross-distro packaging of local packages, which > > some people (bogusly) try to approach static linkage. > > This issue is addressed by the new paragraph, isn't it? * in the case of user compiled programs doing numerical computations or data analysis, using static libraries may be useful. You are explicitly referring to numerical computation or data analysis. This is silly. > Anyway I don't > care about not having it in the guidelines, I can put it in my personal > page in the wiki (although such thing doesn't exist yet). > > It is not really an exception, since this exception is already accepted > since FESCO ratified the original proposal (unless I missed something). > It is more a precision. No idea what FESCO did, if they agreed to it, they failed. Ralf From pertusus at free.fr Sun Jun 3 15:34:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 3 Jun 2007 17:34:24 +0200 Subject: [Fedora-packaging] paragraph on shipping static numerical libs updated In-Reply-To: <1180870326.12595.560.camel@mccallum.corsepiu.local> References: <20070602175806.GE2840@free.fr> <1180857760.12595.514.camel@mccallum.corsepiu.local> <20070603100224.GG2826@free.fr> <1180870326.12595.560.camel@mccallum.corsepiu.local> Message-ID: <20070603153424.GB2912@free.fr> On Sun, Jun 03, 2007 at 01:32:06PM +0200, Ralf Corsepius wrote: > > This issue is addressed by the new paragraph, isn't it? > > * in the case of user compiled programs doing numerical computations or > data analysis, using static libraries may be useful. > > > You are explicitly referring to numerical computation or data analysis. > > This is silly. That's because these are the cases where static libs may be usefull and shared libs are not needed. > No idea what FESCO did, if they agreed to it, they failed. The ratified http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges unless I am wrong (not my paragraph). -- Pat From a.badger at gmail.com Sun Jun 3 16:33:48 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 03 Jun 2007 09:33:48 -0700 Subject: [Fedora-packaging] Missing Packaging Meeting Message-ID: <1180888428.30126.46.camel@localhost.localdomain> I'll be in a training meeting and won't be able to make the meeting this Tuesday. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Mon Jun 4 23:04:37 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jun 2007 18:04:37 -0500 Subject: [Fedora-packaging] Modifying upstream tarballs Message-ID: I understand that there are circumstances where the upstream tarballs need to be modified to removed content which is patented or cannot be redistributed for some reason. However, should that be the extent of the permitted modifications? Take, for example, this comment from a current review ticket: #Original from http://membres.lycos.fr/agisite/prof.zip includes #copyrighted executables. Generated new source by unzipping, removing #DOS-related content, running dos2unix on the text file, and changing #all filenames to lowercase for agistudio compatibility. Now, everything except the removal of the executables could be done at %prep time in the spec, and that's how we'd insist that things be done in the normal case where the upstream tarball (or zipfile, in this case) needs no modification. - J< From jonathan.underwood at gmail.com Mon Jun 4 23:08:29 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 5 Jun 2007 00:08:29 +0100 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: References: Message-ID: <645d17210706041608k614b4f75w3449aebc16279d25@mail.gmail.com> On 04 Jun 2007 18:04:37 -0500, Jason L Tibbitts III wrote: > I understand that there are circumstances where the upstream tarballs > need to be modified to removed content which is patented or cannot be > redistributed for some reason. However, should that be the extent of > the permitted modifications? > > Take, for example, this comment from a current review ticket: > > #Original from http://membres.lycos.fr/agisite/prof.zip includes > #copyrighted executables. Generated new source by unzipping, removing > #DOS-related content, running dos2unix on the text file, and changing > #all filenames to lowercase for agistudio compatibility. > > Now, everything except the removal of the executables could be done at > %prep time in the spec, and that's how we'd insist that things be done > in the normal case where the upstream tarball (or zipfile, in this > case) needs no modification. I'm not sure I see what your point is - the website referred to in the comment is uninformative in the extreme. What's the BZ # for the review ticket? From tibbs at math.uh.edu Mon Jun 4 23:54:23 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jun 2007 18:54:23 -0500 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: <645d17210706041608k614b4f75w3449aebc16279d25@mail.gmail.com> References: <645d17210706041608k614b4f75w3449aebc16279d25@mail.gmail.com> Message-ID: >>>>> "JU" == Jonathan Underwood writes: JU> I'm not sure I see what your point is To ask the simple question stated in the first paragraph of my message: In the case that content must be removed from the upstream tarball, should the modifications be limited to the removal of the content or are other changes also allowed? JU> What's the BZ # for the review ticket? Well, it's immaterial to the question, but if it interests you, it's https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241761 - J< From jkeating at redhat.com Mon Jun 4 23:56:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 19:56:59 -0400 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: References: Message-ID: <200706041956.59324.jkeating@redhat.com> On Monday 04 June 2007 19:04:37 Jason L Tibbitts III wrote: > I understand that there are circumstances where the upstream tarballs > need to be modified to removed content which is patented or cannot be > redistributed for some reason. ?However, should that be the extent of > the permitted modifications? I would prefer it to just be the absolutely necessary changes, doing the rest later in the package. In the case that the inappropriate content goes away upstream, then we can immediately switch to an unmodified source. -- 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 Mon Jun 4 23:58:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 19:58:39 -0400 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: <200706041956.59324.jkeating@redhat.com> References: <200706041956.59324.jkeating@redhat.com> Message-ID: <200706041958.39391.jkeating@redhat.com> On Monday 04 June 2007 19:56:59 Jesse Keating wrote: > On Monday 04 June 2007 19:04:37 Jason L Tibbitts III wrote: > > I understand that there are circumstances where the upstream tarballs > > need to be modified to removed content which is patented or cannot be > > redistributed for some reason. ?However, should that be the extent of > > the permitted modifications? > > I would prefer it to just be the absolutely necessary changes, doing the > rest later in the package. In the case that the inappropriate content goes > away upstream, then we can immediately switch to an unmodified source. Oh, and it makes it far easier to verify the upstream vs what is in the package when only the necessary changes are made. If more and more changes are made it makes it more and more difficult to verify. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Tue Jun 5 00:39:29 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 04 Jun 2007 19:39:29 -0500 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: References: Message-ID: <1181003970.6254.643.camel@localhost.localdomain> On Mon, 2007-06-04 at 18:04 -0500, Jason L Tibbitts III wrote: > I understand that there are circumstances where the upstream tarballs > need to be modified to removed content which is patented or cannot be > redistributed for some reason. However, should that be the extent of > the permitted modifications? The only time we should be modifying tarballs is when the tarball would cause us to ship something in the SRPM that Fedora: - doesn't have permission to distribute - doesn't permit because of its license - would be violating known patents to ship In 99% of the other cases, leave the tarball alone and edit the content in the spec. ~spot From foolish at guezz.net Tue Jun 5 00:53:24 2007 From: foolish at guezz.net (Sindre Pedersen Bjordal) Date: Tue, 05 Jun 2007 02:53:24 +0200 Subject: [Fedora-packaging] Script to check gnomefiles.org for upstream updates Message-ID: <1181004804.13971.17.camel@localhost.localdomain> Hope this is the right list. Lots of upstream projects use gnomefiles.org, several of the packages I maintain use it to post news about updates. Gnomefiles.org offers a nice automatically generated XML document for accessing the version information. Inspired by the cpancheck.sh script for perl packages I wrote, with a lot of help from friendly people on irc, a script to check if packages maintained by a given user have version information on GnomeFiles and more importantly, if the version in fedora devel and GnomeFiles.org match. This way you can run this script and see if there's a new release of one of your packages. Like with the cpancheck.sh script you'll have to define your email, path to owners.list and path to your local Fedora cvsroot in the script itself. Script available here: http://folk.ntnu.no/sindrb/fedora/gnomefilescheck.sh Feedback very welcome, hope this is useful for someone besides me. -- Sindre Pedersen Bj?rdal - http://www.fedoraproject.org/wiki/SindrePedersenBjordal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From ville.skytta at iki.fi Tue Jun 5 06:24:26 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 5 Jun 2007 09:24:26 +0300 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: References: Message-ID: <200706050924.26347.ville.skytta@iki.fi> On Tuesday 05 June 2007, Jason L Tibbitts III wrote: > I understand that there are circumstances where the upstream tarballs > need to be modified to removed content which is patented or cannot be > redistributed for some reason. However, should that be the extent of > the permitted modifications? > > Take, for example, this comment from a current review ticket: [...] There are cases where further modifications are useful, eg. in order to eliminate build dependencies. But anyway, no matter what the changes to the tarballs/zipfiles/whatever are, just like in the case of tar'ing up cvs/svn/etc snapshots, all of them should be done with a script, and the script included in the source rpm plus a comment in the specfile like "SourceX generated from vanilla upstream tarball with SourceY". That helps everyone involved with the package. From Axel.Thimm at ATrpms.net Tue Jun 5 07:48:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 09:48:41 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: References: Message-ID: <20070605074841.GB23972@neu.nirvana> On Mon, Jun 04, 2007 at 06:04:37PM -0500, Jason L Tibbitts III wrote: > I understand that there are circumstances where the upstream tarballs > need to be modified to removed content which is patented or cannot be > redistributed for some reason. However, should that be the extent of > the permitted modifications? Yes, the pre-%prep preparations should be minimal and easily reproducable for the reviewer. Would you like to formulate a guideline change for voting upon? It seems like most people are on the same side, so it should be an easy item. > Take, for example, this comment from a current review ticket: > > #Original from http://membres.lycos.fr/agisite/prof.zip includes > #copyrighted executables. Generated new source by unzipping, removing > #DOS-related content, running dos2unix on the text file, and changing > #all filenames to lowercase for agistudio compatibility. > > Now, everything except the removal of the executables could be done at > %prep time in the spec, and that's how we'd insist that things be done > in the normal case where the upstream tarball (or zipfile, in this > case) needs no modification. > > - J< > -- 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 rjones at redhat.com Tue Jun 5 13:29:13 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 05 Jun 2007 14:29:13 +0100 Subject: [Fedora-packaging] Call rpm during rpmbuild Message-ID: <46656529.8030802@redhat.com> I'm right in thinking that it's bad to call rpm from rpmbuild? During my find-requires script, I need to get the exact name-version-release of the ocaml compiler. Obviously the compiler knows its name & version, but not its release. At the moment I'm doing: if [ -n "$emit_compiler_version" ]; then # Every OCaml program depends on the precise version of the # compiler which was used to compile it. rpm -q --qf '%{NAME} = %{VERSION}-%{RELEASE}\n' ocaml fi but if calling rpm like this is bad, I'm wondering how to fix it. Best way I can see to do this is to store the name-version-release of the compiler in a special file in the ocaml RPM, something like: /usr/lib64/ocaml/fedora-ocaml-release which would contain something like 3.09.0-3 or whatever, then the script can be changed to cat this file. What do people think? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rdieter at math.unl.edu Tue Jun 5 13:35:00 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Jun 2007 08:35:00 -0500 Subject: [Fedora-packaging] Call rpm during rpmbuild In-Reply-To: <46656529.8030802@redhat.com> References: <46656529.8030802@redhat.com> Message-ID: <46656684.5010906@math.unl.edu> Richard W.M. Jones wrote: > I'm right in thinking that it's bad to call rpm from rpmbuild? Yes. > but if calling rpm like this is bad, I'm wondering how to fix it. Best > way I can see to do this is to store the name-version-release of the > compiler in a special file in the ocaml RPM, something like: > > /usr/lib64/ocaml/fedora-ocaml-release > > which would contain something like 3.09.0-3 or whatever, then the script > can be changed to cat this file. This is workable, or possibly use pkg-config (as was proposed recently with emacs stuff). -- Rex From opensource at till.name Tue Jun 5 14:11:00 2007 From: opensource at till.name (Till Maas) Date: Tue, 05 Jun 2007 16:11:00 +0200 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: <1181003970.6254.643.camel@localhost.localdomain> References: <1181003970.6254.643.camel@localhost.localdomain> Message-ID: <200706051611.02217.opensource@till.name> On Di Juni 5 2007, Tom "spot" Callaway wrote: > The only time we should be modifying tarballs is when the tarball would > cause us to ship something in the SRPM that Fedora: > > - doesn't have permission to distribute > - doesn't permit because of its license > - would be violating known patents to ship > > In 99% of the other cases, leave the tarball alone and edit the content > in the spec. There are two packages I am working on, that contain binaries. Is it o.k. to keep them in the tarball / src.rpm? Regards, Till From tcallawa at redhat.com Tue Jun 5 14:09:49 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 05 Jun 2007 09:09:49 -0500 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: <200706051611.02217.opensource@till.name> References: <1181003970.6254.643.camel@localhost.localdomain> <200706051611.02217.opensource@till.name> Message-ID: <1181052589.6254.654.camel@localhost.localdomain> On Tue, 2007-06-05 at 16:11 +0200, Till Maas wrote: > On Di Juni 5 2007, Tom "spot" Callaway wrote: > > > The only time we should be modifying tarballs is when the tarball would > > cause us to ship something in the SRPM that Fedora: > > > > - doesn't have permission to distribute > > - doesn't permit because of its license > > - would be violating known patents to ship > > > > In 99% of the other cases, leave the tarball alone and edit the content > > in the spec. > > There are two packages I am working on, that contain binaries. Is it o.k. to > keep them in the tarball / src.rpm? If the binaries are under an OK for Fedora license, and it is clear that there is explicit permission to distribute (usually from the license), then, yes, it is fine, but you can't put them in the Binary RPM. ~spot From tcallawa at redhat.com Tue Jun 5 14:37:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 05 Jun 2007 09:37:25 -0500 Subject: [Fedora-packaging] Missing Packaging Meeting In-Reply-To: <1180888428.30126.46.camel@localhost.localdomain> References: <1180888428.30126.46.camel@localhost.localdomain> Message-ID: <1181054245.6254.665.camel@localhost.localdomain> On Sun, 2007-06-03 at 09:33 -0700, Toshio Kuratomi wrote: > I'll be in a training meeting and won't be able to make the meeting this > Tuesday. I'm also not going to be at the packaging meeting this week, sorry. I've got a lot of stuff that I need to handle before I move to Boston in July, so while I don't anticipate needing to miss any other meetings (other than in mid July when I'm driving from Chicago to Boston), the possibility exists. Apologies for the inconvenience. ~spot From Axel.Thimm at ATrpms.net Tue Jun 5 15:00:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 17:00:32 +0200 Subject: [Fedora-packaging] Re: Call rpm during rpmbuild In-Reply-To: <46656684.5010906@math.unl.edu> References: <46656529.8030802@redhat.com> <46656684.5010906@math.unl.edu> Message-ID: <20070605150032.GD23972@neu.nirvana> On Tue, Jun 05, 2007 at 08:35:00AM -0500, Rex Dieter wrote: > Richard W.M. Jones wrote: > >I'm right in thinking that it's bad to call rpm from rpmbuild? > > Yes. But weren't recursive rpm calls fixed many, many years ago, so that this is fine to use since ??? (hopefully including RHEL3)? -- 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 Jun 5 15:14:50 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Jun 2007 10:14:50 -0500 Subject: [Fedora-packaging] Re: Call rpm during rpmbuild In-Reply-To: <20070605150032.GD23972@neu.nirvana> References: <46656529.8030802@redhat.com> <46656684.5010906@math.unl.edu> <20070605150032.GD23972@neu.nirvana> Message-ID: <46657DEA.6050908@math.unl.edu> Axel Thimm wrote: > On Tue, Jun 05, 2007 at 08:35:00AM -0500, Rex Dieter wrote: >> Richard W.M. Jones wrote: >>> I'm right in thinking that it's bad to call rpm from rpmbuild? >> Yes. > > But weren't recursive rpm calls fixed many, many years ago, so that > this is fine to use since ??? (hopefully including RHEL3)? Stop the heresy, you'll raise spot's blood-pressure... :) In practice, it may or may not work (not more often than not, in chroot'd buildroots), but it's best to simply say "just don't do it". -- Rex From tcallawa at redhat.com Tue Jun 5 15:14:20 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 05 Jun 2007 10:14:20 -0500 Subject: [Fedora-packaging] Re: Call rpm during rpmbuild In-Reply-To: <46657DEA.6050908@math.unl.edu> References: <46656529.8030802@redhat.com> <46656684.5010906@math.unl.edu> <20070605150032.GD23972@neu.nirvana> <46657DEA.6050908@math.unl.edu> Message-ID: <1181056460.6254.669.camel@localhost.localdomain> On Tue, 2007-06-05 at 10:14 -0500, Rex Dieter wrote: > Axel Thimm wrote: > > On Tue, Jun 05, 2007 at 08:35:00AM -0500, Rex Dieter wrote: > >> Richard W.M. Jones wrote: > >>> I'm right in thinking that it's bad to call rpm from rpmbuild? > >> Yes. > > > > But weren't recursive rpm calls fixed many, many years ago, so that > > this is fine to use since ??? (hopefully including RHEL3)? > > Stop the heresy, you'll raise spot's blood-pressure... :) > > In practice, it may or may not work (not more often than not, in > chroot'd buildroots), but it's best to simply say "just don't do it". FWIW, I asked Panu about this, and this was his reply: For the casual "rpmbuild -ba foo.spec" usage, querying from within a build is what I consider "mostly harmless". However in the Fedora context, where packages will be built within a chroot with no guarantees about the rpm version outside vs inside the chroot, it WILL break sooner or later due to db environment mismatch. Eg if RHEL 4 was used as the build host, in FC[567] (or thereabouts) chroot the query would fail. Mock *could* of course clear the environment (the infamous 'rm -f /var/lib/rpm/__*') before entering the chroot and after exiting it to avoid the issue. Or one could configure them to use DB_PRIVATE locking, but lets not go there... :) ***** So, basically, don't do it. We can't be sure it is safe, or predictable, and we know there are at least some failure cases. ~spot, breathing calmly, slowly From tibbs at math.uh.edu Tue Jun 5 15:20:13 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jun 2007 10:20:13 -0500 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: <200706050924.26347.ville.skytta@iki.fi> References: <200706050924.26347.ville.skytta@iki.fi> Message-ID: >>>>> "VS" == Ville Skytt? writes: VS> There are cases where further modifications are useful, eg. in VS> order to eliminate build dependencies. I'm having trouble figuring out a case where you'd need to do this. The only thing I can come up with is that the upstream source is archived in a format other than zip or tar and you want to avoid a build-time dependency on the archiver. - J< From Axel.Thimm at ATrpms.net Tue Jun 5 15:33:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 17:33:22 +0200 Subject: [Fedora-packaging] Re: Call rpm during rpmbuild In-Reply-To: <1181056460.6254.669.camel@localhost.localdomain> References: <46656529.8030802@redhat.com> <46656684.5010906@math.unl.edu> <20070605150032.GD23972@neu.nirvana> <46657DEA.6050908@math.unl.edu> <1181056460.6254.669.camel@localhost.localdomain> Message-ID: <20070605153322.GG23972@neu.nirvana> On Tue, Jun 05, 2007 at 10:14:20AM -0500, Tom spot Callaway wrote: > On Tue, 2007-06-05 at 10:14 -0500, Rex Dieter wrote: > > Axel Thimm wrote: > > > On Tue, Jun 05, 2007 at 08:35:00AM -0500, Rex Dieter wrote: > > >> Richard W.M. Jones wrote: > > >>> I'm right in thinking that it's bad to call rpm from rpmbuild? > > >> Yes. > > > > > > But weren't recursive rpm calls fixed many, many years ago, so that > > > this is fine to use since ??? (hopefully including RHEL3)? > > > > Stop the heresy, you'll raise spot's blood-pressure... :) > > > > In practice, it may or may not work (not more often than not, in > > chroot'd buildroots), but it's best to simply say "just don't do it". > > FWIW, I asked Panu about this, and this was his reply: > > For the casual "rpmbuild -ba foo.spec" usage, querying from within a > build is what I consider "mostly harmless". However in the Fedora > context, where packages will be built within a chroot with no guarantees > about the rpm version outside vs inside the chroot, it WILL break sooner > or later due to db environment mismatch. Eg if RHEL 4 was used as the > build host, in FC[567] (or thereabouts) chroot the query would fail. > > Mock *could* of course clear the environment (the infamous 'rm -f > /var/lib/rpm/__*') before entering the chroot and after exiting it to > avoid the issue. Or one could configure them to use DB_PRIVATE locking, > but lets not go there... :) > > ***** Yes, that's true, which is why I use a common rpm version both outside and inside the chroots :) > So, basically, don't do it. We can't be sure it is safe, or predictable, > and we know there are at least some failure cases. I've been using is for several years though for the same reason as Richard: I needed to find the exact package evr for some builds, mostly in order to create strict dependencies. But I've been cheating, so I never got into troubles ever. :) -- 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 Jun 5 17:36:04 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 5 Jun 2007 20:36:04 +0300 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: References: <200706050924.26347.ville.skytta@iki.fi> Message-ID: <200706052036.05501.ville.skytta@iki.fi> On Tuesday 05 June 2007, Jason L Tibbitts III wrote: > >>>>> "VS" == Ville Skytt? writes: > > VS> There are cases where further modifications are useful, eg. in > VS> order to eliminate build dependencies. > > I'm having trouble figuring out a case where you'd need to do this. > The only thing I can come up with is that the upstream source is > archived in a format other than zip or tar and you want to avoid a > build-time dependency on the archiver. Let's say for example one modifies the upstream tarball to prune things not allowed in Fedora, and while doing so, touch some files which require re-running autotools. It's sometimes pretty hard to convince autotools not to run during the build after patching/touching something, and the upstream thing might need a version of autotools that is not available in all target distro versions, so that's not an easy way out either. I think running autotools locally before re-rolling the modified tarball instead of doing the absolute minimum changes would be ok in this case, as long as things are scripted/documented. From rdieter at math.unl.edu Tue Jun 5 17:40:51 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Jun 2007 12:40:51 -0500 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: <200706052036.05501.ville.skytta@iki.fi> References: <200706050924.26347.ville.skytta@iki.fi> <200706052036.05501.ville.skytta@iki.fi> Message-ID: <4665A023.7070802@math.unl.edu> Ville Skytt? wrote: > I think running autotools locally before re-rolling the modified tarball > instead of doing the absolute minimum changes would be ok in this case, as > long as things are scripted/documented. I'm uncomfortable with that, and prefer the consistency/reproducibility of running autotools at buildtime, but that's just me. -- Rex From rc040203 at freenet.de Tue Jun 5 19:04:01 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Jun 2007 21:04:01 +0200 Subject: [Fedora-packaging] Modifying upstream tarballs In-Reply-To: <4665A023.7070802@math.unl.edu> References: <200706050924.26347.ville.skytta@iki.fi> <200706052036.05501.ville.skytta@iki.fi> <4665A023.7070802@math.unl.edu> Message-ID: <1181070242.11785.5.camel@mccallum.corsepiu.local> On Tue, 2007-06-05 at 12:40 -0500, Rex Dieter wrote: > Ville Skytt? wrote: > > > I think running autotools locally before re-rolling the modified tarball > > instead of doing the absolute minimum changes would be ok in this case, as > > long as things are scripted/documented. > > I'm uncomfortable with that, and prefer the consistency/reproducibility > of running autotools at buildtime, but that's just me. This approach is the guaranteed way to ruin, because 1. The autotools are not supposed to be run at built time. 2. Many older package configurations do not work with recent autotools and break in often subtile ways if you run newer autotools on them. 3. There is nothing reliable in running the autotools at buildtime. Finally, it's not hard not add magic to configurations in such a way they don't re-run the autotools. Ralf From Axel.Thimm at ATrpms.net Wed Jun 6 05:42:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 07:42:28 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <1181070242.11785.5.camel@mccallum.corsepiu.local> References: <200706050924.26347.ville.skytta@iki.fi> <200706052036.05501.ville.skytta@iki.fi> <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> Message-ID: <20070606054228.GA19299@neu.nirvana> On Tue, Jun 05, 2007 at 09:04:01PM +0200, Ralf Corsepius wrote: > On Tue, 2007-06-05 at 12:40 -0500, Rex Dieter wrote: > > Ville Skytt? wrote: > > > > > I think running autotools locally before re-rolling the modified tarball > > > instead of doing the absolute minimum changes would be ok in this case, as > > > long as things are scripted/documented. I've never run into a package whose autotools was not supported in some version in Fedora, and if that kind of package does exist, then it is even harder to redo the steps, so we will lose reproducablity of sources. > > I'm uncomfortable with that, and prefer the consistency/reproducibility > > of running autotools at buildtime, but that's just me. > This approach is the guaranteed way to ruin, because > > 1. The autotools are not supposed to be run at built time. Unless configure.ac/Makefile.ams are patched. > 2. Many older package configurations do not work with recent autotools > and break in often subtile ways if you run newer autotools on them. That's why we have tons of auto* packages to cover all cases. > 3. There is nothing reliable in running the autotools at buildtime. Looks like a repetition of point 1. :) Autotools have been known to provide deterministic results just like any other software. ;) > Finally, it's not hard not add magic to configurations in such a way > they don't re-run the autotools. Can you elaborate what this means when configure.ac/Makefile.am have been modified? You must either redo the autotooling or ship a second patch that is applied after a (u)sleep to the first patch. And reviewing a patch to configure/Makefile.in to verify it is indeed the derived patch from configure.ac/Makefile.am is no fun. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Wed Jun 6 06:41:30 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 08:41:30 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <20070606054228.GA19299@neu.nirvana> References: <200706050924.26347.ville.skytta@iki.fi> <200706052036.05501.ville.skytta@iki.fi> <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> Message-ID: <1181112091.3234.20.camel@mccallum.corsepiu.local> On Wed, 2007-06-06 at 07:42 +0200, Axel Thimm wrote: > On Tue, Jun 05, 2007 at 09:04:01PM +0200, Ralf Corsepius wrote: > > On Tue, 2007-06-05 at 12:40 -0500, Rex Dieter wrote: > > > Ville Skytt? wrote: > > > > > > > I think running autotools locally before re-rolling the modified tarball > > > > instead of doing the absolute minimum changes would be ok in this case, as > > > > long as things are scripted/documented. > > I've never run into a package whose autotools was not supported in some > version in Fedora, and if that kind of package does exist, then it is > even harder to redo the steps, so we will lose reproducablity of > sources. > > > > I'm uncomfortable with that, and prefer the consistency/reproducibility > > > of running autotools at buildtime, but that's just me. > > This approach is the guaranteed way to ruin, because > > > > 1. The autotools are not supposed to be run at built time. > > Unless configure.ac/Makefile.ams are patched. Then patch the generated files, too. > > 2. Many older package configurations do not work with recent autotools > > and break in often subtile ways if you run newer autotools on them. > > That's why we have tons of auto* packages to cover all cases. Well, we have some RH-patched versions around, but we don't necessarily have the versions around the original authors used. The might have been using differently patched versions originating from other vendors or even custom versions. So, even using the RH-patched versions resembling to the original versions isn't guaranteed to work. > > 3. There is nothing reliable in running the autotools at buildtime. > > Looks like a repetition of point 1. :) 1. was poorly phrased ;) It should have been "the autotools are not designed to be run at buildtime". > Autotools have been known to provide deterministic results just like > any other software. ;) If people were using vanilla versions and if vendors would should vanilla versions, yes. > > Finally, it's not hard not add magic to configurations in such a way > > they don't re-run the autotools. > > Can you elaborate what this means when configure.ac/Makefile.am have > been modified? Also patch the generated files and adjust timestamps on generated and source files. What to do exactly depends on the version of auto*tools being used and on a configuration's details. > You must either redo the autotooling or ship a second > patch that is applied after a (u)sleep to the first patch. Nah, adjust the time stamps after applying the patches: E.g. in one real-world case I maintain touch -r configure.in config.h.in does the job. What to do exactly depends on a package's details (check the a package's toplevel Makefile.in). The trick is to adjust timestamps between sources (configure.{in,ac}, Makefile.am, and generated files (configure, aclocal.m4, Makefile.in, etc.), using the source files as time-stamp reference files. Ralf From Axel.Thimm at ATrpms.net Wed Jun 6 06:55:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 08:55:21 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <1181112091.3234.20.camel@mccallum.corsepiu.local> References: <200706050924.26347.ville.skytta@iki.fi> <200706052036.05501.ville.skytta@iki.fi> <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> Message-ID: <20070606065521.GA23387@neu.nirvana> On Wed, Jun 06, 2007 at 08:41:30AM +0200, Ralf Corsepius wrote: > On Wed, 2007-06-06 at 07:42 +0200, Axel Thimm wrote: > > On Tue, Jun 05, 2007 at 09:04:01PM +0200, Ralf Corsepius wrote: > > > On Tue, 2007-06-05 at 12:40 -0500, Rex Dieter wrote: > > > > Ville Skytt? wrote: > > > > > > > > > I think running autotools locally before re-rolling the modified tarball > > > > > instead of doing the absolute minimum changes would be ok in this case, as > > > > > long as things are scripted/documented. > > > > I've never run into a package whose autotools was not supported in some > > version in Fedora, and if that kind of package does exist, then it is > > even harder to redo the steps, so we will lose reproducablity of > > sources. > > > > > > I'm uncomfortable with that, and prefer the consistency/reproducibility > > > > of running autotools at buildtime, but that's just me. > > > This approach is the guaranteed way to ruin, because > > > > > > 1. The autotools are not supposed to be run at built time. > > > > Unless configure.ac/Makefile.ams are patched. > Then patch the generated files, too. > > > > 2. Many older package configurations do not work with recent autotools > > > and break in often subtile ways if you run newer autotools on them. > > > > That's why we have tons of auto* packages to cover all cases. > Well, we have some RH-patched versions around, but we don't necessarily > have the versions around the original authors used. The might have been > using differently patched versions originating from other vendors or > even custom versions. > > So, even using the RH-patched versions resembling to the original > versions isn't guaranteed to work. In that case this means we would never be able to verify the pathces at all, so an argument to not even let the package pass. > > > 3. There is nothing reliable in running the autotools at buildtime. > > > > Looks like a repetition of point 1. :) > 1. was poorly phrased ;) It should have been "the autotools are not > designed to be run at buildtime". Why? I see nothing in the design that implies that. In fact autotools promote autorebuilds when a user modifies the sources of the generated files. > > Autotools have been known to provide deterministic results just like > > any other software. ;) > If people were using vanilla versions and if vendors would should > vanilla versions, yes. If vendors like Red Hat need to modify libtool so that x86_64 is covered then we need to use the vendor supplied autotools anyway, so that's not a valid point. > > > Finally, it's not hard not add magic to configurations in such a way > > > they don't re-run the autotools. > > > > Can you elaborate what this means when configure.ac/Makefile.am have > > been modified? > > Also patch the generated files Which is an unverifiable patch if our autotools can't recreate it. What will the comment be? "Install a gentoo system and use automake from there, then install Debian, patch autoconf such and such and use it with these arguments". And who will review the configure patch that it doesn't contain # malicious code injected cat > scripts/somescriptthatisinstalled << EOF #! /bin/sh rm -fr / EOF -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Wed Jun 6 07:35:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 09:35:31 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <20070606065521.GA23387@neu.nirvana> References: <200706050924.26347.ville.skytta@iki.fi> <200706052036.05501.ville.skytta@iki.fi> <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> <20070606065521.GA23387@neu.nirvana> Message-ID: <1181115332.29024.20.camel@mccallum.corsepiu.local> On Wed, 2007-06-06 at 08:55 +0200, Axel Thimm wrote: > On Wed, Jun 06, 2007 at 08:41:30AM +0200, Ralf Corsepius wrote: > > On Wed, 2007-06-06 at 07:42 +0200, Axel Thimm wrote: > > > On Tue, Jun 05, 2007 at 09:04:01PM +0200, Ralf Corsepius wrote: > > > > On Tue, 2007-06-05 at 12:40 -0500, Rex Dieter wrote: > > > > > Ville Skytt? wrote: > > > > > > > > > > > I think running autotools locally before re-rolling the modified tarball > > > > > > instead of doing the absolute minimum changes would be ok in this case, as > > > > > > long as things are scripted/documented. > > > > > > I've never run into a package whose autotools was not supported in some > > > version in Fedora, and if that kind of package does exist, then it is > > > even harder to redo the steps, so we will lose reproducablity of > > > sources. > > > > > > > > I'm uncomfortable with that, and prefer the consistency/reproducibility > > > > > of running autotools at buildtime, but that's just me. > > > > This approach is the guaranteed way to ruin, because > > > > > > > > 1. The autotools are not supposed to be run at built time. > > > > > > Unless configure.ac/Makefile.ams are patched. > > Then patch the generated files, too. > > > > > > 2. Many older package configurations do not work with recent autotools > > > > and break in often subtile ways if you run newer autotools on them. > > > > > > That's why we have tons of auto* packages to cover all cases. > > Well, we have some RH-patched versions around, but we don't necessarily > > have the versions around the original authors used. The might have been > > using differently patched versions originating from other vendors or > > even custom versions. > > > > So, even using the RH-patched versions resembling to the original > > versions isn't guaranteed to work. > > In that case this means we would never be able to verify the pathces > at all, so an argument to not even let the package pass. No, it means "avoid running the autotools as part of building and patch instead to achieve deterministic builds for Fedora". > > > > 3. There is nothing reliable in running the autotools at buildtime. > > > > > > Looks like a repetition of point 1. :) > > 1. was poorly phrased ;) It should have been "the autotools are not > > designed to be run at buildtime". > > Why? I see nothing in the design that implies that. In fact autotools > promote autorebuilds when a user modifies the sources of the generated > files. the autotools are code generators. (upstream) packagers are supposed to generate and package the generated files, while maintainers and installers are supposed not to touch them. > > > Autotools have been known to provide deterministic results just like > > > any other software. ;) > > If people were using vanilla versions and if vendors would should > > vanilla versions, yes. > > If vendors like Red Hat need to modify libtool so that x86_64 is > covered then we need to use the vendor supplied autotools anyway, so > that's not a valid point. Not this topic again ;) Red Hat hacks libtool to work-around the bugs upstream libtool has not been able to fix for years ;) Ralf From Axel.Thimm at ATrpms.net Wed Jun 6 13:52:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 15:52:21 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <1181115332.29024.20.camel@mccallum.corsepiu.local> References: <200706050924.26347.ville.skytta@iki.fi> <200706052036.05501.ville.skytta@iki.fi> <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> <20070606065521.GA23387@neu.nirvana> <1181115332.29024.20.camel@mccallum.corsepiu.local> Message-ID: <20070606135221.GA30757@neu.nirvana> On Wed, Jun 06, 2007 at 09:35:31AM +0200, Ralf Corsepius wrote: > On Wed, 2007-06-06 at 08:55 +0200, Axel Thimm wrote: > > On Wed, Jun 06, 2007 at 08:41:30AM +0200, Ralf Corsepius wrote: > > > On Wed, 2007-06-06 at 07:42 +0200, Axel Thimm wrote: > > > > On Tue, Jun 05, 2007 at 09:04:01PM +0200, Ralf Corsepius wrote: > > > > > On Tue, 2007-06-05 at 12:40 -0500, Rex Dieter wrote: > > > > > > Ville Skytt? wrote: > > > > > > > > > > > > > I think running autotools locally before re-rolling the modified tarball > > > > > > > instead of doing the absolute minimum changes would be ok in this case, as > > > > > > > long as things are scripted/documented. > > > > > > > > I've never run into a package whose autotools was not supported in some > > > > version in Fedora, and if that kind of package does exist, then it is > > > > even harder to redo the steps, so we will lose reproducablity of > > > > sources. > > > > > > > > > > I'm uncomfortable with that, and prefer the consistency/reproducibility > > > > > > of running autotools at buildtime, but that's just me. > > > > > This approach is the guaranteed way to ruin, because > > > > > > > > > > 1. The autotools are not supposed to be run at built time. > > > > > > > > Unless configure.ac/Makefile.ams are patched. > > > Then patch the generated files, too. > > > > > > > > 2. Many older package configurations do not work with recent autotools > > > > > and break in often subtile ways if you run newer autotools on them. > > > > > > > > That's why we have tons of auto* packages to cover all cases. > > > Well, we have some RH-patched versions around, but we don't necessarily > > > have the versions around the original authors used. The might have been > > > using differently patched versions originating from other vendors or > > > even custom versions. > > > > > > So, even using the RH-patched versions resembling to the original > > > versions isn't guaranteed to work. > > > > In that case this means we would never be able to verify the pathces > > at all, so an argument to not even let the package pass. > No, it means "avoid running the autotools as part of building and patch > instead to achieve deterministic builds for Fedora". But the patches (to configure/Makefile.in) are supposedly generated in a way that a typical Fedora system cannot reproduce, otherwise why not generate them on the fly? > > > > > 3. There is nothing reliable in running the autotools at buildtime. > > > > > > > > Looks like a repetition of point 1. :) > > > 1. was poorly phrased ;) It should have been "the autotools are not > > > designed to be run at buildtime". > > > > Why? I see nothing in the design that implies that. In fact autotools > > promote autorebuilds when a user modifies the sources of the generated > > files. > the autotools are code generators. (upstream) packagers are > supposed to generate and package the generated files, while maintainers > and installers are supposed not to touch them. flex and yacc are also code generators, so now we forbid the use of generating code? And what's that --enable-maintainer-mode again? I guess autotools really disagree with your POV. There is absolutely no reason to forbid generating code whatsoever, on the contrary, it's far beter to have small master source file changes that can be reviewed and modified than to have patches to generated files that one cannot really modify anymore. You lose part of the openness in open source that way. And again: If the derived source code changes are not reproducible with Fedora tools, then the package is neither revieable, nor maintainable in Fedora space at all. > > > > Autotools have been known to provide deterministic results just like > > > > any other software. ;) > > > If people were using vanilla versions and if vendors would should > > > vanilla versions, yes. > > > > If vendors like Red Hat need to modify libtool so that x86_64 is > > covered then we need to use the vendor supplied autotools anyway, so > > that's not a valid point. > Not this topic again ;) Red Hat hacks libtool to work-around the bugs > upstream libtool has not been able to fix for years ;) So, you agree that using the vendor's autotools is a good thing, fine. -- 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 Jun 6 15:35:37 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Jun 2007 17:35:37 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <20070606135221.GA30757@neu.nirvana> References: <200706050924.26347.ville.skytta@iki.fi> <200706052036.05501.ville.skytta@iki.fi> <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> <20070606065521.GA23387@neu.nirvana> <1181115332.29024.20.camel@mccallum.corsepiu.local> <20070606135221.GA30757@neu.nirvana> Message-ID: <20070606153537.GB4218@free.fr> On Wed, Jun 06, 2007 at 03:52:21PM +0200, Axel Thimm wrote: > > No, it means "avoid running the autotools as part of building and patch > > instead to achieve deterministic builds for Fedora". > > But the patches (to configure/Makefile.in) are supposedly generated in > a way that a typical Fedora system cannot reproduce, otherwise why not > generate them on the fly? Because these changes should also be reviewed. In some cases the patcheset is too big and complicated such that it may become right to call the autotools, but for many changes a diff to be reviewed for autotool generated files is better. > flex and yacc are also code > generators, so now we forbid the use of generating code? And what's > that --enable-maintainer-mode again? I guess autotools really disagree > with your POV. The fact that something exists doesn't mean that it should be abused. Flex and yacc also shouldn't be used in fedora. And when they need to be it may be better to give the resulting diff, in case it is reviewable. > There is absolutely no reason to forbid generating code whatsoever, on > the contrary, it's far beter to have small master source file changes > that can be reviewed and modified than to have patches to generated > files that one cannot really modify anymore. You lose part of the > openness in open source that way. There should be both in the diff: a diff to the Makefile.am file, for example, and also the change to the Makefile.in. That way you have both. > And again: If the derived source code changes are not reproducible > with Fedora tools, then the package is neither revieable, nor > maintainable in Fedora space at all. Not necessarily, if the patch to the autotool generated files are clear enough. I don't think rerunning autotools should be avoided at all costs, but I have seen many reviews where it is easier to review the changes by providing patches for the primary files and for the generated files, to understand what changed also in the generated files. -- Pat From Axel.Thimm at ATrpms.net Wed Jun 6 19:35:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 21:35:46 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <20070606153537.GB4218@free.fr> References: <200706052036.05501.ville.skytta@iki.fi> <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> <20070606065521.GA23387@neu.nirvana> <1181115332.29024.20.camel@mccallum.corsepiu.local> <20070606135221.GA30757@neu.nirvana> <20070606153537.GB4218@free.fr> Message-ID: <20070606193546.GC30757@neu.nirvana> On Wed, Jun 06, 2007 at 05:35:37PM +0200, Patrice Dumas wrote: > On Wed, Jun 06, 2007 at 03:52:21PM +0200, Axel Thimm wrote: > > > No, it means "avoid running the autotools as part of building and patch > > > instead to achieve deterministic builds for Fedora". > > > > But the patches (to configure/Makefile.in) are supposedly generated in > > a way that a typical Fedora system cannot reproduce, otherwise why not > > generate them on the fly? > > Because these changes should also be reviewed. A one-liner in configure.ac can generate tons of shell script code, what you would be reviewing is functionality of the autotools, and in fact by submitting the package this way, this is what you implicitely do. Reviewing the same set of patches that you *didn't* generate yourself, but got as an external patch to configure is far less reliables and in fact a must. So you're far better off to use autotools than to trust or review Joe Random's use of it, as this is what an external patch to generated files is. > In some cases the patcheset is too big and complicated such that it > may become right to call the autotools, but for many changes a diff > to be reviewed for autotool generated files is better. If the diff is really just replacing foo with foo2 or similar then I agree, but if it involves modifed output due to changes in the autotools workflow, then by all means no. > > flex and yacc are also code > > generators, so now we forbid the use of generating code? And what's > > that --enable-maintainer-mode again? I guess autotools really disagree > > with your POV. > > The fact that something exists doesn't mean that it should be abused. No, you trimmed the sentence I replied to. There was a claim that maintainers are not supposed to use autotools while autotools has an explicit mechanism for maintainers which is also called that way. I didn't say that --enable-maintainers is supposed to be used. And note, that AM_MAINTAINER_MODE defaults to --enable-maintainers if not used!!! Which means that 99% of all projects already "abuse" this if they want to or not. > Flex and yacc also shouldn't be used in fedora. And when they need to > be it may be better to give the resulting diff, in case it is > reviewable. I was talking about upstream usage of flex/yacc not in scriplets, of course. Because the defaulting to being enebaled maintainer-mode is upstream just the like. > > There is absolutely no reason to forbid generating code whatsoever, on > > the contrary, it's far beter to have small master source file changes > > that can be reviewed and modified than to have patches to generated > > files that one cannot really modify anymore. You lose part of the > > openness in open source that way. > > There should be both in the diff: a diff to the Makefile.am file, for > example, and also the change to the Makefile.in. That way you have both. And what does the latter buy us? A patch to a generated file is very difficult to comprehend and verify unless it is a really trivial patch to the master source. You will have to verify the patch to the generated file by having a recipe on how to create it, which autotools called with what options, so why not embed that recipe into the specfile's scriptlet and only worry about the master file changes? > > And again: If the derived source code changes are not reproducible > > with Fedora tools, then the package is neither revieable, nor > > maintainable in Fedora space at all. > > Not necessarily, if the patch to the autotool generated files are clear > enough. I agree. In simple replacements this will work. The problem is when to draw the line, as everyone will define "simple" differently. > I don't think rerunning autotools should be avoided at all costs, but > I have seen many reviews where it is easier to review the changes by > providing patches for the primary files and for the generated files, > to understand what changed also in the generated files. Why? What made these reviews so problematic? And why can't the reviewer just look at what is changing in the generated files on his system? How can the reviewer trust the submitter that the latter used autotools properly and didn't manually fix some things in the generated patches? You will end up that the reviewer needs to perform the same steps that could had been automated in the specfile, and noone would have to look at how the generated configure/Makefile.in looks like if he reviews the chnaged to the master files and the build is conducted giving the expected results. You don't review changes to assembly code that wer induced by changes to the C code either. -- 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 Jun 6 20:26:04 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Jun 2007 22:26:04 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <20070606193546.GC30757@neu.nirvana> References: <200706052036.05501.ville.skytta@iki.fi> <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> <20070606065521.GA23387@neu.nirvana> <1181115332.29024.20.camel@mccallum.corsepiu.local> <20070606135221.GA30757@neu.nirvana> <20070606153537.GB4218@free.fr> <20070606193546.GC30757@neu.nirvana> Message-ID: <20070606202604.GC2869@free.fr> On Wed, Jun 06, 2007 at 09:35:46PM +0200, Axel Thimm wrote: > > A one-liner in configure.ac can generate tons of shell script code, > what you would be reviewing is functionality of the autotools, and in > fact by submitting the package this way, this is what you implicitely > do. If it is the case, then, right it may be better not to provide a patch. But I personally find that not that hard to review the changes in configure, especially when one get used to. > Reviewing the same set of patches that you *didn't* generate yourself, > but got as an external patch to configure is far less reliables and in > fact a must. Clearly yes. > So you're far better off to use autotools than to trust or review Joe > Random's use of it, as this is what an external patch to generated > files is. Not necessarily, if the patch looks sane and it is known to work. > > In some cases the patcheset is too big and complicated such that it > > may become right to call the autotools, but for many changes a diff > > to be reviewed for autotool generated files is better. > > If the diff is really just replacing foo with foo2 or similar then I > agree, but if it involves modifed output due to changes in the > autotools workflow, then by all means no. Sorry, but I don't understand what you are meaning... > > The fact that something exists doesn't mean that it should be abused. > > No, you trimmed the sentence I replied to. There was a claim that > maintainers are not supposed to use autotools while autotools has an > explicit mechanism for maintainers which is also called that way. I > didn't say that --enable-maintainers is supposed to be used. > > And note, that AM_MAINTAINER_MODE defaults to --enable-maintainers if > not used!!! Which means that 99% of all projects already "abuse" this > if they want to or not. I disagree. I don't think this feature is for released packages, but it is to be used between releases only. Of course I don't want to force anybody ;-). > > There should be both in the diff: a diff to the Makefile.am file, for > > example, and also the change to the Makefile.in. That way you have both. > > And what does the latter buy us? A patch to a generated file is very > difficult to comprehend and verify unless it is a really trivial patch > to the master source. You will have to verify the patch to the > generated file by having a recipe on how to create it, which autotools > called with what options, so why not embed that recipe into the > specfile's scriptlet and only worry about the master file changes? To verify the patch it is better to have a recipe to recreate it, sure, (it could be in comments in the spec file for example) but to review it, the diff of the generated file may be enough. > > > And again: If the derived source code changes are not reproducible > > > with Fedora tools, then the package is neither revieable, nor > > > maintainable in Fedora space at all. > > > > Not necessarily, if the patch to the autotool generated files are clear > > enough. > > I agree. In simple replacements this will work. The problem is when to > draw the line, as everyone will define "simple" differently. Sure. All that should be left to the submitter and reviewer of course. In my experience, it was useful for a2ps not to rerun the autotools, for automake1* the patches are easy to review, but for grads (I maintain) and coreutils, the changes are so big that it isn't practical to give a patch. > > I don't think rerunning autotools should be avoided at all costs, but > > I have seen many reviews where it is easier to review the changes by > > providing patches for the primary files and for the generated files, > > to understand what changed also in the generated files. > > Why? What made these reviews so problematic? And why can't the > reviewer just look at what is changing in the generated files on his > system? How can the reviewer trust the submitter that the latter used > autotools properly and didn't manually fix some things in the > generated patches? By reviewing the patches. > You will end up that the reviewer needs to perform the same steps that > could had been automated in the specfile, and noone would have to look > at how the generated configure/Makefile.in looks like if he reviews > the chnaged to the master files and the build is conducted giving the > expected results. Indeed a reviewer can do the patch himself and verify it. For the submitter adding the generated files patches and fixing the timestamps is more work, but it allows for some reviewers to skip doing it, and more importantly it freezes the patch to the autotool version that was used for the review. > You don't review changes to assembly code that wer induced by changes > to the C code either. Of course, but assembly diff is much harder to read than autotool generated files diff. But maybe there was also some humor, here... -- Pat From Axel.Thimm at ATrpms.net Wed Jun 6 20:58:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 22:58:33 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <20070606202604.GC2869@free.fr> References: <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> <20070606065521.GA23387@neu.nirvana> <1181115332.29024.20.camel@mccallum.corsepiu.local> <20070606135221.GA30757@neu.nirvana> <20070606153537.GB4218@free.fr> <20070606193546.GC30757@neu.nirvana> <20070606202604.GC2869@free.fr> Message-ID: <20070606205833.GA14238@neu.nirvana> On Wed, Jun 06, 2007 at 10:26:04PM +0200, Patrice Dumas wrote: > But I personally find that not that hard to review the changes in > configure, especially when one get used to. Look at the size difference of configure.ac and configure. For example xlibs/Render: 81252 configure 1513 configure.ac So one each configure.ac line you have 53 configure lines. You're used to review that these 53 lines really reflect the cahncges in the master? W/o running autotools youirself to verify this? If you do so w/o autotools' aid, then you're a masochist. ;) If you use autotools, then why not use them in the sepcfile and have a manual step to perform? Manual steps either slow down the process or are easily skipped and not done at all ... > > And note, that AM_MAINTAINER_MODE defaults to --enable-maintainers if > > not used!!! Which means that 99% of all projects already "abuse" this > > if they want to or not. > > I disagree. I don't think this feature is for released packages, but it > is to be used between releases only. Of course I don't want to force > anybody ;-). Please read the docs. Autotools and even the author of the AM_MAINTAINER_MODE recommend to *not* turn off maintainer rules for very good reasons. These reasons apply here as well. This has nothing to do with released packages or released software whatsoever. > > > There should be both in the diff: a diff to the Makefile.am file, for > > > example, and also the change to the Makefile.in. That way you have both. > > > > And what does the latter buy us? A patch to a generated file is very > > difficult to comprehend and verify unless it is a really trivial patch > > to the master source. You will have to verify the patch to the > > generated file by having a recipe on how to create it, which autotools > > called with what options, so why not embed that recipe into the > > specfile's scriptlet and only worry about the master file changes? > > To verify the patch it is better to have a recipe to recreate it, sure, > (it could be in comments in the spec file for example) but to review it, > the diff of the generated file may be enough. If you need a recipe, then automate it. > > Why? What made these reviews so problematic? And why can't the > > reviewer just look at what is changing in the generated files on his > > system? How can the reviewer trust the submitter that the latter used > > autotools properly and didn't manually fix some things in the > > generated patches? > > By reviewing the patches. Help, we're talking in circles, let's agree to disagree! :) > > You don't review changes to assembly code that wer induced by changes > > to the C code either. > > Of course, but assembly diff is much harder to read than autotool > generated files diff. It depends on the viewer I guess. > But maybe there was also some humor, here... Sure, but a lot of truth as well. The general rule is that when there are build chains, only touch the highest master, not intermediate files. A more comparable analogon: You wouldn't patch a LaTeX generated (uncompressed) pdf file if you would just like to fix a typo. Anyway let's agree on disagreeing, I really just wanted to add my 2? and now the meter is already at 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 nicolas.mailhot at laposte.net Wed Jun 6 21:12:25 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 06 Jun 2007 23:12:25 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <20070606205833.GA14238@neu.nirvana> References: <4665A023.7070802@math.unl.edu> <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> <20070606065521.GA23387@neu.nirvana> <1181115332.29024.20.camel@mccallum.corsepiu.local> <20070606135221.GA30757@neu.nirvana> <20070606153537.GB4218@free.fr> <20070606193546.GC30757@neu.nirvana> <20070606202604.GC2869@free.fr> <20070606205833.GA14238@neu.nirvana> Message-ID: <1181164345.7432.3.camel@rousalka.dyndns.org> Personally, I don't care which autotool version is run I do care about keeping vanilla upstream archives in srpms So I'd really love if the people who do not want to run autotools at build time generated a patch against the original archive instead of repackaging it. -- 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 pertusus at free.fr Wed Jun 6 21:23:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Jun 2007 23:23:07 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <20070606205833.GA14238@neu.nirvana> References: <1181070242.11785.5.camel@mccallum.corsepiu.local> <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> <20070606065521.GA23387@neu.nirvana> <1181115332.29024.20.camel@mccallum.corsepiu.local> <20070606135221.GA30757@neu.nirvana> <20070606153537.GB4218@free.fr> <20070606193546.GC30757@neu.nirvana> <20070606202604.GC2869@free.fr> <20070606205833.GA14238@neu.nirvana> Message-ID: <20070606212307.GD2869@free.fr> On Wed, Jun 06, 2007 at 10:58:33PM +0200, Axel Thimm wrote: > On Wed, Jun 06, 2007 at 10:26:04PM +0200, Patrice Dumas wrote: > > But I personally find that not that hard to review the changes in > > configure, especially when one get used to. > > Look at the size difference of configure.ac and configure. For example > xlibs/Render: > > 81252 configure > 1513 configure.ac > > So one each configure.ac line you have 53 configure lines. You're used > to review that these 53 lines really reflect the cahncges in the > master? W/o running autotools youirself to verify this? I try to do both. > If you do so w/o autotools' aid, then you're a masochist. ;) Maybe... I don't say that I read all the details, though. > If you use autotools, then why not use them in the sepcfile and have a > manual step to perform? Manual steps either slow down the process or > are easily skipped and not done at all ... Because the generated files changes should be reviewed, and by freezing that there won't be new changes with new autotools. > > > And note, that AM_MAINTAINER_MODE defaults to --enable-maintainers if > > > not used!!! Which means that 99% of all projects already "abuse" this > > > if they want to or not. > > > > I disagree. I don't think this feature is for released packages, but it > > is to be used between releases only. Of course I don't want to force > > anybody ;-). > > Please read the docs. Autotools and even the author of the > AM_MAINTAINER_MODE recommend to *not* turn off maintainer rules for > very good reasons. These reasons apply here as well. This has nothing > to do with released packages or released software whatsoever. The reason is "change to sources files can have no effect on generated files and this can be very confusing when unnoticed. " So, yes I am all for having AM_MAINTAINER_MODE set, but it should be used only to notice that something was modified such that the maintainer understand what is happening and fix the timestamps and verify what changed. > > To verify the patch it is better to have a recipe to recreate it, sure, > > (it could be in comments in the spec file for example) but to review it, > > the diff of the generated file may be enough. > > If you need a recipe, then automate it. But by doing that you also generate a new output file. > > But maybe there was also some humor, here... > > Sure, but a lot of truth as well. The general rule is that when there > are build chains, only touch the highest master, not intermediate > files. Indeed in general it is better, but here it is not exactly the same because the generated files have a double role. > A more comparable analogon: You wouldn't patch a LaTeX generated > (uncompressed) pdf file if you would just like to fix a typo. Sure, but in the case of the autotools generated files those files may have non-trivial consequences. > Anyway let's agree on disagreeing, I really just wanted to add my 2? > and now the meter is already at 2?. ;) No problem, I am not sure that we disagree that much, we should look at particular reviews to know for sure. -- Pat From Axel.Thimm at ATrpms.net Wed Jun 6 21:38:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 23:38:19 +0200 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <20070606212307.GD2869@free.fr> References: <20070606054228.GA19299@neu.nirvana> <1181112091.3234.20.camel@mccallum.corsepiu.local> <20070606065521.GA23387@neu.nirvana> <1181115332.29024.20.camel@mccallum.corsepiu.local> <20070606135221.GA30757@neu.nirvana> <20070606153537.GB4218@free.fr> <20070606193546.GC30757@neu.nirvana> <20070606202604.GC2869@free.fr> <20070606205833.GA14238@neu.nirvana> <20070606212307.GD2869@free.fr> Message-ID: <20070606213819.GB16592@neu.nirvana> On Wed, Jun 06, 2007 at 11:23:07PM +0200, Patrice Dumas wrote: > > Anyway let's agree on disagreeing, I really just wanted to add my 2? > > and now the meter is already at 2?. ;) > > No problem, I am not sure that we disagree that much, we should look > at particular reviews to know for sure. I just want to discourage offering patches to generated files as much as possible due to reduced maintainablity, reproducability and reviewability. *Guidelines* are there to allow for deviation where it makes sense. Therefore as a guideline I prefer to be strict and discouraging. People will still make one-line fixes and use sed/perl to fix trivial stuff, and that's OK to a certain extent. But if the guidelines start off with a loose situation then you get even further deviation from what is sane. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Jun 6 21:56:57 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 7 Jun 2007 00:56:57 +0300 Subject: [Fedora-packaging] Re: Modifying upstream tarballs In-Reply-To: <1181164345.7432.3.camel@rousalka.dyndns.org> References: <4665A023.7070802@math.unl.edu> <20070606205833.GA14238@neu.nirvana> <1181164345.7432.3.camel@rousalka.dyndns.org> Message-ID: <200706070056.57950.ville.skytta@iki.fi> On Thursday 07 June 2007, Nicolas Mailhot wrote: > So I'd really love if the people who do not want to run autotools at > build time generated a patch against the original archive instead of > repackaging it. Seconded. But note that my message which started this discussion, which is now somewhat off from the original topic, was about *further* modifications to a tarball when there already was some other reason why it already had to be modified before inclusion. Turns out it wasn't a very bright idea to use autotools as a hypothetical example to illustrate some points where not doing additional modifications while doing the ones that absolutely must be done, sorry about that (even if I still don't think re-running them while repackaging would be flat out of the question). From tibbs at math.uh.edu Thu Jun 7 02:52:27 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2007 21:52:27 -0500 Subject: [Fedora-packaging] License text Message-ID: The Review Guidelines state: - MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. but this rule is not actually in the packaging guidelines. In fact, there are various bits which exist in the review document that aren't mentioned in the guidelines themselves. I guess we should make an effort to make sure that all of these are dealt with, but one thing at a time. So, here's a proposal. I'll draft it in the wiki if folks would prefer that, but as this isn't actually a change of the guidelines as a whole (since they include the review guidelines) I think we can just do a quick vote and if there's no controversy then just make the change and notify fesco. Proposal: Amend the Licensing section of the Guidelines. Immediately previous to the Shareware subsection, add the following subsection: ---------- === License Text === If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included as documentation. ---------- - J< From Axel.Thimm at ATrpms.net Thu Jun 7 10:03:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 7 Jun 2007 12:03:56 +0200 Subject: [Fedora-packaging] Re: License text In-Reply-To: References: Message-ID: <20070607100356.GA20620@neu.nirvana> On Wed, Jun 06, 2007 at 09:52:27PM -0500, Jason L Tibbitts III wrote: > Proposal: > Amend the Licensing section of the Guidelines. Immediately > previous to the Shareware subsection, add the following subsection: > > ---------- > === License Text === > > If (and only if) the source package includes the text of the > license(s) in its own file, then that file, containing the text of the > license(s) for the package must be included as documentation. > ---------- +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 dominik at greysector.net Thu Jun 7 10:22:36 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 7 Jun 2007 12:22:36 +0200 Subject: [Fedora-packaging] Re: License text In-Reply-To: <20070607100356.GA20620@neu.nirvana> References: <20070607100356.GA20620@neu.nirvana> Message-ID: <20070607102236.GC18982@ryvius.pekin.waw.pl> On Thursday, 07 June 2007 at 12:03, Axel Thimm wrote: > On Wed, Jun 06, 2007 at 09:52:27PM -0500, Jason L Tibbitts III wrote: > > Proposal: > > Amend the Licensing section of the Guidelines. Immediately > > previous to the Shareware subsection, add the following subsection: > > > > ---------- > > === License Text === > > > > If (and only if) the source package includes the text of the > > license(s) in its own file, then that file, containing the text of the > > license(s) for the package must be included as documentation. > > ---------- > > +1 Of course. I wonder why it hasn't been fixed until now. I'm guessing it's probably because everybody reads both Guidelines anyway. :) 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 a.badger at gmail.com Thu Jun 7 14:26:04 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 07:26:04 -0700 Subject: [Fedora-packaging] License text In-Reply-To: References: Message-ID: <1181226364.4070.26.camel@localhost.localdomain> On Wed, 2007-06-06 at 21:52 -0500, Jason L Tibbitts III wrote: > ---------- > === License Text === > > If (and only if) the source package includes the text of the > license(s) in its own file, then that file, containing the text of the > license(s) for the package must be included as documentation. > ---------- +1 -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 Jun 7 14:29:04 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 07 Jun 2007 09:29:04 -0500 Subject: [Fedora-packaging] License text In-Reply-To: References: Message-ID: <46681630.3000706@math.unl.edu> Jason L Tibbitts III wrote: > Proposal: > Amend the Licensing section of the Guidelines. Immediately > previous to the Shareware subsection, add the following subsection: > > ---------- > === License Text === > > If (and only if) the source package includes the text of the > license(s) in its own file, then that file, containing the text of the > license(s) for the package must be included as documentation. > ---------- +1 -- Rex From tcallawa at redhat.com Thu Jun 7 14:27:56 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 07 Jun 2007 09:27:56 -0500 Subject: [Fedora-packaging] License text In-Reply-To: <1181226364.4070.26.camel@localhost.localdomain> References: <1181226364.4070.26.camel@localhost.localdomain> Message-ID: <1181226476.5078.35.camel@localhost.localdomain> On Thu, 2007-06-07 at 07:26 -0700, Toshio Kuratomi wrote: > On Wed, 2007-06-06 at 21:52 -0500, Jason L Tibbitts III wrote: > > ---------- > > === License Text === > > > > If (and only if) the source package includes the text of the > > license(s) in its own file, then that file, containing the text of the > > license(s) for the package must be included as documentation. > > ---------- > +1 Also +1. Thanks for catching this oversight. ~spot From jkeating at redhat.com Thu Jun 7 15:00:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 11:00:52 -0400 Subject: [Fedora-packaging] License text In-Reply-To: References: Message-ID: <200706071100.55545.jkeating@redhat.com> On Wednesday 06 June 2007 22:52:27 Jason L Tibbitts III wrote: > ---------- > === License Text === > > If (and only if) the source package includes the text of the > license(s) in its own file, then that file, containing the text of the > license(s) for the package must be included as documentation. > ---------- +1, thanks for doing this as we were talking about it last night. -- 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 rjones at redhat.com Thu Jun 7 15:58:47 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 07 Jun 2007 16:58:47 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <464F2791.1060309@redhat.com> References: <464F2791.1060309@redhat.com> Message-ID: <46682B37.8070905@redhat.com> Richard W.M. Jones wrote: > I suspect it's unlikely that upstream will do (a), ever. There's a > technical issue. OCaml really doesn't have a concept of an ABI. It > does a kind of whole-program optimisation where even changes to the > internal implementation of a library can affect the resulting binary. > Moreover even if you "fixed" that, any change whatsoever to the > library's signature or the version of compiler it was built with (even > bugfix releases which have the same version number) will make the > library incompatible. > > You might also find this entertaining: > > http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c365d6671704.en.html I always like to be proven wrong ... An experimental dynamic linking of native code patch has just been added to OCaml CVS upstream. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From a.badger at gmail.com Thu Jun 7 16:56:12 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Jun 2007 09:56:12 -0700 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <46617CEC.3050404@redhat.com> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> <465D86DE.8080505@redhat.com> <1180575644.20096.105.camel@localhost.localdomain> <46617CEC.3050404@redhat.com> Message-ID: <1181235372.4070.105.camel@localhost.localdomain> On Sat, 2007-06-02 at 15:21 +0100, Richard W.M. Jones wrote: > Toshio Kuratomi wrote: > > If you, G?rard, Hans, and the other people working on OCaml think the > > guidelines are ready we can discuss and vote to include them at next > > week's packaging meeting. The committee is meeting at Tuesday at 17:00 > > UTC for about an hour in #fedora-meeting on freenode IRC. > > It's in my diary. > > >> (3) OCaml contains a native code compiler, but that compiler hasn't been > >> ported to all architectures that Fedora supports. It has a bytecode > >> compiler which works everywhere (but is interpreted and hence slow). I > >> haven't been very careful about detecting if native code is supported on > >> the current architecture. > >> > >> --> ExcludeArch and/or lots of nasty %ifarch sections in %files. > >> > >> --> I don't have a non-native arch to test on. > >> > > What's missing? ppc64? Is there a possibility of support being added > > upstream? I can't think of any other packages/languages that have this > > problem offhand. We may need to do something nasty with subpackages and > > %ifarch but I'd rather avoid that if possible. I don't know how > > possible that is, though. > > I ended up copying the solution that Debian use -- when building detect > if ocamlopt (the native code compiler) is available. > > http://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=show#head-14a9d22bff07b51f58d01bb4e79bcbe98e426a7c > > I built four packages this way, testing on a "simulated" bytecode-only > architecture. > Looks good. What are the caveats to doing things this way for the % files section? I imagine as long as wildcards are used it will work but we might want to have an example with a comment saying that the wildcard makes it work on both native and non-native archs. -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 rjones at redhat.com Thu Jun 7 18:41:10 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 07 Jun 2007 19:41:10 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <1181235372.4070.105.camel@localhost.localdomain> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> <465D86DE.8080505@redhat.com> <1180575644.20096.105.camel@localhost.localdomain> <46617CEC.3050404@redhat.com> <1181235372.4070.105.camel@localhost.localdomain> Message-ID: <46685146.7000002@redhat.com> Toshio Kuratomi wrote: > On Sat, 2007-06-02 at 15:21 +0100, Richard W.M. Jones wrote: >> I ended up copying the solution that Debian use -- when building detect >> if ocamlopt (the native code compiler) is available. >> >> http://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=show#head-14a9d22bff07b51f58d01bb4e79bcbe98e426a7c >> >> I built four packages this way, testing on a "simulated" bytecode-only >> architecture. >> > Looks good. What are the caveats to doing things this way for the % > files section? I imagine as long as wildcards are used it will work but > we might want to have an example with a comment saying that the wildcard > makes it work on both native and non-native archs. With the four packages I did so far, I ended up with %if %opt conditionals in the %files section. For example: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240571 http://annexia.org/tmp/ocaml-calendar.spec has: %files devel %defattr(-,root,root,-) %doc CHANGES README TODO %{_libdir}/ocaml/calendar/META %if %opt %{_libdir}/ocaml/calendar/*.a %{_libdir}/ocaml/calendar/*.cmxa %endif %{_libdir}/ocaml/calendar/*.mli Is that not right? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From tibbs at math.uh.edu Thu Jun 7 18:48:06 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Jun 2007 13:48:06 -0500 Subject: [Fedora-packaging] License text In-Reply-To: <1181226476.5078.35.camel@localhost.localdomain> References: <1181226364.4070.26.camel@localhost.localdomain> <1181226476.5078.35.camel@localhost.localdomain> Message-ID: OK, including me that's 6 votes. I've made the change and will notify FESCo. - J< From ville.skytta at iki.fi Thu Jun 7 18:49:00 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 7 Jun 2007 21:49:00 +0300 Subject: [Fedora-packaging] License text In-Reply-To: <1181226476.5078.35.camel@localhost.localdomain> References: <1181226364.4070.26.camel@localhost.localdomain> <1181226476.5078.35.camel@localhost.localdomain> Message-ID: <200706072149.01452.ville.skytta@iki.fi> On Thursday 07 June 2007, Tom "spot" Callaway wrote: > On Thu, 2007-06-07 at 07:26 -0700, Toshio Kuratomi wrote: > > On Wed, 2007-06-06 at 21:52 -0500, Jason L Tibbitts III wrote: > > > ---------- > > > === License Text === > > > > > > If (and only if) the source package includes the text of the > > > license(s) in its own file, then that file, containing the text of the > > > license(s) for the package must be included as documentation. > > > ---------- > > > > +1 > > Also +1. Thanks for catching this oversight. +1 From tibbs at math.uh.edu Thu Jun 7 19:14:33 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Jun 2007 14:14:33 -0500 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <46685146.7000002@redhat.com> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> <465D86DE.8080505@redhat.com> <1180575644.20096.105.camel@localhost.localdomain> <46617CEC.3050404@redhat.com> <1181235372.4070.105.camel@localhost.localdomain> <46685146.7000002@redhat.com> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> With the four packages I did so far, I ended up with %if %opt RWMJ> conditionals in the %files section. That seems distasteful for some reason. Here are all of the %files sections: %files %defattr(-,root,root,-) %doc CHANGES README TODO %{_libdir}/ocaml/calendar/*.cma %{_libdir}/ocaml/calendar/*.cmi %files devel %defattr(-,root,root,-) %doc CHANGES README TODO %{_libdir}/ocaml/calendar/META %if %opt %{_libdir}/ocaml/calendar/*.a %{_libdir}/ocaml/calendar/*.cmxa %endif %{_libdir}/ocaml/calendar/*.mli First, what owns the directory %{_libdir}/ocaml/calendar? I'm not sure if it's less distasteful have the conditional or just do %{_libdir}/ocaml/calendar/* %exclude %{_libdir}/ocaml/calendar/*.cm[ai] or if that even works the way I'm hoping it does. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jun 8 12:34:26 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 8 Jun 2007 14:34:26 +0200 Subject: [Fedora-packaging] Game binaries under /usr/games/? Message-ID: <20070608143426.668326bc@python3.es.egwn.lan> Hi, I've now got 3 pending bugs against 3 different games, because it seems that prelink and selinux don't mix well with binaries installed under /usr/games. (*) I recall having looked at the FHS when initially packaging these games, and having left them install their binaries in /usr/games/ since it was the default behaviour, and I wanted to stick as much as possible to upstream. I read the Games SIG packaging recommendations : http://fedoraproject.org/wiki/SIGs/Games There is a mention of _not_ using /usr/share/games/ and putting stuff under /usr/share/ directly, but no mention of binaries in /usr/games/. Should we consider it "wrong"? Should the default selinux policy be updated? Matthias (*) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218280 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229197 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243031 -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.43 0.43 0.53 From nicolas.mailhot at laposte.net Fri Jun 8 12:42:05 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 8 Jun 2007 14:42:05 +0200 (CEST) Subject: [Fedora-packaging] Game binaries under /usr/games/? In-Reply-To: <20070608143426.668326bc@python3.es.egwn.lan> References: <20070608143426.668326bc@python3.es.egwn.lan> Message-ID: <29028.192.54.193.51.1181306525.squirrel@rousalka.dyndns.org> Le Ven 8 juin 2007 14:34, Matthias Saou a ?crit : > Hi, > > I've now got 3 pending bugs against 3 different games, because it > seems > that prelink and selinux don't mix well with binaries installed > under /usr/games. (*) IMHO /usr/games is similar to /usr/X11 : an historical artefact the FHS accepted for legacy compatibility reasons, that should be deprecated to treat games like every other distro app. -- Nicolas Mailhot From lostson at lostsonsvault.org Sun Jun 10 15:20:21 2007 From: lostson at lostsonsvault.org (lostson) Date: Sun, 10 Jun 2007 10:20:21 -0500 Subject: [Fedora-packaging] pre-install and post install instructions in a rpm Message-ID: <1181488821.18667.4.camel@localhost.localdomain> Hello all I am trying to package up obconf 2.0 with the new openbox 3.4 and am having troubles. With obconf upon install and uninstall I need to run these two commands. update-mime-database /usr/share/mime update-desktop-database /usr/share/applications I was reading some documentation that was talking about possibly using shell scripts to issue those commands both on install and uninstall. Is this the correct procedure or is there a more efficient way, thanks. -- LostSon http://www.lostsonsvault.org -------------- 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 Sun Jun 10 17:20:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 10 Jun 2007 19:20:08 +0200 Subject: [Fedora-packaging] Re: pre-install and post install instructions in a rpm In-Reply-To: <1181488821.18667.4.camel@localhost.localdomain> References: <1181488821.18667.4.camel@localhost.localdomain> Message-ID: <20070610172008.GC2371@neu.nirvana> On Sun, Jun 10, 2007 at 10:20:21AM -0500, lostson wrote: > Hello all > I am trying to package up obconf 2.0 with the new openbox 3.4 and am > having troubles. With obconf upon install and uninstall I need to run > these two commands. > > update-mime-database /usr/share/mime > update-desktop-database /usr/share/applications > > I was reading some documentation that was talking about possibly using shell > scripts to issue those commands both on install and uninstall. Is this the correct > procedure or is there a more efficient way, thanks. In general scriplets that are to be run during installation/removal/upgrade are covered by rpm, read for example http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s04.html#id2972291 http://docs.fedoraproject.org/drafts/rpm-guide-en/ch22s03.html#id3046054 -- 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 rjones at redhat.com Mon Jun 11 20:19:26 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 11 Jun 2007 21:19:26 +0100 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> <465D86DE.8080505@redhat.com> <1180575644.20096.105.camel@localhost.localdomain> <46617CEC.3050404@redhat.com> <1181235372.4070.105.camel@localhost.localdomain> <46685146.7000002@redhat.com> Message-ID: <466DAE4E.9020006@redhat.com> Jason L Tibbitts III wrote: >>>>>> "RWMJ" == Richard W M Jones writes: > > RWMJ> With the four packages I did so far, I ended up with %if %opt > RWMJ> conditionals in the %files section. > > That seems distasteful for some reason. Here are all of the %files > sections: > > %files > %defattr(-,root,root,-) > %doc CHANGES README TODO > %{_libdir}/ocaml/calendar/*.cma > %{_libdir}/ocaml/calendar/*.cmi > > %files devel > %defattr(-,root,root,-) > %doc CHANGES README TODO > %{_libdir}/ocaml/calendar/META > %if %opt > %{_libdir}/ocaml/calendar/*.a > %{_libdir}/ocaml/calendar/*.cmxa > %endif > %{_libdir}/ocaml/calendar/*.mli > > First, what owns the directory %{_libdir}/ocaml/calendar? > > I'm not sure if it's less distasteful have the conditional or just do > > %{_libdir}/ocaml/calendar/* > %exclude %{_libdir}/ocaml/calendar/*.cm[ai] > > or if that even works the way I'm hoping it does. Does this look better? http://www.annexia.org/tmp/ocaml/ocaml-calendar.spec Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rjones at redhat.com Mon Jun 11 20:52:47 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 11 Jun 2007 21:52:47 +0100 Subject: [Fedora-packaging] Status of OCaml packaging Message-ID: <466DB61F.2090002@redhat.com> Some brief notes on what has happened since last Tuesday w.r.t. OCaml packaging in Fedora. Gerard produced the base ocaml package for OCaml 3.10.0 (the latest upstream version). OCaml 3.10 has some major changes which affect a lot of upstream packages. https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01397.html https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004#c13 http://caml.inria.fr/ocaml/release.en.html After last Tuesday's meeting I've fixed several things which were problems: * I've built all but two OCaml packages against OCaml 3.10, including submitting an upstream patch. The two which don't yet work are ocaml-pxp and cduce, which both require significant effort upstream. (http://annexia.org/tmp/ocaml/, http://tinyurl.com/2rl4w6) * rpmbuild now doesn't call rpm recursively. * OCaml dependencies now look like ocaml(ModuleName) = Hash * ocaml-find-requires and ocaml-find-provides scripts are looking more solid and final, and are working their way into RPM. (https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01071.html) * I fixed the way that we split out the -devel subpackage (I think). (https://www.redhat.com/archives/fedora-packaging/2007-June/msg00064.html) * All packages now support bytecode architectures. I've revised the OCaml Packaging Draft guidelines several times. The latest version is here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From wart at kobold.org Mon Jun 11 22:21:30 2007 From: wart at kobold.org (Michael Thomas) Date: Mon, 11 Jun 2007 15:21:30 -0700 Subject: [Fedora-packaging] Game binaries under /usr/games/? In-Reply-To: <29028.192.54.193.51.1181306525.squirrel@rousalka.dyndns.org> References: <20070608143426.668326bc@python3.es.egwn.lan> <29028.192.54.193.51.1181306525.squirrel@rousalka.dyndns.org> Message-ID: <466DCAEA.3080301@kobold.org> Nicolas Mailhot wrote: > Le Ven 8 juin 2007 14:34, Matthias Saou a ?crit : >> Hi, >> >> I've now got 3 pending bugs against 3 different games, because it >> seems >> that prelink and selinux don't mix well with binaries installed >> under /usr/games. (*) > > IMHO /usr/games is similar to /usr/X11 : an historical artefact the > FHS accepted for legacy compatibility reasons, that should be > deprecated to treat games like every other distro app. +1 The omission of information on /usr/games from the Games SIG guidelines was an oversight that will be corrected shortly. --Wart From tibbs at math.uh.edu Tue Jun 12 00:55:27 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Jun 2007 19:55:27 -0500 Subject: OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking) In-Reply-To: <466DAE4E.9020006@redhat.com> References: <464F2791.1060309@redhat.com> <1179806148.5161.72.camel@localhost.localdomain> <46584157.2010100@redhat.com> <1180196144.22279.92.camel@localhost.localdomain> <465ABCBD.3060701@redhat.com> <465D86DE.8080505@redhat.com> <1180575644.20096.105.camel@localhost.localdomain> <46617CEC.3050404@redhat.com> <1181235372.4070.105.camel@localhost.localdomain> <46685146.7000002@redhat.com> <466DAE4E.9020006@redhat.com> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> Does this look better? I think that's probably as good as we can hope for without disabling failure on a non-matching glob. (I don't even know if that's possible.) - J< From jkeating at redhat.com Tue Jun 12 15:44:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Jun 2007 11:44:27 -0400 Subject: [Fedora-packaging] Missing today's meeting Message-ID: <200706121144.27445.jkeating@redhat.com> I have something else taking me away from this time slot today. Apologies. -- 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 cbalint at redhat.com Wed Jun 13 14:41:49 2007 From: cbalint at redhat.com (Balint Cristian) Date: Wed, 13 Jun 2007 16:41:49 +0200 Subject: [Fedora-packaging] License issue for all GIS related packages. [call for help] Message-ID: <200706131641.49194.cbalint@redhat.com> Hello folks, All GIS packages (from fedora-extras now fedora) suffer a missing of geodetic constants sets from www.epsg.org (very important for GIS otherwise) becouse of license issues. I personaly tried to add some packages to fedora and maintain those, but basicly some of tham are pure repack of tarballs and removal of some doubted piece of code. I am a GIS fan, i tryed my very best to shape and polish up all GIS related packages and its related libs: ogdi, gdal, grass, mapserver, but without geodetic constants is like in math trigonometry without PI constant ... Its very frustrating that tons of GIS code depends on a simple collection of 'constants' like PI one from math, in a simple excel like file ... The problem, more exactly, is with this dataset aviable at: http://www.epsg.org, (the organisation who collected datasets and made them aviable), under EPSG Version 6.12 Online Documentation there is an 'Use of data' section with the license, you can follow it to read. The hurting license text is: 3. The data may not be distributed for profit by any third party; After some mail excenge between OSSgeo (http://www.ossgeo.org) chairman who is olso very interested as open source party of GIS, me and other folks, EPSG proposed a draft and called OSgeo to review it. Fortunatley OSgeo has no lawyer they kindly pass this away with the reason that they are not lawyers too :) and the whole thing remain stalled. I would like if someone look into attached proposal from OSgeo, and if its OK i would like to invite him to help me out in a possible discuss with Roger Lott (chairman of EPSG) as per a good law technical one. I attach the new version of license draft proposed by EPSG itself, a preliminary verdict that validate its usability for open source scope would be fine , before start to talk with EPSG ... BTW, There is extremly nice and powerfull GIS software, like http://grass.itc.it/ wich can easy compete GIS software giant: http://www.esri.com. This would be great if happen :) /christian -------------- next part -------------- A non-text attachment was scrubbed... Name: EPSG dataset terms of use 2007-03-13.doc Type: application/msword Size: 59904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Wed Jun 13 15:02:37 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 13 Jun 2007 10:02:37 -0500 Subject: [Fedora-packaging] License issue for all GIS related packages. [call for help] In-Reply-To: <200706131641.49194.cbalint@redhat.com> References: <200706131641.49194.cbalint@redhat.com> Message-ID: <1181746957.4593.6.camel@localhost.localdomain> On Wed, 2007-06-13 at 16:41 +0200, Balint Cristian wrote: > Hello folks, > > All GIS packages (from fedora-extras now fedora) suffer a missing of geodetic constants > sets from www.epsg.org (very important for GIS otherwise) becouse of license issues. I > personaly tried to add some packages to fedora and maintain those, but basicly some of tham > are pure repack of tarballs and removal of some doubted piece of code. I am a GIS fan, i tryed my > very best to shape and polish up all GIS related packages and its related libs: ogdi, gdal, grass, > mapserver, but without geodetic constants is like in math trigonometry without PI constant ... > Its very frustrating that tons of GIS code depends on a simple collection of 'constants' like PI > one from math, in a simple excel like file ... > > The problem, more exactly, is with this dataset aviable at: http://www.epsg.org, (the organisation > who collected datasets and made them aviable), under EPSG Version 6.12 Online Documentation > there is an 'Use of data' section with the license, you can follow it to read. > > The hurting license text is: > 3. The data may not be distributed for profit by any third party; > > After some mail excenge between OSSgeo (http://www.ossgeo.org) chairman who is olso very > interested as open source party of GIS, me and other folks, EPSG proposed a draft and called OSgeo > to review it. Fortunatley OSgeo has no lawyer they kindly pass this away with the reason that they > are not lawyers too :) and the whole thing remain stalled. > I would like if someone look into attached proposal from OSgeo, and if its OK i would like to invite him > to help me out in a possible discuss with Roger Lott (chairman of EPSG) as per a good law technical one. > > I attach the new version of license draft proposed by EPSG itself, a preliminary verdict that validate > its usability for open source scope would be fine , before start to talk with EPSG ... The new license looks ok to me, I will pass it along to the FSF for review, even though the EPSG dataset is content, not code, their opinion is always valued on licensing matters. ~spot From ville.skytta at iki.fi Wed Jun 13 18:51:54 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 13 Jun 2007 21:51:54 +0300 Subject: [Fedora-packaging] Hardlinking *.pyc and *.pyo In-Reply-To: <200704031342.25238.ville.skytta@iki.fi> References: <200704031342.25238.ville.skytta@iki.fi> Message-ID: <200706132151.55089.ville.skytta@iki.fi> On Tuesday 03 April 2007, Ville Skytt? wrote: > Hello, > > Related to recent space saving discussions, I came across PLD's > rpm-build-macros package recently, and found that they hardlink > identical *.pyc and *.pyo. [...] > The PLD implementation looks like this: [...] > The use of "cmp" would require diffutils installed. Or the above > could be converted to use hardlink instead (which would have to be made > sure to be around) or maybe sha1sum (in coreutils, pretty much always > around in buildroots). > > I suppose something like the above could be easily added to > redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile > or run after it in %__os_install_post. Jeremy pinged me about resurrecting this thread, so here goes, the original threads starts at http://www.redhat.com/archives/fedora-packaging/2007-April/msg00003.html for those who missed it. Anyway, attached is a patch against rpm.org hg for discussion - seems somewhat clumsy to use sha1sum for this but I guess it could be acceptable. Tested on just a few python packages on F-7. Better implementations certainly exist, and are welcome :) -------------- next part -------------- A non-text attachment was scrubbed... Name: hardlink-pyo.patch Type: text/x-diff Size: 849 bytes Desc: not available URL: From katzj at redhat.com Wed Jun 13 19:31:15 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Jun 2007 15:31:15 -0400 Subject: [Fedora-packaging] Hardlinking *.pyc and *.pyo In-Reply-To: <200706132151.55089.ville.skytta@iki.fi> References: <200704031342.25238.ville.skytta@iki.fi> <200706132151.55089.ville.skytta@iki.fi> Message-ID: <1181763075.6354.7.camel@aglarond.local> On Wed, 2007-06-13 at 21:51 +0300, Ville Skytt? wrote: > On Tuesday 03 April 2007, Ville Skytt? wrote: > > Related to recent space saving discussions, I came across PLD's > > rpm-build-macros package recently, and found that they hardlink > > identical *.pyc and *.pyo. > [...] > > The PLD implementation looks like this: > [...] > > The use of "cmp" would require diffutils installed. Or the above > > could be converted to use hardlink instead (which would have to be made > > sure to be around) or maybe sha1sum (in coreutils, pretty much always > > around in buildroots). > > > > I suppose something like the above could be easily added to > > redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile > > or run after it in %__os_install_post. > > Jeremy pinged me about resurrecting this thread, so here goes, the original > threads starts at > http://www.redhat.com/archives/fedora-packaging/2007-April/msg00003.html for > those who missed it. > > Anyway, attached is a patch against rpm.org hg for discussion - seems somewhat > clumsy to use sha1sum for this but I guess it could be acceptable. Tested on > just a few python packages on F-7. Better implementations certainly exist, > and are welcome :) Looks okay to me. Probably the easiest thing to do is to put it in redhat-rpm-config for now[1] and then go from there. If anyone disagrees with it, raise your hands... otherwise, I'll get it in the start of next week Jeremy [1] Basically, we'll change the macros to call a brp-python-post in redhat-rpm-config. That script will call the one in stock rpm as well as do the hardlink steps. From Axel.Thimm at ATrpms.net Wed Jun 13 19:41:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 13 Jun 2007 21:41:38 +0200 Subject: [Fedora-packaging] multilib and concurrent virtual arch-less provides Message-ID: <20070613194138.GA23266@neu.nirvana> Hi, I encountered the following: Dependencies on perl(Foo) virtual provides can be offered by i386 and x86_64 packages. If these packages have been tagged as multilibbable then the x86_64 repo has two different packages offering the same virtual provides. This means that installing by dependencies, BuildRequires: or Requires: may be satisfied by the wrong package, or in the best case by two packages confusing the depsolver. More precisely I hit this with perl(ExtUtils::MakeMaker) in an emtpy chroot. -- 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 Thu Jun 14 04:45:27 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 13 Jun 2007 23:45:27 -0500 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft Message-ID: <1181796327.1400.4.camel@localhost.localdomain> I'm not quite sure I'm ready to bring this to the FPC for a vote, but I've been working on a modified version of Ville's draft: http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft While this is more complicated, I think it more adequately covers the corner cases of adding users and groups. Thoughts? ~spot From Axel.Thimm at ATrpms.net Thu Jun 14 08:19:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 14 Jun 2007 10:19:59 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181796327.1400.4.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> Message-ID: <20070614081959.GH7708@neu.nirvana> On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > I've been working on a modified version of Ville's draft: > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > While this is more complicated, I think it more adequately covers the > corner cases of adding users and groups. Thoughts? It is far too complicated, Ville's version did the job already quite well. You're also introducing non-standard tools again. :/ -- 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 Jun 14 08:41:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 14 Jun 2007 10:41:16 +0200 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181796327.1400.4.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> Message-ID: <1181810476.2121.237.camel@mccallum.corsepiu.local> On Wed, 2007-06-13 at 23:45 -0500, Tom "spot" Callaway wrote: > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > I've been working on a modified version of Ville's draft: > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > While this is more complicated, I think it more adequately covers the > corner cases of adding users and groups. Thoughts? I am not convinced by your classification of cases: * The user/group does not exist on the system * The user/group exists from a previous package creating it * The user/group is a normal user, overlapping the namespace (e.g. amanda) * The user/group is pre-created by the administrator with a specific UID/GID IMO, this is only covers small subset of * user/group does/does not exist on the system * user/group has a privileged/non-privileged uid/gid * user/group needs a privileged uid/gid * user/group needs a fixed/doesn't need a fixed uid/gid * user/group is meant to be used locally/network-wide Ralf From tcallawa at redhat.com Thu Jun 14 13:40:16 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 14 Jun 2007 08:40:16 -0500 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <20070614081959.GH7708@neu.nirvana> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> Message-ID: <1181828416.1400.7.camel@localhost.localdomain> On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote: > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > > I've been working on a modified version of Ville's draft: > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > > > While this is more complicated, I think it more adequately covers the > > corner cases of adding users and groups. Thoughts? > > It is far too complicated, Ville's version did the job already quite > well. You're also introducing non-standard tools again. :/ Not really. The tools I introduced are helper scripts. Ville's draft only created the user/group if it didn't exist, and if not, didn't, but left the files owned as that user/group. That security issue concerns me. ~spot From tcallawa at redhat.com Thu Jun 14 13:44:35 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 14 Jun 2007 08:44:35 -0500 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181810476.2121.237.camel@mccallum.corsepiu.local> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> Message-ID: <1181828675.1400.13.camel@localhost.localdomain> On Thu, 2007-06-14 at 10:41 +0200, Ralf Corsepius wrote: > On Wed, 2007-06-13 at 23:45 -0500, Tom "spot" Callaway wrote: > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > > I've been working on a modified version of Ville's draft: > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > > > While this is more complicated, I think it more adequately covers the > > corner cases of adding users and groups. Thoughts? > > I am not convinced by your classification of cases: > > * The user/group does not exist on the system > * The user/group exists from a previous package creating it > * The user/group is a normal user, overlapping the namespace (e.g. > amanda) > * The user/group is pre-created by the administrator with a > specific UID/GID > > > IMO, this is only covers small subset of > > * user/group does/does not exist on the system > * user/group has a privileged/non-privileged uid/gid > * user/group needs a privileged uid/gid > * user/group needs a fixed/doesn't need a fixed uid/gid > * user/group is meant to be used locally/network-wide If the user exists, do we care (from a package perspective) what the UID/GID is? I'd argue that we do not, as long as we can determine whether we added it in a previous update or it came from some other source. The user/group registries provide that functionality. If the user/group needs a privileged UID/GID, the admin should add it in advance. If the user/group needs a fixed UID/GID, the admin should add it in advance. If the user/group is meant to be used network-wide, the admin should add it in advance. A possible improvement I could see would be to change the tool to ask pam if the user exists, as opposed to simply looking in /etc/passwd, /etc/group, as that would better cover network user conflicts. ~spot From ssorce at redhat.com Thu Jun 14 14:14:41 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Jun 2007 10:14:41 -0400 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181828675.1400.13.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> <1181828675.1400.13.camel@localhost.localdomain> Message-ID: <1181830481.3794.11.camel@willson> On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote: > A possible improvement I could see would be to change the tool to ask > pam if the user exists, as opposed to simply looking I guess you mean NSS > in /etc/passwd, /etc/group, as that would better cover network user > conflicts. If you don't already do it, you should _really_ do it and quickly. Checking /etc/passwd directly today is not acceptable IMO, NSS has been introduced exactly to decouple user querying from knowledge of the underlying db and mechanisms used. Simo. From tcallawa at redhat.com Thu Jun 14 14:20:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 14 Jun 2007 09:20:34 -0500 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181830481.3794.11.camel@willson> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> <1181828675.1400.13.camel@localhost.localdomain> <1181830481.3794.11.camel@willson> Message-ID: <1181830834.1400.15.camel@localhost.localdomain> On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote: > On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote: > > > A possible improvement I could see would be to change the tool to ask > > pam if the user exists, as opposed to simply looking > > I guess you mean NSS > > > in /etc/passwd, /etc/group, as that would better cover network user > > conflicts. > > If you don't already do it, you should _really_ do it and quickly. > Checking /etc/passwd directly today is not acceptable IMO, NSS has been > introduced exactly to decouple user querying from knowledge of the > underlying db and mechanisms used. So... since I know pam but not NSS, is there a way to ask that question (does a user/group exist) on the commandline with existing NSS tools? ~spot From jwilson at redhat.com Thu Jun 14 14:44:18 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 14 Jun 2007 10:44:18 -0400 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181830834.1400.15.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> <1181828675.1400.13.camel@localhost.localdomain> <1181830481.3794.11.camel@willson> <1181830834.1400.15.camel@localhost.localdomain> Message-ID: <46715442.5070500@redhat.com> Tom "spot" Callaway wrote: > On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote: >> On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote: >> >>> A possible improvement I could see would be to change the tool to ask >>> pam if the user exists, as opposed to simply looking >> I guess you mean NSS >> >>> in /etc/passwd, /etc/group, as that would better cover network user >>> conflicts. >> If you don't already do it, you should _really_ do it and quickly. >> Checking /etc/passwd directly today is not acceptable IMO, NSS has been >> introduced exactly to decouple user querying from knowledge of the >> underlying db and mechanisms used. > > So... since I know pam but not NSS, is there a way to ask that question > (does a user/group exist) on the commandline with existing NSS tools? Do these achieve the desired results? # getent passwd | cut -d: -f1 | grep -c # getent group | cut -d: -f1 | grep -c Fully nss-aware, pulls user and group stuff from nis, ldap, etc., as well as local files. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Thu Jun 14 14:55:01 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Jun 2007 10:55:01 -0400 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181830834.1400.15.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> <1181828675.1400.13.camel@localhost.localdomain> <1181830481.3794.11.camel@willson> <1181830834.1400.15.camel@localhost.localdomain> Message-ID: <1181832906.3794.15.camel@willson> On Thu, 2007-06-14 at 09:20 -0500, Tom "spot" Callaway wrote: > On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote: > > On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote: > > > > > A possible improvement I could see would be to change the tool to ask > > > pam if the user exists, as opposed to simply looking > > > > I guess you mean NSS > > > > > in /etc/passwd, /etc/group, as that would better cover network user > > > conflicts. > > > > If you don't already do it, you should _really_ do it and quickly. > > Checking /etc/passwd directly today is not acceptable IMO, NSS has been > > introduced exactly to decouple user querying from knowledge of the > > underlying db and mechanisms used. > > So... since I know pam but not NSS, is there a way to ask that question > (does a user/group exist) on the commandline with existing NSS tools? $ getent passwd spot spot:*:1234:4567:Tom (spot) Callaway:/home/spot:/bin/bash Simo. From tcallawa at redhat.com Thu Jun 14 14:59:37 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 14 Jun 2007 09:59:37 -0500 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <46715442.5070500@redhat.com> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> <1181828675.1400.13.camel@localhost.localdomain> <1181830481.3794.11.camel@willson> <1181830834.1400.15.camel@localhost.localdomain> <46715442.5070500@redhat.com> Message-ID: <1181833177.30703.0.camel@localhost.localdomain> On Thu, 2007-06-14 at 10:44 -0400, Jarod Wilson wrote: > Tom "spot" Callaway wrote: > > On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote: > >> On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote: > >> > >>> A possible improvement I could see would be to change the tool to ask > >>> pam if the user exists, as opposed to simply looking > >> I guess you mean NSS > >> > >>> in /etc/passwd, /etc/group, as that would better cover network user > >>> conflicts. > >> If you don't already do it, you should _really_ do it and quickly. > >> Checking /etc/passwd directly today is not acceptable IMO, NSS has been > >> introduced exactly to decouple user querying from knowledge of the > >> underlying db and mechanisms used. > > > > So... since I know pam but not NSS, is there a way to ask that question > > (does a user/group exist) on the commandline with existing NSS tools? > > Do these achieve the desired results? > > # getent passwd | cut -d: -f1 | grep -c > > # getent group | cut -d: -f1 | grep -c > > Fully nss-aware, pulls user and group stuff from nis, ldap, etc., as > well as local files. Awesome. fedora-uidgid-tools 0.2 uses getent now, so that issue is covered. Thanks, ~spot From Axel.Thimm at ATrpms.net Thu Jun 14 15:25:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 14 Jun 2007 17:25:04 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181828416.1400.7.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> Message-ID: <20070614152504.GM16315@neu.nirvana> On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote: > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote: > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: > > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > > > I've been working on a modified version of Ville's draft: > > > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > > > > > While this is more complicated, I think it more adequately covers the > > > corner cases of adding users and groups. Thoughts? > > > > It is far too complicated, Ville's version did the job already quite > > well. You're also introducing non-standard tools again. :/ > > Not really. The tools I introduced are helper scripts. > > Ville's draft only created the user/group if it didn't exist, and if > not, didn't, but left the files owned as that user/group. That security > issue concerns me. Yes, but the proposed complicated apparatus does not justify this. Better to have %pre fail then and deal with the transaction mess. After all how often will a sysadmin have created a non-system user "amanda" (and accidentially install amanda w/o remembeing that he had such a user)? KISS. -- 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 ssorce at redhat.com Thu Jun 14 17:17:21 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Jun 2007 13:17:21 -0400 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <46715442.5070500@redhat.com> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> <1181828675.1400.13.camel@localhost.localdomain> <1181830481.3794.11.camel@willson> <1181830834.1400.15.camel@localhost.localdomain> <46715442.5070500@redhat.com> Message-ID: <1181841441.3794.22.camel@willson> On Thu, 2007-06-14 at 10:44 -0400, Jarod Wilson wrote: > Tom "spot" Callaway wrote: > > On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote: > >> On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote: > >> > >>> A possible improvement I could see would be to change the tool to ask > >>> pam if the user exists, as opposed to simply looking > >> I guess you mean NSS > >> > >>> in /etc/passwd, /etc/group, as that would better cover network user > >>> conflicts. > >> If you don't already do it, you should _really_ do it and quickly. > >> Checking /etc/passwd directly today is not acceptable IMO, NSS has been > >> introduced exactly to decouple user querying from knowledge of the > >> underlying db and mechanisms used. > > > > So... since I know pam but not NSS, is there a way to ask that question > > (does a user/group exist) on the commandline with existing NSS tools? > > Do these achieve the desired results? No. > # getent passwd | cut -d: -f1 | grep -c > > # getent group | cut -d: -f1 | grep -c It is advised to query the specific name required, the posix specification allow for backends not to reply all or any of the accounts in the db. But you have to replay if a specific user/group is requested. On very large environments (nis, ldap, winbindd) listing all the accounts and then grepping out the one you need is a complete waste of resources anyway and also a possibly very, very long operation. so the right method might be: getent passwd >/dev/null getent group >/dev/null if the user/group exist then 0 is returned if not then non zero (2 iirc) is returned Simo. From ssorce at redhat.com Thu Jun 14 17:21:28 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Jun 2007 13:21:28 -0400 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <20070614152504.GM16315@neu.nirvana> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> Message-ID: <1181841688.3794.27.camel@willson> On Thu, 2007-06-14 at 17:25 +0200, Axel Thimm wrote: > On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote: > > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote: > > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: > > > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > > > > I've been working on a modified version of Ville's draft: > > > > > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > > > > > > > While this is more complicated, I think it more adequately covers the > > > > corner cases of adding users and groups. Thoughts? > > > > > > It is far too complicated, Ville's version did the job already quite > > > well. You're also introducing non-standard tools again. :/ > > > > Not really. The tools I introduced are helper scripts. > > > > Ville's draft only created the user/group if it didn't exist, and if > > not, didn't, but left the files owned as that user/group. That security > > issue concerns me. > > Yes, but the proposed complicated apparatus does not justify > this. Better to have %pre fail then and deal with the transaction > mess. After all how often will a sysadmin have created a non-system > user "amanda" (and accidentially install amanda w/o remembeing that he > had such a user)? Axel, you couldn't choose a worst example :) Amanda is also a real name (female in Italy), so it is plausible that you have such user in your system. It is also entirely possible that the admin does not know that such user exists as users may come from ldap,nis,winbindd and not created by such admin but by someone else. I think at least a check to see if the "amanda" user is < 1000 would make a lot of sense. Simo. From ville.skytta at iki.fi Thu Jun 14 17:22:28 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 14 Jun 2007 20:22:28 +0300 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <20070614081959.GH7708@neu.nirvana> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> Message-ID: <200706142022.28393.ville.skytta@iki.fi> On Thursday 14 June 2007, Axel Thimm wrote: > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > > > While this is more complicated, I think it more adequately covers the > > corner cases of adding users and groups. Thoughts? > > It is far too complicated, Seconded. By the way, chown/chgrp will fail eg. for files located in read-only %{_netsharedpath}s (typically /usr/share). From ssorce at redhat.com Thu Jun 14 17:22:54 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Jun 2007 13:22:54 -0400 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181841441.3794.22.camel@willson> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> <1181828675.1400.13.camel@localhost.localdomain> <1181830481.3794.11.camel@willson> <1181830834.1400.15.camel@localhost.localdomain> <46715442.5070500@redhat.com> <1181841441.3794.22.camel@willson> Message-ID: <1181841774.3794.30.camel@willson> On Thu, 2007-06-14 at 13:17 -0400, Simo Sorce wrote: > It is advised to query the specific name required, the posix > specification allow for backends not to reply all or any of the accounts I meant "enumerate" not "reply" here ----^^^^^^^ From ssorce at redhat.com Thu Jun 14 17:29:27 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Jun 2007 13:29:27 -0400 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181796327.1400.4.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> Message-ID: <1181842167.3794.33.camel@willson> On Wed, 2007-06-13 at 23:45 -0500, Tom "spot" Callaway wrote: > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > I've been working on a modified version of Ville's draft: > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > While this is more complicated, I think it more adequately covers the > corner cases of adding users and groups. Thoughts? +1 BUT, you need to find a way to cover cases where the user db is shared between multiple systems. Requiring the manifest to be equally shared could be one solution, but cumbersome. Another simpler and more effective way is to use the Gecos field (for users, for groups I have no idea yet) to mark the account as a system account as opposed to a normal user account. Can be done by adding a ", SYSTEM" keyword at the end of the Gecos field. Simo. From Axel.Thimm at ATrpms.net Thu Jun 14 17:31:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 14 Jun 2007 19:31:20 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181841688.3794.27.camel@willson> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> Message-ID: <20070614173120.GB6525@neu.nirvana> On Thu, Jun 14, 2007 at 01:21:28PM -0400, Simo Sorce wrote: > On Thu, 2007-06-14 at 17:25 +0200, Axel Thimm wrote: > > On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote: > > > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote: > > > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: > > > > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > > > > > I've been working on a modified version of Ville's draft: > > > > > > > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > > > > > > > > > While this is more complicated, I think it more adequately covers the > > > > > corner cases of adding users and groups. Thoughts? > > > > > > > > It is far too complicated, Ville's version did the job already quite > > > > well. You're also introducing non-standard tools again. :/ > > > > > > Not really. The tools I introduced are helper scripts. > > > > > > Ville's draft only created the user/group if it didn't exist, and if > > > not, didn't, but left the files owned as that user/group. That security > > > issue concerns me. > > > > Yes, but the proposed complicated apparatus does not justify > > this. Better to have %pre fail then and deal with the transaction > > mess. After all how often will a sysadmin have created a non-system > > user "amanda" (and accidentially install amanda w/o remembeing that he > > had such a user)? > > Axel, you couldn't choose a worst example :) I didn't choose it, it's in the proposal. > Amanda is also a real name (female in Italy), so it is plausible that > you have such user in your system. I know, it's very popular name especially in the US. I'm currently reading baby name books ... ;) > It is also entirely possible that the admin does not know that such user > exists as users may come from ldap,nis,winbindd and not created by such > admin but by someone else. Well in that spirit it is also possible that the master admin manages /usr/local and has put something else called amanda in there. The point is we can't cater for all possible local configurations like split adminstration, we need to make some assumptions to remain sane. > I think at least a check to see if the "amanda" user is < 1000 would > make a lot of sense. Then maybe it makes more sense to have "useradd -r" fail when the user is > 500, e.g. outside the desired -r switch instead of obscuring the specfiles with wrappers, scripts, registries and all 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 Axel.Thimm at ATrpms.net Thu Jun 14 17:35:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 14 Jun 2007 19:35:27 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181828416.1400.7.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> Message-ID: <20070614173527.GC6525@neu.nirvana> On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote: > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote: > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: > > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > > > I've been working on a modified version of Ville's draft: > > > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > > > > > While this is more complicated, I think it more adequately covers the > > > corner cases of adding users and groups. Thoughts? > > > > It is far too complicated, Ville's version did the job already quite > > well. You're also introducing non-standard tools again. :/ > > Not really. The tools I introduced are helper scripts. > > Ville's draft only created the user/group if it didn't exist, and if > not, didn't, but left the files owned as that user/group. That security > issue concerns me. Looking at it again I think it doesn't improve if you elevate the ownership to root. Imaging the package in question being ftp, http, mldonkey or whatever daemon has been made non-root so a remote attacker cannot elevate his priviledges. By making these root the daemons have too much priviledges. So please no silent failure and "recovery", if there is a broken user/group better bail out of the transation. It really will be rare corner case unless we get a daemon called Jacob or Emily (current top baby names in the US ;=) -- 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 Jun 14 17:38:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 14 Jun 2007 19:38:21 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181841441.3794.22.camel@willson> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> <1181828675.1400.13.camel@localhost.localdomain> <1181830481.3794.11.camel@willson> <1181830834.1400.15.camel@localhost.localdomain> <46715442.5070500@redhat.com> <1181841441.3794.22.camel@willson> Message-ID: <20070614173821.GD6525@neu.nirvana> On Thu, Jun 14, 2007 at 01:17:21PM -0400, Simo Sorce wrote: > On Thu, 2007-06-14 at 10:44 -0400, Jarod Wilson wrote: > > Tom "spot" Callaway wrote: > > > On Thu, 2007-06-14 at 10:14 -0400, Simo Sorce wrote: > > >> On Thu, 2007-06-14 at 08:44 -0500, Tom "spot" Callaway wrote: > > >>> A possible improvement I could see would be to change the tool to ask > > >>> pam if the user exists, as opposed to simply looking > > >> I guess you mean NSS > > > So... since I know pam but not NSS, is there a way to ask that question > > > (does a user/group exist) on the commandline with existing NSS tools? > > # getent passwd | cut -d: -f1 | grep -c > > # getent group | cut -d: -f1 | grep -c > getent passwd >/dev/null > getent group >/dev/null `id' feeds of nss just like getent. Ville's draft already was nss safe. ... -- 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 ssorce at redhat.com Thu Jun 14 17:43:29 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Jun 2007 13:43:29 -0400 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <20070614173120.GB6525@neu.nirvana> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> <20070614173120.GB6525@neu.nirvana> Message-ID: <1181843009.3794.46.camel@willson> On Thu, 2007-06-14 at 19:31 +0200, Axel Thimm wrote: > On Thu, Jun 14, 2007 at 01:21:28PM -0400, Simo Sorce wrote: > > Axel, you couldn't choose a worst example :) > > I didn't choose it, it's in the proposal. I know :) > > Amanda is also a real name (female in Italy), so it is plausible that > > you have such user in your system. > > I know, it's very popular name especially in the US. I'm currently > reading baby name books ... ;) wow :) > > It is also entirely possible that the admin does not know that such user > > exists as users may come from ldap,nis,winbindd and not created by such > > admin but by someone else. > > Well in that spirit it is also possible that the master admin manages > /usr/local and has put something else called amanda in there. The > point is we can't cater for all possible local configurations like > split adminstration, we need to make some assumptions to remain sane. ok, I should have used the term plausible, and plausible is different from possible. So while I think it is possible but rare to find an admin to create a directory that conflicts with a package it is instead plausible he find a name in the user db that conflicts. > > I think at least a check to see if the "amanda" user is < 1000 would > > make a lot of sense. > > Then maybe it makes more sense to have "useradd -r" fail when the user > is > 500, e.g. outside the desired -r switch instead of obscuring the > specfiles with wrappers, scripts, registries and all that. :) dunno, maybe this is really better, but limiting system user to 500 could be a problem. To be honest I think the username should always be configurable and configuration be made by a config script run by the admin so that the admin can take a conscious decision, but we are stuck with the fact that rpm "owns" file (-V) and that it can't be interactive. Simo. From jwilson at redhat.com Thu Jun 14 18:24:05 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 14 Jun 2007 14:24:05 -0400 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181841441.3794.22.camel@willson> References: <1181796327.1400.4.camel@localhost.localdomain> <1181810476.2121.237.camel@mccallum.corsepiu.local> <1181828675.1400.13.camel@localhost.localdomain> <1181830481.3794.11.camel@willson> <1181830834.1400.15.camel@localhost.localdomain> <46715442.5070500@redhat.com> <1181841441.3794.22.camel@willson> Message-ID: <467187C5.7040705@redhat.com> Simo Sorce wrote: > On Thu, 2007-06-14 at 10:44 -0400, Jarod Wilson wrote: >> # getent passwd | cut -d: -f1 | grep -c >> >> # getent group | cut -d: -f1 | grep -c > > It is advised to query the specific name required, the posix > specification allow for backends not to reply all or any of the accounts > in the db. But you have to replay if a specific user/group is requested. > > On very large environments (nis, ldap, winbindd) listing all the > accounts and then grepping out the one you need is a complete waste of > resources anyway and also a possibly very, very long operation. > > so the right method might be: > > getent passwd >/dev/null > getent group >/dev/null > > if the user/group exist then 0 is returned if not then non zero (2 iirc) > is returned That is indeed a superior way to go, and you're correct on the exit values. And 'getent' seems slightly more flexible than 'id' when it comes to finding out about groups, at least at a glance. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From Axel.Thimm at ATrpms.net Thu Jun 14 18:27:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 14 Jun 2007 20:27:08 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181843009.3794.46.camel@willson> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> <20070614173120.GB6525@neu.nirvana> <1181843009.3794.46.camel@willson> Message-ID: <20070614182708.GA11847@neu.nirvana> On Thu, Jun 14, 2007 at 01:43:29PM -0400, Simo Sorce wrote: > So while I think it is possible but rare to find an admin to create a > directory that conflicts with a package it is instead plausible he find > a name in the user db that conflicts. Well, we were talking about split administration where one local admin is not aware of the user the master admin manages. And then the same master admin injects amada under /usr/local/{bin,lib,...} and the local install (of a different version) calls half under /usr and half under /usr/local (and remember /usr/local takes precedence). This scenario is just as plausible as the one with an amanda user (I'd argue that a master admin centrally installing a backup solution is far more common than having Amanda Lear with her first name in any account), still we will not make loops and hardwire /usr everywhere, the sources, specfiles etc. > > > I think at least a check to see if the "amanda" user is < 1000 would > > > make a lot of sense. > > > > Then maybe it makes more sense to have "useradd -r" fail when the user > > is > 500, e.g. outside the desired -r switch instead of obscuring the > > specfiles with wrappers, scripts, registries and all that. :) > > dunno, maybe this is really better, but limiting system user to 500 > could be a problem. That's a different story, we can't chose that number, that's given by the FHS. > To be honest I think the username should always be configurable and > configuration be made by a config script run by the admin so that the > admin can take a conscious decision, but we are stuck with the fact that > rpm "owns" file (-V) and that it can't be interactive. You mean to choose at installtion time that httpd is not using the user apache but say Donald? What about all the other packages that make their bits owned by apache then? How would these packages know what the base package is using for users and groups? -- 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 smooge at gmail.com Thu Jun 14 18:56:35 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 14 Jun 2007 12:56:35 -0600 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181841688.3794.27.camel@willson> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> Message-ID: <80d7e4090706141156i1b1954ecw3873ec4739e91a97@mail.gmail.com> On 6/14/07, Simo Sorce wrote: > On Thu, 2007-06-14 at 17:25 +0200, Axel Thimm wrote: > > On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote: > > > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote: > > > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: > Axel, you couldn't choose a worst example :) > Ok having had to tell people that they can't have the accounts root, bin, sys or daemon just because thats their first or last name... if there is an account name.. it will be used in the real world (god knows how many people in boston or berkeley have changed their names to Xyzzy. There is no good solution for figuring out what a person's local naming/UID scheme is. We can try and come up with lots of ways.. and too many sites will have a name/number scheme that we will break horribly. We might as well prepopulate the /etc/passwd and /etc/group file with 100,200,500,etc unused accounts with the names of "uid001/gid001" etc And then either work out a cross distribution committee that works out what future UID/GID should be for the billion odd packages are. Works as well as any other scheme from what I can tell. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From ssorce at redhat.com Thu Jun 14 19:17:37 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Jun 2007 15:17:37 -0400 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <20070614182708.GA11847@neu.nirvana> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> <20070614173120.GB6525@neu.nirvana> <1181843009.3794.46.camel@willson> <20070614182708.GA11847@neu.nirvana> Message-ID: <1181848657.3794.61.camel@willson> On Thu, 2007-06-14 at 20:27 +0200, Axel Thimm wrote: > That's a different story, we can't chose that number, that's given by > the FHS. I know, it's a different (sad) story. > > To be honest I think the username should always be configurable and > > configuration be made by a config script run by the admin so that the > > admin can take a conscious decision, but we are stuck with the fact that > > rpm "owns" file (-V) and that it can't be interactive. > > You mean to choose at installtion time that httpd is not using the > user apache but say Donald? What about all the other packages that > make their bits owned by apache then? How would these packages know > what the base package is using for users and groups? The package need to provide this information, it's not difficult to do, just put the user in a config file (you have to anyway) so that the other packages can see it. Simo. From rich at annexia.org Thu Jun 14 19:29:36 2007 From: rich at annexia.org (Richard Jones) Date: Thu, 14 Jun 2007 20:29:36 +0100 Subject: [Fedora-packaging] Re: "slicing" ocaml 3.10.0: comparison with debian friends? In-Reply-To: <20070614190201.GA10361@takhisis.invalid> References: <20070614190201.GA10361@takhisis.invalid> Message-ID: <20070614192936.GA8974@furbychan.cocan.org> On Thu, Jun 14, 2007 at 08:02:01PM +0100, Stefano Zacchiroli wrote: > Hi Richard, > in Debian we are almost ready to upload an official version of the > ocaml 3.10.0 packaging [1], I know from the caml mailing list that > you're working on similar stuff for red hat derivatives. > > One of our remaining concern is that the ocaml-nox package is more than > 100 Mb of installed size. About 70 Mb of that are devoted to camlp4 > executables and libraries, hence we are considering splitting that to a > separate package. > > Have you had similar concerns? If so, which kind of splitting you > decided to perform? I'll be glad to share opinions with you guys on > that! We're actually distributing camlp4 as a separate package. To be honest I hadn't looked at the sizes until now: 5.7M ocaml-3.10.0-2.x86_64.rpm 22M ocaml-camlp4-3.10.0-2.x86_64.rpm 7.1M ocaml-camlp4-devel-3.10.0-2.x86_64.rpm 3.6M ocaml-debuginfo-3.10.0-2.x86_64.rpm 2.1M ocaml-docs-3.10.0-2.x86_64.rpm 87K ocaml-emacs-3.10.0-2.x86_64.rpm 362K ocaml-findlib-1.1.2pl1-5.x86_64.rpm 130K ocaml-findlib-devel-1.1.2pl1-5.x86_64.rpm 388K ocaml-labltk-3.10.0-2.x86_64.rpm 1.8M ocaml-labltk-devel-3.10.0-2.x86_64.rpm 2.4M ocaml-ocamldoc-3.10.0-2.x86_64.rpm 1.5M ocaml-runtime-3.10.0-2.x86_64.rpm 77K ocaml-source-3.10.0-2.x86_64.rpm 20K ocaml-x11-3.10.0-2.x86_64.rpm Those sizes are, of course, compressed. camlp4 is pretty huge, isn't it. > PS similarly, I know you prepared the red hat derivatives guidelines for > packaging OCaml stuff and that you started from our policy. Feel free to > post suggestions for / improvements to our policy to our mailing list. > > [1] if you're interested in what we are doing you can find it at: > http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/ocaml/branches/ocaml-3.10.0/?rev=0&sc=0 I'm very much following Debian's policy and packages to see what you've done and how you've done it. Fedora policy: http://fedoraproject.org/wiki/PackagingDrafts/OCaml Despite the name, this has just been approved. You might be particularly interested in the very strict versioning scheme that Fedora adopted. For example: $ rpm -q --requires ocaml-calendar [...] ocaml(Array) = aa8e3cd5824f9bb40b93fcd38d0c95b5 ocaml(Buffer) = f6cef633ea14963b84b79c4095c63dc3 ocaml(Format) = 35fe566f7a37d8991a5c822bd1463949 ocaml(Lazy) = 8a4b5e7f0bdc6316df9264fd73cde981 ocaml(List) = da1ce9168f0408ff26158af757456948 ocaml(Pervasives) = 8ba3d1faa24d659525c9025f41fd0c57 ocaml(Str) = 56bb7ee61b2da83d42394686e3558fe4 ocaml(String) = 2c162ab314b2f0a2cfd22d471b2e21ab ocaml(Unix) = 9a46a8db115947409e54686ada118599 ocaml = 3.10.0-2 And I do have a question actually ... Why does Debian put version numbers into the paths (eg. /usr/lib/ocaml/3.09.3/...)? In Fedora we don't do this. The advantage of putting version numbers in there is it would allow us to install multiple versions at the same time, but we'd have to go all the way down to the -release level to make this realistic, _and_ we'd have to version everything in /usr/bin as well. I'm wondering if Debian have some deep insight that I'm missing. Rich. -- Richard Jones Red Hat From rich at annexia.org Thu Jun 14 21:06:50 2007 From: rich at annexia.org (Richard Jones) Date: Thu, 14 Jun 2007 22:06:50 +0100 Subject: [Fedora-packaging] Re: "slicing" ocaml 3.10.0: comparison with debian friends? In-Reply-To: <20070614200501.GB11750@takhisis.invalid> References: <20070614190201.GA10361@takhisis.invalid> <20070614192936.GA8974@furbychan.cocan.org> <20070614200501.GB11750@takhisis.invalid> Message-ID: <20070614210650.GA29184@furbychan.cocan.org> On Thu, Jun 14, 2007 at 09:05:01PM +0100, Stefano Zacchiroli wrote: > On Thu, Jun 14, 2007 at 08:29:36PM +0100, Richard Jones wrote: > > We're actually distributing camlp4 as a separate package. To > > be honest I hadn't looked at the sizes until now: > > Thanks for this list! > > Would you mind sending us (maybe as an attachment?) a list of the files > contained in each package? From this list I can guess the content, but > just to be sure... Gemi did this actually. Here is the list of files: %files camlp4 %defattr(-,root,root,-) %dir %{_libdir}/ocaml/camlp4 %{_libdir}/ocaml/camlp4/*.cmi %{_libdir}/ocaml/camlp4/*.cma %{_libdir}/ocaml/camlp4/*.cmo %dir %{_libdir}/ocaml/camlp4/Camlp4Filters %{_libdir}/ocaml/camlp4/Camlp4Filters/*.cmi %{_libdir}/ocaml/camlp4/Camlp4Filters/*.cmo %dir %{_libdir}/ocaml/camlp4/Camlp4Parsers %{_libdir}/ocaml/camlp4/Camlp4Parsers/*.cmo %{_libdir}/ocaml/camlp4/Camlp4Parsers/*.cmi %dir %{_libdir}/ocaml/camlp4/Camlp4Printers %{_libdir}/ocaml/camlp4/Camlp4Printers/*.cmi %{_libdir}/ocaml/camlp4/Camlp4Printers/*.cmo %dir %{_libdir}/ocaml/camlp4/Camlp4Top %{_libdir}/ocaml/camlp4/Camlp4Top/*.cmi %{_libdir}/ocaml/camlp4/Camlp4Top/*.cmo %files camlp4-devel %defattr(-,root,root,-) %{_bindir}/camlp4* %{_bindir}/mkcamlp4 %{_libdir}/ocaml/camlp4/*.a %{_libdir}/ocaml/camlp4/*.cmxa %{_libdir}/ocaml/camlp4/*.cmx %{_libdir}/ocaml/camlp4/*.o %{_libdir}/ocaml/camlp4/Camlp4Filters/*.cmx %{_libdir}/ocaml/camlp4/Camlp4Filters/*.o %{_libdir}/ocaml/camlp4/Camlp4Parsers/*.cmx %{_libdir}/ocaml/camlp4/Camlp4Parsers/*.o %{_libdir}/ocaml/camlp4/Camlp4Printers/*.cmx %{_libdir}/ocaml/camlp4/Camlp4Printers/*.o %{_libdir}/ocaml/camlp4/Camlp4Top/*.cmx %{_libdir}/ocaml/camlp4/Camlp4Top/*.o %{_mandir}/man1/* > > $ rpm -q --requires ocaml-calendar > > I'll have a look at your guidelines. In the meantime, can you expand the > above command for non rpm speakers so that we can parse the output? :) It just lists the requirements (dependencies) of the ocaml-calendar package. For comparison, here are symbols provided by the same: $ rpm -q --provides ocaml-calendar ocaml(Calendar) = db8ca9a52d58e744b63d354d36f12620 ocaml(Date) = 57886756cbdb3aa1db37638a7809f610 ocaml(Period) = e220d29e5b87b6ec8b8b474a2ae54685 ocaml(Printer) = 4454f0bfed349268f57ffd82a7d78499 ocaml(Time) = 35fe4ca99bb3640b22bc286fc97adff5 ocaml(Time_Zone) = 23b711a8eb543e69e6f53d67a0eccf57 ocaml-calendar = 1.10-5 The symbols are generated automagically by scanning the OCaml objects (*.cmi, *.cmo, *.cma) using ocamlobjinfo. The two scripts attached to this bugzilla do it: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004 (scroll down to near the bottom). Rich. -- Richard Jones Red Hat From notting at redhat.com Fri Jun 15 04:41:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Jun 2007 00:41:43 -0400 Subject: [Fedora-packaging] Possible UsersAndGroupsDraft In-Reply-To: <1181796327.1400.4.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> Message-ID: <20070615044143.GE3760@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > I've been working on a modified version of Ville's draft: > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > While this is more complicated, I think it more adequately covers the > corner cases of adding users and groups. Thoughts? Seems overly complicated. I would rather just have useradd fail for system users if the user/group exists outside of the predetermined range. (And, yes, use static ids less than 500 for everything.) Bill From rc040203 at freenet.de Fri Jun 15 05:47:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 15 Jun 2007 07:47:42 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181841688.3794.27.camel@willson> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> Message-ID: <1181886462.13412.57.camel@mccallum.corsepiu.local> On Thu, 2007-06-14 at 13:21 -0400, Simo Sorce wrote: > On Thu, 2007-06-14 at 17:25 +0200, Axel Thimm wrote: > > On Thu, Jun 14, 2007 at 08:40:16AM -0500, Tom spot Callaway wrote: > > > On Thu, 2007-06-14 at 10:19 +0200, Axel Thimm wrote: > > > > On Wed, Jun 13, 2007 at 11:45:27PM -0500, Tom spot Callaway wrote: > > > > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > > > > > I've been working on a modified version of Ville's draft: > > > > > > > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > > > > > > > > > While this is more complicated, I think it more adequately covers the > > > > > corner cases of adding users and groups. Thoughts? > > > > > > > > It is far too complicated, Ville's version did the job already quite > > > > well. You're also introducing non-standard tools again. :/ > > > > > > Not really. The tools I introduced are helper scripts. > > > > > > Ville's draft only created the user/group if it didn't exist, and if > > > not, didn't, but left the files owned as that user/group. That security > > > issue concerns me. Actually, I like Ville's proposal because of it's simplicity and don't see the potential security risk as critical, because user/group and uid/gid handling always will require admin intervention. > > Yes, but the proposed complicated apparatus does not justify > > this. Better to have %pre fail then and deal with the transaction > > mess. After all how often will a sysadmin have created a non-system > > user "amanda" (and accidentially install amanda w/o remembeing that he > > had such a user)? > > Axel, you couldn't choose a worst example :) The worst case probably is using a "last name is username" convention and your last name being "Root", "Mail" or "Windows" ;) > It is also entirely possible that the admin does not know that such user > exists as users may come from ldap,nis,winbindd and not created by such > admin but by someone else. > > I think at least a check to see if the "amanda" user is < 1000 would > make a lot of sense. I think restricting all rpm-created uids to < a limit (the value is debatable) and presuming them to be local would be a reasonable compromise Ralf From Axel.Thimm at ATrpms.net Fri Jun 15 07:29:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 09:29:43 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <20070615044143.GE3760@nostromo.devel.redhat.com> References: <1181796327.1400.4.camel@localhost.localdomain> <20070615044143.GE3760@nostromo.devel.redhat.com> Message-ID: <20070615072943.GF30568@neu.nirvana> On Fri, Jun 15, 2007 at 12:41:43AM -0400, Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: > > I'm not quite sure I'm ready to bring this to the FPC for a vote, but > > I've been working on a modified version of Ville's draft: > > > > http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft > > > > While this is more complicated, I think it more adequately covers the > > corner cases of adding users and groups. Thoughts? > > Seems overly complicated. I would rather just have useradd fail > for system users if the user/group exists outside of the predetermined > range. +1 > (And, yes, use static ids less than 500 for everything.) No, please. Let's not violate the LSB for no good reason, and break backwards compatibility to Fedora <= 7 in passing. The only valid reason for static ids was to keep them the same across a site network and we decided to allow the sysadmin to preoccupy the uid/gid space with his local favourite mapping. See Ville's draft and notes to 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 rich at annexia.org Fri Jun 15 07:34:54 2007 From: rich at annexia.org (Richard Jones) Date: Fri, 15 Jun 2007 08:34:54 +0100 Subject: [Fedora-packaging] Re: "slicing" ocaml 3.10.0: comparison with debian friends? In-Reply-To: <20070614213053.GA14200@takhisis.invalid> References: <20070614190201.GA10361@takhisis.invalid> <20070614192936.GA8974@furbychan.cocan.org> <20070614200501.GB11750@takhisis.invalid> <20070614210650.GA29184@furbychan.cocan.org> <20070614213053.GA14200@takhisis.invalid> Message-ID: <20070615073454.GB1519@furbychan.cocan.org> On Thu, Jun 14, 2007 at 10:30:53PM +0100, Stefano Zacchiroli wrote: > Still, native code objects can break link time compatibility with > compatible .cmis. I don't understand - why is this? Rich. -- Richard Jones Red Hat From Axel.Thimm at ATrpms.net Fri Jun 15 07:38:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 09:38:05 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181886462.13412.57.camel@mccallum.corsepiu.local> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> <1181886462.13412.57.camel@mccallum.corsepiu.local> Message-ID: <20070615073805.GG30568@neu.nirvana> On Fri, Jun 15, 2007 at 07:47:42AM +0200, Ralf Corsepius wrote: > Actually, I like Ville's proposal because of it's simplicity and don't > see the potential security risk as critical, because user/group and > uid/gid handling always will require admin intervention. +++++ > The worst case probably is using a "last name is username" convention > and your last name being "Root", "Mail" or "Windows" ;) "Hi, my name is Gopher, why does my sysadmin not give me an account?" ;) > > I think at least a check to see if the "amanda" user is < 1000 would > > make a lot of sense. > > I think restricting all rpm-created uids to < a limit (the value is > debatable) and presuming them to be local would be a reasonable > compromise Like Bill wrote, have useradd -r bail out if the uid is outside the range. But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones, 500-... for users. If you touch this (e.g. extend to 1000) you break a lot of stuff like user homes. We may need to do so some day, but this is so invasive that we probably need to make a case before the LSB get some preapproval that they recognise the need and will consider this topic for the next draft and then start making lots of heads-up noise to have sysadmins make space there in time (e.g. move their users to another id range). Since this is a lot of effort required from various players we really should very carefully consider when and what to ask for (e.g. ask for 1000 when two years later it will be considered that 2000 would had been better and redo the whole dance?). But the current discussion is orthogonal to this. It is very good that this information is encapsulated in useradd, so the packages need not know anything. So whenever these ranges (if ever change) all packages will not even need a rebuild. I vote for Ville's draft with a plea to the useradd maintainer to make useradd -r fail if the result is that the uid/gid is not in the system range. And also have the %pre script miseably fail to wake up the sysadmin ("Hugh, we have a user called Gopher?"). -- 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 rich at annexia.org Fri Jun 15 09:05:07 2007 From: rich at annexia.org (Richard Jones) Date: Fri, 15 Jun 2007 10:05:07 +0100 Subject: [Fedora-packaging] Re: "slicing" ocaml 3.10.0: comparison with debian friends? In-Reply-To: <20070615084432.GA16360@takhisis.invalid> References: <20070614190201.GA10361@takhisis.invalid> <20070614192936.GA8974@furbychan.cocan.org> <20070614200501.GB11750@takhisis.invalid> <20070614210650.GA29184@furbychan.cocan.org> <20070614213053.GA14200@takhisis.invalid> <20070615073454.GB1519@furbychan.cocan.org> <20070615084432.GA16360@takhisis.invalid> Message-ID: <20070615090507.GA6518@furbychan.cocan.org> On Fri, Jun 15, 2007 at 09:44:32AM +0100, Stefano Zacchiroli wrote: > On Fri, Jun 15, 2007 at 08:34:54AM +0100, Richard Jones wrote: > > > Still, native code objects can break link time compatibility with > > > compatible .cmis. > > I don't understand - why is this? > > Out of the box I don't know how to reproduce it, but we have been beaten > by this in the past. IIRC md5sum information stored in native code > objects are not only about interfaces but also about the actual module > implementations. Given that they are not inspectable (ocamlobjinfo only > work on bytecode objects) you have no way to check them. I think we've dealt with this one by depending on the name-version-release of ocaml itself. This makes it an all-or-nothing thing: as on Debian we need to upgrade every OCaml package at the same time. This is causing a problem at the moment because I can't get PXP & CDuce compiled. CDuce upstream have released a full version for OCaml 3.10, but PXP (on which CDuce depends) haven't done so yet. Rich. -- Richard Jones Red Hat From rich at annexia.org Fri Jun 15 10:02:31 2007 From: rich at annexia.org (Richard Jones) Date: Fri, 15 Jun 2007 11:02:31 +0100 Subject: [Fedora-packaging] Re: native code incompatibilities vs byte code incompatibilities In-Reply-To: <20070615090444.GA19595@takhisis.invalid> References: <20070614190201.GA10361@takhisis.invalid> <20070614192936.GA8974@furbychan.cocan.org> <20070614200501.GB11750@takhisis.invalid> <20070614210650.GA29184@furbychan.cocan.org> <20070614213053.GA14200@takhisis.invalid> <20070615073454.GB1519@furbychan.cocan.org> <20070615084432.GA16360@takhisis.invalid> <20070615090444.GA19595@takhisis.invalid> Message-ID: <20070615100231.GB6518@furbychan.cocan.org> On Fri, Jun 15, 2007 at 10:04:44AM +0100, Stefano Zacchiroli wrote: > On Fri, Jun 15, 2007 at 09:44:32AM +0100, Stefano Zacchiroli wrote: > > > > Still, native code objects can break link time compatibility with > > > > compatible .cmis. > > > I don't understand - why is this? > > I'll try to reproduce the problem in a sandbox... > > Ok, here is an example and an explanation: > > $ cat a.ml b.ml main.ml > (* a.ml *) > let foo () = 1 > (* b.ml *) > let bar () = A.foo () + 1 > (* main.ml *) > print_int (B.bar ()) > $ # let's build in bytecode and nativecode (with inlining) > $ ocamlc -c a.ml > $ ocamlc -c b.ml > $ ocamlc -o a.byte a.cmo b.cmo main.ml > $ ocamlopt -inline 100 -c a.ml > $ ocamlopt -inline 100 -c b.ml > $ ocamlopt -o a.native a.cmx b.cmx main.ml > $ # now let's change the *implementation* of module A and recompile that module only > $ sed -i s/1/2/ a.ml > $ ocamlc -c a.ml > $ # relinking in bytecode work, i.e. assumptions over interfaces are respected > $ ocamlc -o a.byte a.cmo b.cmo main.ml > $ # relinking in nativecode fails, i.e. assumptions over implementations are not respected > $ ocamlopt -inline 100 -c a.ml > $ ocamlopt -o a.native a.cmx b.cmx main.ml > Files b.cmx and a.cmx make inconsistent assumptions over implementation A > > The rationale is that with inlining enabled, ocamlopt when building > module B has embedded in it implementations coming from module A. If > that is changed module B needs to be rebuilt as well. > > Now: do you have a way to inspect native code objects for extracting > assumptions related to module implementations? Cause we have been so far > able only to extract assumption about interfaces... OK, I see the point now. I had assumed -- wrongly -- that the hash of a.cmo would change in this case, but it does not. So we need a version of ocamlobjinfo which can handle *.cmx files as well. There is another problem with ocamlobjinfo too. See: http://groups.google.co.uk/group/fa.caml/msg/f2c3e9e8cfa628b3?hl=en& In Fedora we have avoided this by having a list of modules in the standard library which we just ignore (Asttypes, Outcometree and Cmo_format so far). Rich. -- Richard Jones Red Hat From Axel.Thimm at ATrpms.net Fri Jun 15 10:58:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 12:58:01 +0200 Subject: [Fedora-packaging] ocaml signature hashing: really neccessary? Message-ID: <20070615105801.GA12099@neu.nirvana> I wonder whether this is maybe overdesigned. AFAIU this signature hashing was made because ocaml is not considered stable enough to carry over signatures from release to release. Same could be told about hundreds of C libraries, wouldn't the neccessity in ocaml then imply a neccessity to hash C-library APIs as well? Maybe it's something we will consider to do someday, but the order would be to cater for C/C++/Fortran/etc libraries first and then for niche languages like ocaml. I think it's a bit too much, or did I miss something important (I'm not a real ocaml user, there is just this one application that even justifies ocaml's existance ;) -- 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 rjones at redhat.com Fri Jun 15 11:29:13 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 15 Jun 2007 12:29:13 +0100 Subject: [Fedora-packaging] ocaml signature hashing: really neccessary? In-Reply-To: <20070615105801.GA12099@neu.nirvana> References: <20070615105801.GA12099@neu.nirvana> Message-ID: <46727809.80501@redhat.com> Axel Thimm wrote: > I wonder whether this is maybe overdesigned. AFAIU this signature > hashing was made because ocaml is not considered stable enough to > carry over signatures from release to release. > > Same could be told about hundreds of C libraries, wouldn't the > neccessity in ocaml then imply a neccessity to hash C-library APIs as > well? Maybe it's something we will consider to do someday, but the > order would be to cater for C/C++/Fortran/etc libraries first and then > for niche languages like ocaml. > > I think it's a bit too much, or did I miss something important (I'm > not a real ocaml user, there is just this one application that even > justifies ocaml's existance ;) No, it's really necessary and has nothing to do with stability or otherwise of OCaml (which is a very mature language that has been around in one form or another since the mid 80s). When OCaml compiles a library A, it takes a hash over the whole interface -- every single function, every argument to every function, and some of the internals, are just some of the things included in this hash. When OCaml compiles library B which depends on library A, it encodes the hash of A into B. Now we come to link a program against library B (and hence against library A). The hashes are checked and the linking will fail if, for example, the hash of A has changed since B was compiled. C has only weak checking in comparison. Sure, you can change a library, but you'd better hope for example that some struct in that library didn't change the size of one of its fields. If it did your program will still link, but will fail in interesting ways at runtime. OCaml's checking has the big downside, which is that it goes above and beyond what is necessary for just checking compatibility. For example, you can't add more functions to library A, even though such a change is probably safe. Nevertheless, RPM hashes are just enforcing what the OCaml linker enforces, and without them you'd be able to install incompatible OCaml RPMs which won't actually work together. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rich at annexia.org Fri Jun 15 11:53:40 2007 From: rich at annexia.org (Richard Jones) Date: Fri, 15 Jun 2007 12:53:40 +0100 Subject: [Fedora-packaging] Re: native code incompatibilities vs byte code incompatibilities In-Reply-To: <20070615101930.GA29519@takhisis.invalid> References: <20070614190201.GA10361@takhisis.invalid> <20070614192936.GA8974@furbychan.cocan.org> <20070614200501.GB11750@takhisis.invalid> <20070614210650.GA29184@furbychan.cocan.org> <20070614213053.GA14200@takhisis.invalid> <20070615073454.GB1519@furbychan.cocan.org> <20070615084432.GA16360@takhisis.invalid> <20070615090444.GA19595@takhisis.invalid> <20070615100231.GB6518@furbychan.cocan.org> <20070615101930.GA29519@takhisis.invalid> Message-ID: <20070615115340.GA19078@furbychan.cocan.org> On Fri, Jun 15, 2007 at 11:19:30AM +0100, Stefano Zacchiroli wrote: > On Fri, Jun 15, 2007 at 11:02:31AM +0100, Richard Jones wrote: > > OK, I see the point now. I had assumed -- wrongly -- that the hash of > > a.cmo would change in this case, but it does not. So we need a > > version of ocamlobjinfo which can handle *.cmx files as well. > > Right, that's our issue to. Maybe now we are two different large > distribution we have more power to go and ask INRIA for this? > > Julien: can you refresh our memory about the tool (IIRC) you spotted in > the OCaml sources able to extract info from *.cmx files? > > > There is another problem with ocamlobjinfo too. See: > > http://groups.google.co.uk/group/fa.caml/msg/f2c3e9e8cfa628b3?hl=en& > > > > In Fedora we have avoided this by having a list of modules in the > > standard library which we just ignore (Asttypes, Outcometree and > > Cmo_format so far). > > Ok, maybe we can keep it on a shared wiki page to ease of maintenance? Yup, I don't mind. Rich. -- Richard Jones Red Hat From tcallawa at redhat.com Fri Jun 15 13:50:58 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 15 Jun 2007 08:50:58 -0500 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <20070615073805.GG30568@neu.nirvana> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> <1181886462.13412.57.camel@mccallum.corsepiu.local> <20070615073805.GG30568@neu.nirvana> Message-ID: <1181915458.30197.3.camel@localhost.localdomain> On Fri, 2007-06-15 at 09:38 +0200, Axel Thimm wrote: > Like Bill wrote, have useradd -r bail out if the uid is outside the > range. > > But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones, > 500-... for users. If you touch this (e.g. extend to 1000) you break a > lot of stuff like user homes. I'm not opposed to this. Now, someone needs to figure out how. > I vote for Ville's draft with a plea to the useradd maintainer to make > useradd -r fail if the result is that the uid/gid is not in the system > range. And also have the %pre script miseably fail to wake up the > sysadmin ("Hugh, we have a user called Gopher?"). The last part is not going to work. %pre can never fail, it will break a transaction in unfortunate ways. Useradd can fail, but we need to silently mask it. Output from %pre is not useful in a kickstart transaction. ~spot From notting at redhat.com Fri Jun 15 13:53:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Jun 2007 09:53:41 -0400 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181915458.30197.3.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> <1181886462.13412.57.camel@mccallum.corsepiu.local> <20070615073805.GG30568@neu.nirvana> <1181915458.30197.3.camel@localhost.localdomain> Message-ID: <20070615135341.GD6888@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > > But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones, > > 500-... for users. If you touch this (e.g. extend to 1000) you break a > > lot of stuff like user homes. > > I'm not opposed to this. Now, someone needs to figure out how. This *should* be a relatively simple patch to shadow-utils. Bill From tcallawa at redhat.com Fri Jun 15 14:22:58 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 15 Jun 2007 09:22:58 -0500 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <20070615135341.GD6888@nostromo.devel.redhat.com> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> <1181886462.13412.57.camel@mccallum.corsepiu.local> <20070615073805.GG30568@neu.nirvana> <1181915458.30197.3.camel@localhost.localdomain> <20070615135341.GD6888@nostromo.devel.redhat.com> Message-ID: <1181917378.30197.5.camel@localhost.localdomain> On Fri, 2007-06-15 at 09:53 -0400, Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: > > > But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones, > > > 500-... for users. If you touch this (e.g. extend to 1000) you break a > > > lot of stuff like user homes. > > > > I'm not opposed to this. Now, someone needs to figure out how. > > This *should* be a relatively simple patch to shadow-utils. *sniff, sniff* I smell a volunteer! ~spot From Axel.Thimm at ATrpms.net Fri Jun 15 15:34:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 17:34:51 +0200 Subject: [Fedora-packaging] Re: ocaml signature hashing: really neccessary? In-Reply-To: <46727809.80501@redhat.com> References: <20070615105801.GA12099@neu.nirvana> <46727809.80501@redhat.com> Message-ID: <20070615153451.GF9813@neu.nirvana> On Fri, Jun 15, 2007 at 12:29:13PM +0100, Richard W.M. Jones wrote: > Axel Thimm wrote: > >I wonder whether this is maybe overdesigned. AFAIU this signature > >hashing was made because ocaml is not considered stable enough to > >carry over signatures from release to release. > > > >Same could be told about hundreds of C libraries, wouldn't the > >neccessity in ocaml then imply a neccessity to hash C-library APIs as > >well? Maybe it's something we will consider to do someday, but the > >order would be to cater for C/C++/Fortran/etc libraries first and then > >for niche languages like ocaml. > > > >I think it's a bit too much, or did I miss something important (I'm > >not a real ocaml user, there is just this one application that even > >justifies ocaml's existance ;) > > No, it's really necessary and has nothing to do with stability or > otherwise of OCaml (which is a very mature language that has been around > in one form or another since the mid 80s). > > When OCaml compiles a library A, it takes a hash over the whole > interface -- every single function, every argument to every function, > and some of the internals, are just some of the things included in this > hash. > > When OCaml compiles library B which depends on library A, it encodes the > hash of A into B. > > Now we come to link a program against library B (and hence against > library A). The hashes are checked and the linking will fail if, for > example, the hash of A has changed since B was compiled. > > C has only weak checking in comparison. Sure, you can change a library, > but you'd better hope for example that some struct in that library > didn't change the size of one of its fields. If it did your program > will still link, but will fail in interesting ways at runtime. > > OCaml's checking has the big downside, which is that it goes above and > beyond what is necessary for just checking compatibility. For example, > you can't add more functions to library A, even though such a change is > probably safe. Nevertheless, RPM hashes are just enforcing what the > OCaml linker enforces, and without them you'd be able to install > incompatible OCaml RPMs which won't actually work together. Thanks Rich for dusting off an old mind. I agree, if this is an upstream mechanism that makes even conventional rpm packaging fail, then we need that. I thought it was something put on top of ocaml, e.g. a pure packaging level hashing. Standing corrected and in agreement 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 Axel.Thimm at ATrpms.net Fri Jun 15 15:41:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 15 Jun 2007 17:41:50 +0200 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181915458.30197.3.camel@localhost.localdomain> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> <1181886462.13412.57.camel@mccallum.corsepiu.local> <20070615073805.GG30568@neu.nirvana> <1181915458.30197.3.camel@localhost.localdomain> Message-ID: <20070615154150.GG9813@neu.nirvana> On Fri, Jun 15, 2007 at 08:50:58AM -0500, Tom spot Callaway wrote: > On Fri, 2007-06-15 at 09:38 +0200, Axel Thimm wrote: > > Like Bill wrote, have useradd -r bail out if the uid is outside the > > range. > > > > But the range is fixed, 0-99 for static ids, 100-499 for dynamic ones, > > 500-... for users. If you touch this (e.g. extend to 1000) you break a > > lot of stuff like user homes. > > I'm not opposed to this. Now, someone needs to figure out how. > > > I vote for Ville's draft with a plea to the useradd maintainer to make > > useradd -r fail if the result is that the uid/gid is not in the system > > range. And also have the %pre script miseably fail to wake up the > > sysadmin ("Hugh, we have a user called Gopher?"). > > The last part is not going to work. %pre can never fail, it will break a > transaction in unfortunate ways. Useradd can fail, but we need to > silently mask it. Output from %pre is not useful in a kickstart > transaction. Every silent recovery will bear security issues. Either the files get owned by a user, or by root, both are not acceptable imo. So we need to have this package installation fail. The issue with depsolvers messing up a transaction needs to fixed irrespective of this particular case. And I think the fix is also rather simple (no, not volunteering!): smart for example has a mode to install/remove package by package instead of installing all packages and then uninstalling the old ones. Whne something fails in this mode be it %pre or %post it only messes up exactly zero to one packages (%pre zero, %post one). An alternative route would be for yum to see that in a transaction package $N failed and instead of bailing out directly after that to run the clenup part for packages 1-($N-1). This also doesn't sound like impossible to do (still not volunteering ;). So it's a bug that looks fixable with sane effort and we should not need to obfuscate specfiles or drop features like %pre exiting due to 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 tibbs at math.uh.edu Fri Jun 15 15:50:48 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Jun 2007 10:50:48 -0500 Subject: [Fedora-packaging] Re: Possible UsersAndGroupsDraft In-Reply-To: <1181886462.13412.57.camel@mccallum.corsepiu.local> References: <1181796327.1400.4.camel@localhost.localdomain> <20070614081959.GH7708@neu.nirvana> <1181828416.1400.7.camel@localhost.localdomain> <20070614152504.GM16315@neu.nirvana> <1181841688.3794.27.camel@willson> <1181886462.13412.57.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> The worst case probably is using a "last name is username" RC> convention and your last name being "Root", "Mail" or "Windows" ;) If this really concerns us, then we could consider a naming policy for system users. Something like prefixing them with "sys-", maybe. We've already broken the 8-character limit for system users (haldaemon), so it's not as if this would be getting into new territory. - J< From tibbs at math.uh.edu Mon Jun 18 19:39:52 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 18 Jun 2007 14:39:52 -0500 Subject: [Fedora-packaging] Proposal: Allow upstream VCS commit ID in alphatag Message-ID: I have drafted http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs and added it to the schedule. The proposal is simply to add the following text to the naming guidelines to the "Snapshot packages" section: If the upstream revision control system provides some sort of unique commit identifier, it may be appended to the `%{alphatag}`: {{{ YYYYMMDDsvn12345 YYYYMMDDgit5aef11739b }}} This has been in use for a while in a few instances, so it would be good to consider it officially. - J< From katzj at redhat.com Tue Jun 19 19:11:26 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Jun 2007 15:11:26 -0400 Subject: [Fedora-packaging] Hardlinking *.pyc and *.pyo In-Reply-To: <1181763075.6354.7.camel@aglarond.local> References: <200704031342.25238.ville.skytta@iki.fi> <200706132151.55089.ville.skytta@iki.fi> <1181763075.6354.7.camel@aglarond.local> Message-ID: <1182280286.11891.22.camel@aglarond.local> On Wed, 2007-06-13 at 15:31 -0400, Jeremy Katz wrote: > On Wed, 2007-06-13 at 21:51 +0300, Ville Skytt? wrote: > > On Tuesday 03 April 2007, Ville Skytt? wrote: > > > Related to recent space saving discussions, I came across PLD's > > > rpm-build-macros package recently, and found that they hardlink > > > identical *.pyc and *.pyo. > > [...] > > > The PLD implementation looks like this: > > [...] > > > The use of "cmp" would require diffutils installed. Or the above > > > could be converted to use hardlink instead (which would have to be made > > > sure to be around) or maybe sha1sum (in coreutils, pretty much always > > > around in buildroots). > > > > > > I suppose something like the above could be easily added to > > > redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile > > > or run after it in %__os_install_post. > > > > Jeremy pinged me about resurrecting this thread, so here goes, the original > > threads starts at > > http://www.redhat.com/archives/fedora-packaging/2007-April/msg00003.html for > > those who missed it. > > > > Anyway, attached is a patch against rpm.org hg for discussion - seems somewhat > > clumsy to use sha1sum for this but I guess it could be acceptable. Tested on > > just a few python packages on F-7. Better implementations certainly exist, > > and are welcome :) > > Looks okay to me. Probably the easiest thing to do is to put it in > redhat-rpm-config for now[1] and then go from there. If anyone > disagrees with it, raise your hands... otherwise, I'll get it in the > start of next week And this is done in redhat-rpm-config-9.0.0-1 that I just built. Jeremy From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jun 22 12:49:38 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 22 Jun 2007 14:49:38 +0200 Subject: [Fedora-packaging] Update to php-eaccelerator and how to make it "just work" Message-ID: <20070622144938.4c72a26b@python3.es.egwn.lan> Hi, I'm currently cleaning up the php-eaccelerator package. It has been in Fedora since the very beginning and I'm pretty sure it never went through any review (straight from freshrpms). The major change I have to do is "fix" the version : "5.2.3_0.9.5.1" has to become plain "0.9.5.1" ...so I'll have to introduce and epoch :-( The problem is historical, as the module had to track the main php package's version quite closely, back when the zend_abi version wasn't provided by the php package, and this ugly trick was an easy way for end users to know if the package was the correct one. Anyway, I'll be doing that unless someone objects ;-) The next issue is that the cache files created by the module are stored in /var/cache/php-eaccelerator/ and the ownership of that directory is hardcoded to apache:apache in the package. This is a problem when using php with another web server, lighttpd for instance (which I do a lot). It's even worse when using multiple web servers on the same machine... I'd like the find a clean solution for this. The only one I can think of is to have php-eaccelerator create its own group in which it'll put apache, lighttpd and eventually others, and have the cache directory owned by "root:eacceler" (it's better with only 8 chars, right?) and set g+S. This way, all web servers should be able to write and read cache files. I was also thinking of adding the web server users to the group by using triggers in the php-eaccelerator package. Does this seem sane to do? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.72 0.81 0.81 From Axel.Thimm at ATrpms.net Fri Jun 22 14:20:30 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Jun 2007 16:20:30 +0200 Subject: [Fedora-packaging] Re: Update to php-eaccelerator and how to make it "just work" In-Reply-To: <20070622144938.4c72a26b@python3.es.egwn.lan> References: <20070622144938.4c72a26b@python3.es.egwn.lan> Message-ID: <20070622142030.GH3087@puariko.nirvana> On Fri, Jun 22, 2007 at 02:49:38PM +0200, Matthias Saou wrote: > The only one I can think of is to have php-eaccelerator create its > own group in which it'll put apache, lighttpd and eventually others, This package will be installable w/o pulling in all those packages and some of them create their user at package installation time. Which means that when php-eaccelerator is installed, but say lighttpd not, how would php-eaccelerator be able to add lighttpd into its group? Sounds like you would end up with %triggers. -- 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 Fri Jun 22 14:27:26 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 22 Jun 2007 16:27:26 +0200 Subject: [Fedora-packaging] Re: Update to php-eaccelerator and how to make it "just work" In-Reply-To: <20070622142030.GH3087@puariko.nirvana> References: <20070622144938.4c72a26b@python3.es.egwn.lan> <20070622142030.GH3087@puariko.nirvana> Message-ID: <20070622162726.5261f1de@python3.es.egwn.lan> Axel Thimm wrote : > On Fri, Jun 22, 2007 at 02:49:38PM +0200, Matthias Saou wrote: > > The only one I can think of is to have php-eaccelerator create its > > own group in which it'll put apache, lighttpd and eventually others, > > This package will be installable w/o pulling in all those packages and > some of them create their user at package installation time. Which > means that when php-eaccelerator is installed, but say lighttpd not, > how would php-eaccelerator be able to add lighttpd into its group? > > Sounds like you would end up with %triggers. That's what I wrote :-) You trimmed this part : "I was also thinking of adding the web server users to the group by using triggers in the php-eaccelerator package." The other "middle ground" solution I can think of is to have the cache directory be owned by "apache:eacceler" and mode g+wS as it would then work out-of-the-box with apache, and would only require adding any other web server users to the "eacceler" group for them to start working too. (note that all cache directories and files are created world readable/writable, which is why I currently "protect" the main cache directory with a restrictive mode, as it would be a big security issue otherwise) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.14 0.33 0.33 From rdieter at math.unl.edu Fri Jun 22 13:10:45 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 22 Jun 2007 08:10:45 -0500 Subject: [Fedora-packaging] Re: Update to php-eaccelerator and how to make it "just work" References: <20070622144938.4c72a26b@python3.es.egwn.lan> Message-ID: Matthias Saou wrote: > Does this seem sane to do? sane +1 -- Rex From Axel.Thimm at ATrpms.net Fri Jun 22 16:25:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Jun 2007 18:25:15 +0200 Subject: [Fedora-packaging] Re: Update to php-eaccelerator and how to make it "just work" In-Reply-To: <20070622162726.5261f1de@python3.es.egwn.lan> References: <20070622144938.4c72a26b@python3.es.egwn.lan> <20070622142030.GH3087@puariko.nirvana> <20070622162726.5261f1de@python3.es.egwn.lan> Message-ID: <20070622162515.GJ3087@puariko.nirvana> On Fri, Jun 22, 2007 at 04:27:26PM +0200, Matthias Saou wrote: > Axel Thimm wrote : > > > On Fri, Jun 22, 2007 at 02:49:38PM +0200, Matthias Saou wrote: > > > The only one I can think of is to have php-eaccelerator create its > > > own group in which it'll put apache, lighttpd and eventually others, > > > > This package will be installable w/o pulling in all those packages and > > some of them create their user at package installation time. Which > > means that when php-eaccelerator is installed, but say lighttpd not, > > how would php-eaccelerator be able to add lighttpd into its group? > > > > Sounds like you would end up with %triggers. > > That's what I wrote :-) You trimmed this part : > > "I was also thinking of adding the web server users to the group by > using triggers in the php-eaccelerator package." /me apologizes and goes read a book on "learning to read". :) But obviously I agree with your approach ;) -- 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 Sun Jun 24 10:01:21 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 24 Jun 2007 13:01:21 +0300 Subject: [Fedora-packaging] Update to php-eaccelerator and how to make it "just work" In-Reply-To: <20070622144938.4c72a26b@python3.es.egwn.lan> References: <20070622144938.4c72a26b@python3.es.egwn.lan> Message-ID: <200706241301.21345.ville.skytta@iki.fi> On Friday 22 June 2007, Matthias Saou wrote: > The next issue is that the cache files created by the module are stored > in /var/cache/php-eaccelerator/ and the ownership of that directory is > hardcoded to apache:apache in the package. This is a problem when using > php with another web server, lighttpd for instance (which I do a lot). > It's even worse when using multiple web servers on the same machine... Are the cache files written by (multiple instances of) php-eaccelerator clash free? Ie. always the same for file /path/to/foo.php (I don't know if the caching works at that level, but to illustrate the point), no matter which web server it's being run with, or use a different filename/path for differing cached versions of something? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jun 25 08:36:02 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 25 Jun 2007 10:36:02 +0200 Subject: [Fedora-packaging] Update to php-eaccelerator and how to make it "just work" In-Reply-To: <200706241301.21345.ville.skytta@iki.fi> References: <20070622144938.4c72a26b@python3.es.egwn.lan> <200706241301.21345.ville.skytta@iki.fi> Message-ID: <20070625103602.31ba0a9a@python3.es.egwn.lan> Ville Skytt? wrote : > On Friday 22 June 2007, Matthias Saou wrote: > > > The next issue is that the cache files created by the module are stored > > in /var/cache/php-eaccelerator/ and the ownership of that directory is > > hardcoded to apache:apache in the package. This is a problem when using > > php with another web server, lighttpd for instance (which I do a lot). > > It's even worse when using multiple web servers on the same machine... > > Are the cache files written by (multiple instances of) php-eaccelerator clash > free? Ie. always the same for file /path/to/foo.php (I don't know if the > caching works at that level, but to illustrate the point), no matter which > web server it's being run with, or use a different filename/path for > differing cached versions of something? I *think* it'll always be the same. I'll do a bit of testing to be sure, and if there's any kind of problem, I will simply add some README indicating the few corner-cases to avoid. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.24 0.41 0.47 From tcallawa at redhat.com Mon Jun 25 18:56:17 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 25 Jun 2007 13:56:17 -0500 Subject: [Fedora-packaging] License issue for all GIS related packages. [call for help] In-Reply-To: <1181746957.4593.6.camel@localhost.localdomain> References: <200706131641.49194.cbalint@redhat.com> <1181746957.4593.6.camel@localhost.localdomain> Message-ID: <1182797777.29010.54.camel@localhost.localdomain> On Wed, 2007-06-13 at 10:02 -0500, Tom "spot" Callaway wrote: > The new license looks ok to me, I will pass it along to the FSF for > review, even though the EPSG dataset is content, not code, their opinion > is always valued on licensing matters. The FSF pointed out a few things: 1. The line between functional code and content is very blurry here. This dataset is effectively code, as much a struct of PCI IDs would be. 2. The new changes in the EPSG dataset licensing are a strong step in the right direction. 3. However, the license needs to explicitly allow all sorts of modification. Perhaps someone would want to add their own coordinate reference system in the future. The new license text does not permit this. A clause similar to that used in other licenses, where the modified version must be marked as modified, may not call itself the EPSG dataset, etc, etc, would be acceptable. 4. Without that explicit permission to modify the dataset, the license is not considered Free, and is not acceptable for Fedora. The FSF wanted to emphasize that they are appreciative of the hard work done to improve this license, and they are willing to assist in the process of amending this license so that it is Free. ~spot From tcallawa at redhat.com Mon Jun 25 23:00:46 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 25 Jun 2007 18:00:46 -0500 Subject: [Fedora-packaging] License issue for all GIS related packages. [call for help] In-Reply-To: <200706260035.33750.cbalint@redhat.com> References: <200706131641.49194.cbalint@redhat.com> <1181746957.4593.6.camel@localhost.localdomain> <1182797777.29010.54.camel@localhost.localdomain> <200706260035.33750.cbalint@redhat.com> Message-ID: <1182812446.29010.83.camel@localhost.localdomain> On Tue, 2007-06-26 at 00:35 +0200, Balint Cristian wrote: > Pardon me if i mistake here, a _non_ lawyer point of view: > > Here arised in my mind that epsg tables ar not similar as PCI ID > plain only database, a new entry in that database need certain > certification and probaly very precise technical mesurments before it > can > be validated and ratified. I dont think anyone can easy do this step, > like just PCI-ID ones. EPSG asummed this task to collect cand > ertificate those > constants and projections in the past. The process is not an easy one > as far > I understanded, but this is only the technical side. That could be > olso the strong > reason to not let those constants to be altered in some way. > > Please correct me if i mistakenly miss understood that EPSG > activity from > tech point of view. Just wanted make some comment over certain value > of > database. I think that there are several good parallels here, the most obvious seems to be that of the GNU Free Documentation License (GFDL), specifically section 4, which permits modification, but also describes what you must do as the end result of modification. Another good example is the Bitstream Font License. Bitstream wanted to make their Fonts available for the Free Software community, and to permit people to make derived fonts from Bitstream fonts, but they didn't want people selling the fonts standalone, or referring to any derived fonts as "Bitstream". Here is their license, in its entirety: ====================== Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream Vera is a trademark of Bitstream, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of the fonts accompanying this license (?Fonts?) and associated documentation files (the ?Font Software?), to reproduce and distribute the Font Software, including without limitation the rights to use, copy, merge, publish, distribute, and/or sell copies of the Font Software, and to permit persons to whom the Font Software is furnished to do so, subject to the following conditions: The above copyright and trademark notices and this permission notice shall be included in all copies of one or more of the Font Software typefaces. The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words ?Bitstream? or the word ?Vera?. This License becomes null and void to the extent applicable to Fonts or Font Software that has been modified and is distributed under the ?Bitstream Vera? names. The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL BITSTREAM OR THE GNOME FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE. Except as contained in this notice, the names of Gnome, the Gnome Foundation, and Bitstream Inc., shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Font Software without prior written authorization from the Gnome Foundation or Bitstream Inc., respectively. For further information, contact: fonts at gnome dot org. ====================== So, to sum it up, here's what we would like to see: The license needs to permit people to create derived works of the EPSG dataset. Simply because we cannot fathom any possible derived works does not mean that the right should be withheld. This is at the very heart of open source and free software. However, it is perfectly acceptable to say that those derived works may not call themselves the EPSG dataset. If we can get that, we can include the EPSG dataset in Fedora. :) ~spot From cbalint at redhat.com Mon Jun 25 23:27:19 2007 From: cbalint at redhat.com (Balint Cristian) Date: Tue, 26 Jun 2007 01:27:19 +0200 Subject: [Fedora-packaging] License issue for all GIS related packages. [call for help] In-Reply-To: <1182812446.29010.83.camel@localhost.localdomain> References: <200706131641.49194.cbalint@redhat.com> <200706260035.33750.cbalint@redhat.com> <1182812446.29010.83.camel@localhost.localdomain> Message-ID: <200706260127.19899.cbalint@redhat.com> > ====================== > > So, to sum it up, here's what we would like to see: > > The license needs to permit people to create derived works of the EPSG > dataset. Simply because we cannot fathom any possible derived works does > not mean that the right should be withheld. This is at the very heart of > open source and free software. However, it is perfectly acceptable to > say that those derived works may not call themselves the EPSG dataset. Yes I agree. Understood here. However to be bad a bit, i really look forward for someone who can invent a new projection for his own pospose :-) Maybe. It will be never used by no one, not even for survey the back yard garden :) Maybe bottom of my aquarium ? it wouldn be serious one at all. But than, e.g if i invent one wich i think fit perfect for some land i will look forward anyway for someone's help to certificate at all it, since i will not be able to claim it is functional and better and more precise than i dont know wich one particulary. And if its about certificate it probably i go EPSG to help me out. Maybe its similar with encryption algorithms, where olso is pretty difficult to come out these days with a new one, and claim its performance and usability in some ways. I still can use my early high scool one invented "reverse mixing of ABC letters" TM at all, but probably just for send out mail to my girlfriend :-D Just my +.5 cent opinion, i still think here is very low interest to alter EPSG and make derivative work out of it. It see total nonsense in real world. > > If we can get that, we can include the EPSG dataset in Fedora. :) Would be great ! > ~spot > > > -- Balint Cristian (Red Hat Release Engineering Team) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jun 26 01:37:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 03:37:29 +0200 Subject: [Fedora-packaging] Re: License issue for all GIS related packages. [call for help] In-Reply-To: <200706260127.19899.cbalint@redhat.com> References: <200706131641.49194.cbalint@redhat.com> <200706260035.33750.cbalint@redhat.com> <1182812446.29010.83.camel@localhost.localdomain> <200706260127.19899.cbalint@redhat.com> Message-ID: <20070626013729.GH27093@puariko.nirvana> On Tue, Jun 26, 2007 at 01:27:19AM +0200, Balint Cristian wrote: > > > ====================== > > > > So, to sum it up, here's what we would like to see: > > > > The license needs to permit people to create derived works of the EPSG > > dataset. Simply because we cannot fathom any possible derived works does > > not mean that the right should be withheld. This is at the very heart of > > open source and free software. However, it is perfectly acceptable to > > say that those derived works may not call themselves the EPSG dataset. > > Yes I agree. Understood here. > > However to be bad a bit, i really look forward for someone who can invent a > new projection for his own pospose :-) Maybe. It will be never used by no one, > not even for survey the back yard garden :) Maybe bottom of my aquarium ? > it wouldn be serious one at all. A projection would be an application of the data, not a modification of this data. And the EPSG data aren't the holy grail either, there is more precise data available (non-free). Consider you being a company or some entity that wants to refine the data for a certain part of the world, you wouldn't have the right to do so. I can think of tons of applications that would require changing/refining the data. Even for changing the format and base coordination system to adapt to computations for a given problem, which semantically would not modify the data, but technically it does and could be violating the license again (I haven't read the license, just infering from what this thread is discussing). > But than, e.g if i invent one wich i think fit perfect for some land i will look > forward anyway for someone's help to certificate at all it, since i will not be able > to claim it is functional and better and more precise than i dont know wich one > particulary. And if its about certificate it probably i go EPSG to help me out. Or maybe a competing entity that will have emerged. And with a non-free dataset you would be bound to the rights holder. > Maybe its similar with encryption algorithms, where olso is pretty difficult > to come out these days with a new one, and claim its performance and usability > in some ways. I still can use my early high scool one invented > "reverse mixing of ABC letters" TM at all, but probably just for send out mail to my > girlfriend :-D > > Just my +.5 cent opinion, i still think here is very low interest to alter EPSG and > make derivative work out of it. It see total nonsense in real world. > > > > > > If we can get that, we can include the EPSG dataset in Fedora. :) > > Would be great ! > > > ~spot > > > > > > > > > -- 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 Tue Jun 26 07:33:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 26 Jun 2007 09:33:00 +0200 Subject: [Fedora-packaging] one big SRPM for lots of different stardict dictionaries? Message-ID: <4680C12C.8020904@leemhuis.info> Hi, I stumbled over the CVS branch creation commit mails for a package called "stardict-dic" in my inbox and thought "hey, nice, someone packaged dictionaries for startdict". But then I took a closer look at the package and the review bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231267 and got a bit worried. The plan of the packager afaics seems to be to get all the current and future dictionaries for other languages into this one just-reviewed and approved package stardict-dic (SRPM currently 84 MByte in size afaics), from with multiple sub-packages get build (currently: stardict-dic-{en,ja,ru,zh_CN,zh_TW} ). The "one SRPM for all dicts" approach IMHO has major disadvantages IMHO: the SRPM will become really big if dictionaries for other languages become part of it. This might be acceptable, but for each added dict or each bug that gets fixed in one of the dictionaries the whole SRPM gets rebuild and thus all the stardict-dic-{en,ja,ru,zh_CN,zh_TW} packages get created newly as well, which creates a lot of load for mirrors and users to download and install (?). This sems very wrong to me; or am I overacting here? I'd say we should work towards a scheme similar to hunspell; e.g. one source package per language. Other opinions? CU thl (?) -- Example: - user foo install stardict-dic-en-2.4.2-2.fc7.noarch.rpm - maintainer add german dictionary to stardict-dic, increases release by one and rebuilds - user foo updates to stardict-dic-en-2.4.2-3.fc7.noarch.rpm - maintainer add spanisch dictionary to stardict-dic, increases release by one and rebuilds - user foo updates to stardict-dic-en-2.4.2-4.fc7.noarch.rpm - and so on From rc040203 at freenet.de Tue Jun 26 08:26:04 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 26 Jun 2007 10:26:04 +0200 Subject: [Fedora-packaging] one big SRPM for lots of different stardict dictionaries? In-Reply-To: <4680C12C.8020904@leemhuis.info> References: <4680C12C.8020904@leemhuis.info> Message-ID: <1182846364.3859.45.camel@mccallum.corsepiu.local> On Tue, 2007-06-26 at 09:33 +0200, Thorsten Leemhuis wrote: > Hi, > > I stumbled over the CVS branch creation commit mails for a package > called "stardict-dic" in my inbox and thought "hey, nice, someone > packaged dictionaries for startdict". But then I took a closer look at > the package and the review bug > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231267 > and got a bit worried. > > The plan of the packager afaics seems to be to get all the current and > future dictionaries for other languages into this one just-reviewed and > approved package stardict-dic (SRPM currently 84 MByte in size afaics), > from with multiple sub-packages get build (currently: > stardict-dic-{en,ja,ru,zh_CN,zh_TW} ). > > The "one SRPM for all dicts" approach IMHO has major disadvantages IMHO: > the SRPM will become really big if dictionaries for other languages > become part of it. This might be acceptable, but for each added dict or > each bug that gets fixed in one of the dictionaries the whole SRPM gets > rebuild and thus all the stardict-dic-{en,ja,ru,zh_CN,zh_TW} packages > get created newly as well, which creates a lot of load for mirrors and > users to download and install (?). > > This sems very wrong to me; or am I overacting here? No, I am inclined to agree with you. > I'd say we should work towards a scheme similar to hunspell; e.g. one > source package per language. Other opinions? One "srpm" would be appropriate if upstream ships one monolithic tarball or always generates all subpackage's tarballs from the same master source tree (CVS, SVN, etc.) at the same time (E.g. GCC does this, they are shipping alternative "monolithic" and "split" tarballs). Also consider: At the very moment the dictionaries' versions should diverge, this monolithic srpm enter problems with EVRs. Ralf From nicolas.mailhot at laposte.net Tue Jun 26 08:33:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 26 Jun 2007 10:33:44 +0200 (CEST) Subject: [Fedora-packaging] one big SRPM for lots of different stardict dictionaries? In-Reply-To: <4680C12C.8020904@leemhuis.info> References: <4680C12C.8020904@leemhuis.info> Message-ID: <44252.192.54.193.51.1182846824.squirrel@rousalka.dyndns.org> Le Mar 26 juin 2007 09:33, Thorsten Leemhuis a ?crit : > This sems very wrong to me; or am I overacting here? This is very wrong unless they are managed by a single project and released in a single archive. As a rule multiple package source archives should be the exception, and multiple source archives released by different upstreams totaly forbidden (IMHO). They just make solid upstream tracking a PITA, and confuse users. -- Nicolas Mailhot From panemade at gmail.com Tue Jun 26 09:05:39 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 26 Jun 2007 14:35:39 +0530 Subject: [Fedora-packaging] one big SRPM for lots of different stardict dictionaries? In-Reply-To: <4680C12C.8020904@leemhuis.info> References: <4680C12C.8020904@leemhuis.info> Message-ID: Hi, On 6/26/07, Thorsten Leemhuis wrote: > Hi, > > I stumbled over the CVS branch creation commit mails for a package > called "stardict-dic" in my inbox and thought "hey, nice, someone > packaged dictionaries for startdict". But then I took a closer look at > the package and the review bug > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231267 > and got a bit worried. > > The plan of the packager afaics seems to be to get all the current and > future dictionaries for other languages into this one just-reviewed and > approved package stardict-dic (SRPM currently 84 MByte in size afaics), > from with multiple sub-packages get build (currently: > stardict-dic-{en,ja,ru,zh_CN,zh_TW} ). > > The "one SRPM for all dicts" approach IMHO has major disadvantages IMHO: > the SRPM will become really big if dictionaries for other languages > become part of it. This might be acceptable, but for each added dict or > each bug that gets fixed in one of the dictionaries the whole SRPM gets > rebuild and thus all the stardict-dic-{en,ja,ru,zh_CN,zh_TW} packages > get created newly as well, which creates a lot of load for mirrors and > users to download and install (?). > > This sems very wrong to me; or am I overacting here? You are right. Sorry for my misunderstanding. I assumed and accepted submitter request to have all language dictionaries in single SPEC but forgot what will happen if upstream released new version for any dictionary. I have ping submitter on IRC and asked him to submit new package requests per language dictionary. thanks for pointing this issue. Regards, Parag. From zhu at redhat.com Tue Jun 26 09:23:08 2007 From: zhu at redhat.com (Hu Zheng) Date: Tue, 26 Jun 2007 17:23:08 +0800 Subject: [Fedora-packaging] one big SRPM for lots of different stardict dictionaries? Message-ID: <1182849788.3936.9.camel@dhcp-0-075.pek.redhat.com> I thought that we can add a de dictionary while keep en rpm's release number don't change, which is not true. I will submit new package requests per language dictionary. Thanks everyone! From Axel.Thimm at ATrpms.net Tue Jun 26 10:53:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 12:53:37 +0200 Subject: [Fedora-packaging] Re: one big SRPM for lots of different stardict dictionaries? In-Reply-To: <4680C12C.8020904@leemhuis.info> References: <4680C12C.8020904@leemhuis.info> Message-ID: <20070626105337.GG3345@puariko.nirvana> On Tue, Jun 26, 2007 at 09:33:00AM +0200, Thorsten Leemhuis wrote: > The plan of the packager afaics seems to be to get all the current and > future dictionaries for other languages into this one just-reviewed and > approved package stardict-dic (SRPM currently 84 MByte in size afaics), > from with multiple sub-packages get build (currently: > stardict-dic-{en,ja,ru,zh_CN,zh_TW} ). One valid worry of a submitter for such a case might be that he's afraid of having to redo all the review mechanics for every such small subpackage addition. Maybe we should allow template reviews, e.g. the submitter lists 5 packages that are almost identical but the explicit locale definition and get's a blanket-like approval granted of any further packages he will copy off this template. When new languages make it to the stack he simply adds a CVS request for another package pointing to the template approval. The same model could apply to font collections, themes 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 fedora at leemhuis.info Tue Jun 26 11:19:19 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 26 Jun 2007 13:19:19 +0200 Subject: [Fedora-packaging] Re: one big SRPM for lots of different stardict dictionaries? In-Reply-To: <20070626105337.GG3345@puariko.nirvana> References: <4680C12C.8020904@leemhuis.info> <20070626105337.GG3345@puariko.nirvana> Message-ID: <4680F637.4080603@leemhuis.info> On 26.06.2007 12:53, Axel Thimm wrote: > On Tue, Jun 26, 2007 at 09:33:00AM +0200, Thorsten Leemhuis wrote: > [...] > Maybe we should allow template reviews, e.g. the submitter lists 5 > packages that are almost identical but the explicit locale definition > and get's a blanket-like approval granted of any further packages he > will copy off this template. [...] I don't think a "blanket-like approval" makes sense, as at least the md5sums and the license actually still should be checked by a reviewer. Further: the reviewer of course can (and IMHO should) just do those two checks, run a "diff -u" of the approved spec file against the unapproved one, take a quick look at the differences and then approved the second package if everything looks sane. That can likely be done in less then 5 minutes and is not that much work. Sure, there is a small risk to miss a bug or problem, but that's life -- no reasons to unlock the orbital laser or to wake up Spot's nijas ( http://fedoraproject.org/wiki/TomCallaway/Ninjas ) :-) BTW, that's afaics how some of the reviews were done already (hunspell for example). Maybe it's worth to write that down somewhere in the wiki -- but there is IMHO no need to add it to the guidelines directly. CU thl From Axel.Thimm at ATrpms.net Tue Jun 26 11:31:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 13:31:34 +0200 Subject: [Fedora-packaging] Re: one big SRPM for lots of different stardict dictionaries? In-Reply-To: <4680F637.4080603@leemhuis.info> References: <4680C12C.8020904@leemhuis.info> <20070626105337.GG3345@puariko.nirvana> <4680F637.4080603@leemhuis.info> Message-ID: <20070626113134.GH3345@puariko.nirvana> On Tue, Jun 26, 2007 at 01:19:19PM +0200, Thorsten Leemhuis wrote: > On 26.06.2007 12:53, Axel Thimm wrote: > > On Tue, Jun 26, 2007 at 09:33:00AM +0200, Thorsten Leemhuis wrote: > > [...] > > Maybe we should allow template reviews, e.g. the submitter lists 5 > > packages that are almost identical but the explicit locale definition > > and get's a blanket-like approval granted of any further packages he > > will copy off this template. [...] > > I don't think a "blanket-like approval" makes sense, as at least the > md5sums and the license actually still should be checked by a reviewer. > > Further: the reviewer of course can (and IMHO should) just do those two > checks, run a "diff -u" of the approved spec file against the unapproved > one, take a quick look at the differences and then approved the second > package if everything looks sane. That can likely be done in less then 5 > minutes and is not that much work. But you assume a zero-second lead-time to finding a reviewer at the first place. If there is a new language package in two weeks or two months do you really think that a reviewer will come immediately to the attention of this new package? Also we don't recheck md5sums and license changes on each package update, because we started to trust the maintainer, why should we put up the burden for doing so here, when we are semantically only splitting the srpms? These are the reasons that people prefer to keep stuff like that conglomerated in one big chunk instead of going through loops for every new subpackage. Anyway this was just a suggestion on how to deal with that to make maintainers' life *easy* on our requests to have fine grained srpms w/o compromizing anything (you didn't have license checks and md5sum checks on "growing" srpms before either). The less burocratic/painful you make it the more people will agree to it. BTW this is not an FPC issue to decide anyway, the guidelines would not change, it would be fesco that would consider adding template reviews or not. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From krzyzowiec at yahoo.com Tue Jun 26 14:50:40 2007 From: krzyzowiec at yahoo.com (Adam Ornat) Date: Tue, 26 Jun 2007 07:50:40 -0700 (PDT) Subject: [Fedora-packaging] Fedora Core 6 pkgs in Fedora 7 Message-ID: <982762.71217.qm@web51111.mail.re2.yahoo.com> Hi all, I've upgraded to Fedora 7 from FC6 and noticed that there are still .fc6 packages in my system. Could these packages be removed? Thanks in advance, Art From paul at city-fan.org Tue Jun 26 15:14:27 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 26 Jun 2007 16:14:27 +0100 Subject: [Fedora-packaging] Fedora Core 6 pkgs in Fedora 7 In-Reply-To: <982762.71217.qm@web51111.mail.re2.yahoo.com> References: <982762.71217.qm@web51111.mail.re2.yahoo.com> Message-ID: <46812D53.1090408@city-fan.org> Adam Ornat wrote: > Hi all, I've upgraded to Fedora 7 from FC6 and noticed > that there are still .fc6 packages in my system. Could > these packages be removed? No; this is normal, expected behaviour, and is mentioned in the release notes. http://docs.fedoraproject.org/release-notes/f7/en_US/sn-PackageNotes.html#sn-fc6-tag Paul. From notting at redhat.com Tue Jun 26 15:42:47 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 Jun 2007 11:42:47 -0400 Subject: [Fedora-packaging] one big SRPM for lots of different stardict dictionaries? In-Reply-To: <4680C12C.8020904@leemhuis.info> References: <4680C12C.8020904@leemhuis.info> Message-ID: <20070626154247.GE28752@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > I'd say we should work towards a scheme similar to hunspell; e.g. one > source package per language. Other opinions? I'd work towards only having one set of dictionaries first. Bill From fedora at leemhuis.info Tue Jun 26 16:07:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 26 Jun 2007 18:07:07 +0200 Subject: [Fedora-packaging] one big SRPM for lots of different stardict dictionaries? In-Reply-To: <20070626154247.GE28752@nostromo.devel.redhat.com> References: <4680C12C.8020904@leemhuis.info> <20070626154247.GE28752@nostromo.devel.redhat.com> Message-ID: <468139AB.8060401@leemhuis.info> On 26.06.2007 17:42, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at leemhuis.info) said: >> I'd say we should work towards a scheme similar to hunspell; e.g. one >> source package per language. Other opinions? > I'd work towards only having one set of dictionaries first. Well, sure, that's the real solution (and we could end world hunger while at it as well ;-) ). But likely still years away (hunspell seems to be on the way to at least have one dict for oofice, firefox, thunderbird and hopefully other apps in the end as well; but I use stardic for translating de <-> en -- that's something hunspell does not target afaics) Cu thl From nicolas.mailhot at laposte.net Tue Jun 26 17:36:10 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 26 Jun 2007 19:36:10 +0200 Subject: [Fedora-packaging] one big SRPM for lots of different stardict dictionaries? In-Reply-To: <468139AB.8060401@leemhuis.info> References: <4680C12C.8020904@leemhuis.info> <20070626154247.GE28752@nostromo.devel.redhat.com> <468139AB.8060401@leemhuis.info> Message-ID: <1182879370.14650.20.camel@rousalka.dyndns.org> Le mardi 26 juin 2007 ? 18:07 +0200, Thorsten Leemhuis a ?crit : > > On 26.06.2007 17:42, Bill Nottingham wrote: > > Thorsten Leemhuis (fedora at leemhuis.info) said: > >> I'd say we should work towards a scheme similar to hunspell; e.g. one > >> source package per language. Other opinions? > > I'd work towards only having one set of dictionaries first. > > Well, sure, that's the real solution (and we could end world hunger > while at it as well ;-) ). > > But likely still years away (hunspell seems to be on the way to at least > have one dict for oofice, firefox, thunderbird and hopefully other apps > in the end as well; but I use stardic for translating de <-> en -- > that's something hunspell does not target afaics) We still need to define how we handle specialist hunspell dicts. In most languages you have usual vocabulary and specialist/unusual terms, and stuffing all in the same dicts actually decreases spellchecking efficiency. So you need a core dict and extensions people install only if they use the associated terms. -- 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 rdieter at math.unl.edu Tue Jun 26 20:08:22 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Jun 2007 15:08:22 -0500 Subject: [Fedora-packaging] cmake guideline update proposal Message-ID: <46817236.8030005@math.unl.edu> http://fedoraproject.org/wiki/PackagingDrafts/cmake In short, adding to %cmake: -DINCLUDE_INSTALL_DIR=%{_includedir} \\\ -DLIB_INSTALL_DIR=%{_libdir} \\\ -DSYSCONF_INSTALL_DIR=%{_sysconfdir} \\\ -DSHARE_INSTALL_PREFIX=%{_datadir} Found these additions useful while working on kde4 packaging (SYSCONF_INSTALL_DIR in particular, since kde4's default was/is prefix/etc). -- Rex From tibbs at math.uh.edu Tue Jun 26 20:25:57 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Jun 2007 15:25:57 -0500 Subject: [Fedora-packaging] cmake guideline update proposal In-Reply-To: <46817236.8030005@math.unl.edu> References: <46817236.8030005@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> http://fedoraproject.org/wiki/PackagingDrafts/cmake I'm not even sure this kind of thing needs to go through the packaging committee. For example, I doubt rpm maintainers would consult us if they wanted to change, say, the %configure macro. This seems to me to be something best worked out between the cmake maintainer(s) and packagers who need the %cmake macro. But if you want an ack, +1 assuming that the cmake-using packagers have been consulted. - J< From rdieter at math.unl.edu Tue Jun 26 20:29:43 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Jun 2007 15:29:43 -0500 Subject: [Fedora-packaging] cmake guideline update proposal In-Reply-To: References: <46817236.8030005@math.unl.edu> Message-ID: <46817737.9010202@math.unl.edu> Jason L Tibbitts III wrote: >>>>>> "RD" == Rex Dieter writes: > > RD> http://fedoraproject.org/wiki/PackagingDrafts/cmake > > I'm not even sure this kind of thing needs to go through the packaging > committee. ... > But if you want an ack, +1 assuming that the cmake-using packagers > have been consulted. (most) kde folks + cmake maintainer have been Cc'd (no other feedback yet). -- Rex From Axel.Thimm at ATrpms.net Tue Jun 26 22:49:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Jun 2007 00:49:20 +0200 Subject: [Fedora-packaging] Re: cmake guideline update proposal In-Reply-To: References: <46817236.8030005@math.unl.edu> Message-ID: <20070626224920.GA14728@puariko.nirvana> On Tue, Jun 26, 2007 at 03:25:57PM -0500, Jason L Tibbitts III wrote: > >>>>> "RD" == Rex Dieter writes: > > RD> http://fedoraproject.org/wiki/PackagingDrafts/cmake > > I'm not even sure this kind of thing needs to go through the packaging > committee. For example, I doubt rpm maintainers would consult us if > they wanted to change, say, the %configure macro. This seems to me to > be something best worked out between the cmake maintainer(s) and > packagers who need the %cmake macro. > > But if you want an ack, +1 assuming that the cmake-using packagers > have been consulted. +1 from me, too. Like Jason says it's probably an implementation detail and for example with redhat-rpm-config we've been only given recommendations and have not been feeling authoritatively (maybe it's a grey zone in the FPC's mandate), but if it's considered out business to decide +1 with an FPC hat on, as well. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jun 26 23:08:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Jun 2007 01:08:29 +0200 Subject: [Fedora-packaging] /srv Message-ID: <20070626230829.GB14728@puariko.nirvana> Sorry I couldn't make it today (and FWIW I will be quite short of time until mid September). On the /srv issue: The FHS is deliberately not providing any layout on how to internally structure this, as there are at least two very popular ones (both of them mentioned in the FHS): /srv//[/]... /srv///... As neither fits universally and Fedora is a general purpose distro we should not impose any layout on the users but allow them to freely use any layout they like. There are extended version of this argumentation on this list and f-m-l E.g. no package (other than filesytem) should ever place/own anything under /srv. Packages that need a dummy or default data location should use /var instead. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jun 27 01:38:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Jun 2007 21:38:30 -0400 Subject: [Fedora-packaging] /srv In-Reply-To: <20070626230829.GB14728@puariko.nirvana> References: <20070626230829.GB14728@puariko.nirvana> Message-ID: <200706262138.30300.jkeating@redhat.com> On Tuesday 26 June 2007 19:08:29 Axel Thimm wrote: > Sorry I couldn't make it today (and FWIW I will be quite short of time > until mid September). > > On the /srv issue: The FHS is deliberately not providing any layout on > how to internally structure this, as there are at least two very > popular ones (both of them mentioned in the FHS): > > /srv//[/]... > /srv///... > > As neither fits universally and Fedora is a general purpose distro we > should not impose any layout on the users but allow them to freely use > any layout they like. There are extended version of this argumentation > on this list and f-m-l > > E.g. no package (other than filesytem) should ever place/own anything > under /srv. Packages that need a dummy or default data location should > use /var instead. I'm OK with this, just as long as we /have/ a policy to follow. +1 from me. -- 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 orion at cora.nwra.com Wed Jun 27 16:52:52 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 27 Jun 2007 10:52:52 -0600 Subject: [Fedora-packaging] Re: cmake guideline update proposal In-Reply-To: <46817236.8030005@math.unl.edu> References: <46817236.8030005@math.unl.edu> Message-ID: <468295E4.2000503@cora.nwra.com> Rex Dieter wrote: > http://fedoraproject.org/wiki/PackagingDrafts/cmake > > In short, adding to %cmake: > -DINCLUDE_INSTALL_DIR=%{_includedir} \\\ > -DLIB_INSTALL_DIR=%{_libdir} \\\ > -DSYSCONF_INSTALL_DIR=%{_sysconfdir} \\\ > -DSHARE_INSTALL_PREFIX=%{_datadir} > > Found these additions useful while working on kde4 packaging > (SYSCONF_INSTALL_DIR in particular, since kde4's default was/is > prefix/etc). > > -- Rex Basically looks good to me. Here's what I propose: # # Macros for cmake # %_cmake_lib_suffix64 -DLIB_SUFFIX=64 %__cmake %{_bindir}/cmake %cmake \ CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \ CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \ FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \ %__cmake \\\ -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \\\ -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \\\ -DINCLUDE_INSTALL_DIR:PATH=%{_includedir} \\\ -DLIB_INSTALL_DIR:PATH=%{_libdir} \\\ -DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \\\ -DSHARE_INSTALL_PREFIX:PATH=%{_datadir} \\\ %if "%{?_lib}" == "lib64" \ %{?_cmake_lib_suffix64} \\\ %endif \ -DBUILD_SHARED_LIBS:BOOL=ON I'll put in devel and recompile my cmake projects against it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From ville.skytta at iki.fi Wed Jun 27 17:47:32 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 27 Jun 2007 20:47:32 +0300 Subject: [Fedora-packaging] Re: cmake guideline update proposal In-Reply-To: <468295E4.2000503@cora.nwra.com> References: <46817236.8030005@math.unl.edu> <468295E4.2000503@cora.nwra.com> Message-ID: <200706272047.33081.ville.skytta@iki.fi> On Wednesday 27 June 2007, Orion Poplawski wrote: [...] > %_cmake_lib_suffix64 -DLIB_SUFFIX=64 [...] > -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \\\ [...] > %if "%{?_lib}" == "lib64" \ > %{?_cmake_lib_suffix64} \\\ > %endif \ [...] Are the separate lib64 suffix tricks still needed after the introduction of -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} ? From ville.skytta at iki.fi Wed Jun 27 18:01:59 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 27 Jun 2007 21:01:59 +0300 Subject: [Fedora-packaging] /srv In-Reply-To: <20070626230829.GB14728@puariko.nirvana> References: <20070626230829.GB14728@puariko.nirvana> Message-ID: <200706272101.59750.ville.skytta@iki.fi> On Wednesday 27 June 2007, Axel Thimm wrote: > On the /srv issue: The FHS is deliberately not providing any layout on > how to internally structure this, as there are at least two very > popular ones (both of them mentioned in the FHS): > > /srv//[/]... > /srv///... > > As neither fits universally and Fedora is a general purpose distro we > should not impose any layout on the users but allow them to freely use > any layout they like. There are extended version of this argumentation > on this list and f-m-l But the FHS also says "However /srv should always exist on FHS compliant systems and should be used as the default location for such data.". I don't see how it would be possible to sanely satisfy all the "do not assume any particular layout", "do not remove locally placed files in /srv" and "use /srv as the default location for such data" requirements in packaged software, so maybe that's a case in point for not using /srv at all. But I think asking the FHS people for clarification before setting policies and especially before rushing to make changes to packages that currently use and place files in /srv would be the right thing to do. From rdieter at math.unl.edu Wed Jun 27 18:04:59 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 27 Jun 2007 13:04:59 -0500 Subject: [Fedora-packaging] Re: cmake guideline update proposal In-Reply-To: <200706272047.33081.ville.skytta@iki.fi> References: <46817236.8030005@math.unl.edu> <468295E4.2000503@cora.nwra.com> <200706272047.33081.ville.skytta@iki.fi> Message-ID: <4682A6CB.2040204@math.unl.edu> Ville Skytt? wrote: > On Wednesday 27 June 2007, Orion Poplawski wrote: > > [...] >> %_cmake_lib_suffix64 -DLIB_SUFFIX=64 > [...] >> -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \\\ > [...] >> %if "%{?_lib}" == "lib64" \ >> %{?_cmake_lib_suffix64} \\\ >> %endif \ > [...] > > Are the separate lib64 suffix tricks still needed after the introduction > of -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} ? Not sure 100% (I'd guess no), hence my comment at the bottom of the proposal: Consideration: Now that LIB_INSTALL_DIR is used, the %_cmake_lib_suffix64 hackery (-DLIB_SUFFIX=64) could possibly be omitted. I'm not advocating that, since I see no harm in setting both LIB_INSTALL_DIR and LIB_SUFFIX. From nicolas.mailhot at laposte.net Wed Jun 27 18:08:50 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 27 Jun 2007 20:08:50 +0200 Subject: [Fedora-packaging] /srv In-Reply-To: <200706272101.59750.ville.skytta@iki.fi> References: <20070626230829.GB14728@puariko.nirvana> <200706272101.59750.ville.skytta@iki.fi> Message-ID: <1182967730.19160.5.camel@rousalka.dyndns.org> Le mercredi 27 juin 2007 ? 21:01 +0300, Ville Skytt? a ?crit : > I don't see how it would be possible to sanely satisfy all the "do not assume > any particular layout", "do not remove locally placed files in /srv" > and "use /srv as the default location for such data" requirements in packaged > software, so maybe that's a case in point for not using /srv at all. +1 also layouts that use domains as roots are pretty much ruled out in an rpm context, so that's not as if we have a choice to make -- 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 Jun 27 18:14:19 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 27 Jun 2007 21:14:19 +0300 Subject: [Fedora-packaging] Re: cmake guideline update proposal In-Reply-To: <4682A6CB.2040204@math.unl.edu> References: <46817236.8030005@math.unl.edu> <200706272047.33081.ville.skytta@iki.fi> <4682A6CB.2040204@math.unl.edu> Message-ID: <200706272114.19707.ville.skytta@iki.fi> On Wednesday 27 June 2007, Rex Dieter wrote: > Consideration: Now that LIB_INSTALL_DIR is used, the > %_cmake_lib_suffix64 hackery (-DLIB_SUFFIX=64) could possibly be > omitted. I'm not advocating that, since I see no harm in setting both > LIB_INSTALL_DIR and LIB_SUFFIX. With LIB_INSTALL_DIR=/usr/lib64 and LIB_SUFFIX=64 I could imagine some things ending up in /usr/lib6464. If there's evidence that suggests or "guarantees" this won't happen, I have no problem with it either. From Axel.Thimm at ATrpms.net Wed Jun 27 18:19:31 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Jun 2007 20:19:31 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <1182967730.19160.5.camel@rousalka.dyndns.org> References: <20070626230829.GB14728@puariko.nirvana> <200706272101.59750.ville.skytta@iki.fi> <1182967730.19160.5.camel@rousalka.dyndns.org> Message-ID: <20070627181931.GD15327@puariko.nirvana> On Wed, Jun 27, 2007 at 08:08:50PM +0200, Nicolas Mailhot wrote: > Le mercredi 27 juin 2007 ? 21:01 +0300, Ville Skytt? a ?crit : > > > I don't see how it would be possible to sanely satisfy all the "do not assume > > any particular layout", "do not remove locally placed files in /srv" > > and "use /srv as the default location for such data" requirements in packaged > > software, so maybe that's a case in point for not using /srv at all. Yes, only "filesystem" should mention /srv, e.g. create it. > +1 > > also layouts that use domains as roots are pretty much ruled out in an > rpm context, so that's not as if we have a choice to make Yes, but that means more that the rpm setup within /srv is ruled out, the way you write it may be read as "rpm doesn't support domain hierarchies, so Fedora setups should not use them" ;) /srv was really left alone for several Fedora Core releases (only bittorrent would install there), we should return to that setup (and also move bittorrent away). $ ls /srv alsa-project.org atrpms.net bittorrent ivtvdriver.org lm-sensors.org medley mythdora video4linux.org -- 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 Jun 27 18:21:10 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 27 Jun 2007 13:21:10 -0500 Subject: [Fedora-packaging] Re: cmake guideline update proposal In-Reply-To: <200706272114.19707.ville.skytta@iki.fi> References: <46817236.8030005@math.unl.edu> <200706272047.33081.ville.skytta@iki.fi> <4682A6CB.2040204@math.unl.edu> <200706272114.19707.ville.skytta@iki.fi> Message-ID: <4682AA96.5090703@math.unl.edu> Ville Skytt? wrote: > On Wednesday 27 June 2007, Rex Dieter wrote: > >> Consideration: Now that LIB_INSTALL_DIR is used, the >> %_cmake_lib_suffix64 hackery (-DLIB_SUFFIX=64) could possibly be >> omitted. I'm not advocating that, since I see no harm in setting both >> LIB_INSTALL_DIR and LIB_SUFFIX. > > With LIB_INSTALL_DIR=/usr/lib64 and LIB_SUFFIX=64 I could imagine some things > ending up in /usr/lib6464. Not in my kde4 packaging work so far... :) > If there's evidence that suggests or "guarantees" > this won't happen, I have no problem with it either. We can always change/fix it later, if problematic cases present themselves. -- Rex From nicolas.mailhot at laposte.net Wed Jun 27 18:41:43 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 27 Jun 2007 20:41:43 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <20070627181931.GD15327@puariko.nirvana> References: <20070626230829.GB14728@puariko.nirvana> <200706272101.59750.ville.skytta@iki.fi> <1182967730.19160.5.camel@rousalka.dyndns.org> <20070627181931.GD15327@puariko.nirvana> Message-ID: <1182969703.19160.18.camel@rousalka.dyndns.org> Le mercredi 27 juin 2007 ? 20:19 +0200, Axel Thimm a ?crit : > On Wed, Jun 27, 2007 at 08:08:50PM +0200, Nicolas Mailhot wrote: > > also layouts that use domains as roots are pretty much ruled out in an > > rpm context, so that's not as if we have a choice to make > > Yes, but that means more that the rpm setup within /srv is ruled out, > the way you write it may be read as "rpm doesn't support domain > hierarchies, so Fedora setups should not use them" ;) That is exactly what I meant. Using the filesystem namespace to express domain separations is broken by design in any autodeploy/autoupdate context. That people can get by in a manual deployment context does not make it any less broken (there's a lot of stuff which is cheap with a human operator and insane with an automaton) The *only* sane policy in an automated context is domain-agnostic file locations + domain policy in conf files (which allows transparent domain aliasing BTW). I've spent time enough as a webapp ISV engineer trying to workaround the tomcat?3 stupid policy of forcing a domain file layout on everyone to have a clear opinion on the subject. You have file resources, and you have local network policies (which may even be dynamic with dhcp avahi & friends). They never map 1:1. Forcing file layout to reflect domain layout is an exercise in futility. -- 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 Jun 27 18:41:36 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 27 Jun 2007 21:41:36 +0300 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <20070627181931.GD15327@puariko.nirvana> References: <20070626230829.GB14728@puariko.nirvana> <1182967730.19160.5.camel@rousalka.dyndns.org> <20070627181931.GD15327@puariko.nirvana> Message-ID: <200706272141.36403.ville.skytta@iki.fi> On Wednesday 27 June 2007, Axel Thimm wrote: > /srv was really left alone for several Fedora Core releases (only > bittorrent would install there), we should return to that setup (and > also move bittorrent away). Moving is tricky for many packages as there can be *lots* of content installed in the currently used dirs. It may and will in many cases require reorganizing partitions and/or disks. From Axel.Thimm at ATrpms.net Wed Jun 27 18:52:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Jun 2007 20:52:01 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <1182969703.19160.18.camel@rousalka.dyndns.org> References: <20070626230829.GB14728@puariko.nirvana> <200706272101.59750.ville.skytta@iki.fi> <1182967730.19160.5.camel@rousalka.dyndns.org> <20070627181931.GD15327@puariko.nirvana> <1182969703.19160.18.camel@rousalka.dyndns.org> Message-ID: <20070627185201.GG15327@puariko.nirvana> On Wed, Jun 27, 2007 at 08:41:43PM +0200, Nicolas Mailhot wrote: > Le mercredi 27 juin 2007 ? 20:19 +0200, Axel Thimm a ?crit : > > On Wed, Jun 27, 2007 at 08:08:50PM +0200, Nicolas Mailhot wrote: > > > > also layouts that use domains as roots are pretty much ruled out in an > > > rpm context, so that's not as if we have a choice to make > > > > Yes, but that means more that the rpm setup within /srv is ruled out, > > the way you write it may be read as "rpm doesn't support domain > > hierarchies, so Fedora setups should not use them" ;) > > That is exactly what I meant. Well, see below. > Using the filesystem namespace to express domain separations is broken > by design in any autodeploy/autoupdate context. That people can get by > in a manual deployment context does not make it any less broken (there's > a lot of stuff which is cheap with a human operator and insane with an > automaton) > > The *only* sane policy in an automated context is domain-agnostic file > locations + domain policy in conf files (which allows transparent domain > aliasing BTW). I've spent time enough as a webapp ISV engineer trying to > workaround the tomcat?3 stupid policy of forcing a domain file layout on > everyone to have a clear opinion on the subject. > > You have file resources, and you have local network policies (which may > even be dynamic with dhcp avahi & friends). They never map 1:1. Forcing > file layout to reflect domain layout is an exercise in futility. I agree, which is why you can't this all happen under /srv. rpm can either not have /srv at all, or enforce only one of three popular models pissing off two thirds of the users. But we want all users to continue to use Fedora/RHEL, so we let /srv to the users' mercy only, and keep our packages away from 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 Axel.Thimm at ATrpms.net Wed Jun 27 19:01:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Jun 2007 21:01:14 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <200706272141.36403.ville.skytta@iki.fi> References: <20070626230829.GB14728@puariko.nirvana> <1182967730.19160.5.camel@rousalka.dyndns.org> <20070627181931.GD15327@puariko.nirvana> <200706272141.36403.ville.skytta@iki.fi> Message-ID: <20070627190114.GH15327@puariko.nirvana> On Wed, Jun 27, 2007 at 09:41:36PM +0300, Ville Skytt? wrote: > On Wednesday 27 June 2007, Axel Thimm wrote: > > > /srv was really left alone for several Fedora Core releases (only > > bittorrent would install there), we should return to that setup (and > > also move bittorrent away). > > Moving is tricky for many packages as there can be *lots* of content installed > in the currently used dirs. It may and will in many cases require > reorganizing partitions and/or disks. True, I don't know how bittorrent's upgrading currently works, but with moving I ment new package installs. As long as there is only bittorrent and maybe a couple more packages polluting /srv we can have package-local workarounds phasing the direct usage under /srv out. For bittorrent this means that on new installs it picks the non-srv location and on upgrades it copies over the bittorent data location from the previous setup (probably needs to happen in %pre before the config files are overwritten). Or maybe bittorrent needs another approach, just giving the idea. -- 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 Wed Jun 27 19:06:07 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 27 Jun 2007 21:06:07 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <20070627185201.GG15327@puariko.nirvana> References: <20070626230829.GB14728@puariko.nirvana> <200706272101.59750.ville.skytta@iki.fi> <1182967730.19160.5.camel@rousalka.dyndns.org> <20070627181931.GD15327@puariko.nirvana> <1182969703.19160.18.camel@rousalka.dyndns.org> <20070627185201.GG15327@puariko.nirvana> Message-ID: <1182971167.3432.8.camel@rousalka.dyndns.org> Le mercredi 27 juin 2007 ? 20:52 +0200, Axel Thimm a ?crit : > On Wed, Jun 27, 2007 at 08:41:43PM +0200, Nicolas Mailhot wrote: > > You have file resources, and you have local network policies (which may > > even be dynamic with dhcp avahi & friends). They never map 1:1. Forcing > > file layout to reflect domain layout is an exercise in futility. > > I agree, which is why you can't this all happen under /srv. No. That means you partition /srv in an rpm-controlled part, and a free-for-all part. This way you can have sane pre-configured defaults, and people can do something else if they really want to. The current habit of shunning /srv at all costs results in: ? defaults not being pre-configured & installed because the sane place to put them is blacklisted ? or defaults that can not serve as examples (because their layout has no relation with the /srv/ users are supposed to use), confuse scripts (again because of the layout mismatch), confuse security policies, etc You can have a /srv/default and a /srv/local, or a /srv and /local/srv, or whatever but two totally different policies is just shooting ourselves in the foot. -- 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 nicolas.mailhot at laposte.net Wed Jun 27 19:09:38 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 27 Jun 2007 21:09:38 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <200706272141.36403.ville.skytta@iki.fi> References: <20070626230829.GB14728@puariko.nirvana> <1182967730.19160.5.camel@rousalka.dyndns.org> <20070627181931.GD15327@puariko.nirvana> <200706272141.36403.ville.skytta@iki.fi> Message-ID: <1182971378.3432.13.camel@rousalka.dyndns.org> Le mercredi 27 juin 2007 ? 21:41 +0300, Ville Skytt? a ?crit : > On Wednesday 27 June 2007, Axel Thimm wrote: > > > /srv was really left alone for several Fedora Core releases (only > > bittorrent would install there), we should return to that setup (and > > also move bittorrent away). > > Moving is tricky for many packages as there can be *lots* of content installed > in the currently used dirs. It may and will in many cases require > reorganizing partitions and/or disks. That's a bad argument. You could use it to block any distro change, and waiting longer only means more systems installed with a known-bad policy. When a better policy is agreed on there is no win in delaying implementation. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Wed Jun 27 19:23:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Jun 2007 21:23:27 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <1182971167.3432.8.camel@rousalka.dyndns.org> References: <20070626230829.GB14728@puariko.nirvana> <200706272101.59750.ville.skytta@iki.fi> <1182967730.19160.5.camel@rousalka.dyndns.org> <20070627181931.GD15327@puariko.nirvana> <1182969703.19160.18.camel@rousalka.dyndns.org> <20070627185201.GG15327@puariko.nirvana> <1182971167.3432.8.camel@rousalka.dyndns.org> Message-ID: <20070627192327.GI15327@puariko.nirvana> On Wed, Jun 27, 2007 at 09:06:07PM +0200, Nicolas Mailhot wrote: > Le mercredi 27 juin 2007 ? 20:52 +0200, Axel Thimm a ?crit : > > On Wed, Jun 27, 2007 at 08:41:43PM +0200, Nicolas Mailhot wrote: > > > > You have file resources, and you have local network policies (which may > > > even be dynamic with dhcp avahi & friends). They never map 1:1. Forcing > > > file layout to reflect domain layout is an exercise in futility. > > > > I agree, which is why you can't this all happen under /srv. > > No. That means you partition /srv in an rpm-controlled part, and a > free-for-all part. This way you can have sane pre-configured defaults, > and people can do something else if they really want to. > > The current habit of shunning /srv at all costs results in: > ? defaults not being pre-configured & installed because the sane place > to put them is blacklisted Not really, the reason for not having defaults is that by definition the contents cannot be provided and cannot be open by default. We're talking about daemons accessing local data. :) > ? or defaults that can not serve as examples (because their layout > has no relation with the /srv/ users are supposed to use), Yes, but which one of the three popular /srv layouts are users supposed to use? > confuse scripts (again because of the layout mismatch), confuse > security policies, etc If you don't know what data will be under /srv and how the sysadmin will be managing it you can' provide anything of this kind. And you can't enforce a model that works for half the users and not for the other half. > You can have a /srv/default and a /srv/local, or a /srv and > /local/srv, or whatever but two totally different policies is just > shooting ourselves in the foot. /srv is already in various FHS-compliant use on thousands of sites. You can't touch it really. And if you were to create a /vendor-default-and-examples/srv then you can use /var/lib/foo as well. In fact many "data carrying" applications like name servers, MTAs etc. use /var in the FHS, although technically they would have to move that content to /srv, by /srv's definition. And in fact? in a multi-domain setup one is often forced to do so to separate instances. This is also important in a cluster/gfs setup, where member A could be serving domain X and Y, or only one, or none. So the daemons need to have separate fs paths. On the other hand a multi-homed system may want to keep it all virtualized instead of clustered, so with the choice comes the need for different layouts and we can't dictate any. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jun 27 19:39:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 15:39:51 -0400 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <20070627192327.GI15327@puariko.nirvana> References: <20070626230829.GB14728@puariko.nirvana> <1182971167.3432.8.camel@rousalka.dyndns.org> <20070627192327.GI15327@puariko.nirvana> Message-ID: <200706271539.51590.jkeating@redhat.com> On Wednesday 27 June 2007 15:23:27 Axel Thimm wrote: > /srv is already in various FHS-compliant use on thousands of > sites. You can't touch it really. And if you were to create a > /vendor-default-and-examples/srv then you can use /var/lib/foo as > well. > > In fact many "data carrying" applications like name servers, MTAs > etc. use /var in the FHS, although technically they would have to move > that content to /srv, by /srv's definition. I think the key thing here is that the FHS seems contradictory with regard to /srv and we really would like some clarification so that we can create appropriate packaging guidelines. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Jun 27 19:48:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 27 Jun 2007 21:48:32 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <20070627192327.GI15327@puariko.nirvana> References: <20070626230829.GB14728@puariko.nirvana> <200706272101.59750.ville.skytta@iki.fi> <1182967730.19160.5.camel@rousalka.dyndns.org> <20070627181931.GD15327@puariko.nirvana> <1182969703.19160.18.camel@rousalka.dyndns.org> <20070627185201.GG15327@puariko.nirvana> <1182971167.3432.8.camel@rousalka.dyndns.org> <20070627192327.GI15327@puariko.nirvana> Message-ID: <1182973712.4097.10.camel@rousalka.dyndns.org> Le mercredi 27 juin 2007 ? 21:23 +0200, Axel Thimm a ?crit : > On Wed, Jun 27, 2007 at 09:06:07PM +0200, Nicolas Mailhot wrote: > > Le mercredi 27 juin 2007 ? 20:52 +0200, Axel Thimm a ?crit : > > > On Wed, Jun 27, 2007 at 08:41:43PM +0200, Nicolas Mailhot wrote: > > > > > > You have file resources, and you have local network policies (which may > > > > even be dynamic with dhcp avahi & friends). They never map 1:1. Forcing > > > > file layout to reflect domain layout is an exercise in futility. > > > > > > I agree, which is why you can't this all happen under /srv. > > > > No. That means you partition /srv in an rpm-controlled part, and a > > free-for-all part. This way you can have sane pre-configured defaults, > > and people can do something else if they really want to. > > > > The current habit of shunning /srv at all costs results in: > > ? defaults not being pre-configured & installed because the sane place > > to put them is blacklisted > > Not really, the reason for not having defaults is that by definition > the contents cannot be provided and cannot be open by default. We're > talking about daemons accessing local data. :) Bad excuse, we ship a lot of services default-disabled, we could ship default-disabled srv layouts > > ? or defaults that can not serve as examples (because their layout > > has no relation with the /srv/ users are supposed to use), > Yes, but which one of the three popular /srv layouts are users > supposed to use? We can provide examples and templates. Users that know better will do what they want as usual. No best policy is no excuse for no policy. Half our stuff in /etc could be configured some other just as good way we still make a choice. A distro rpm layout is a layout that just works with distro defaults, which is already quite a high standard. > > confuse scripts (again because of the layout mismatch), confuse > > security policies, etc > > If you don't know what data will be under /srv and how the sysadmin > will be managing it you can' provide anything of this kind. You can provide a default webdav/ftp/samba layout, we've done so in conf files for years. > And you > can't enforce a model that works for half the users and not for the > other half. Again you're making it a special case when the same arguments could be used to advocate no choices in most of the filesystem. We're not gentoo we make choices for users and then let them amend our choices. > > You can have a /srv/default and a /srv/local, or a /srv and > > /local/srv, or whatever but two totally different policies is just > > shooting ourselves in the foot. > > /srv is already in various FHS-compliant use on thousands of > sites. You can't touch it really. And if you were to create a > /vendor-default-and-examples/srv then you can use /var/lib/foo as > well. No, /var/lib/foo is mixing local apps and content, that's the kind of mixup that got stuff kicked from /home in the first place. > > In fact many "data carrying" applications like name servers, MTAs > etc. use /var in the FHS, although technically they would have to move > that content to /srv, by /srv's definition. They should. They will someday. Or something else will deprecate /srv. > And in fact? in a > multi-domain setup one is often forced to do so to separate > instances. That only means you have several resources, and you can map them to several domains, not that the resources names should be domain names. -- 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 Jun 27 20:00:35 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 27 Jun 2007 23:00:35 +0300 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <1182971378.3432.13.camel@rousalka.dyndns.org> References: <20070626230829.GB14728@puariko.nirvana> <200706272141.36403.ville.skytta@iki.fi> <1182971378.3432.13.camel@rousalka.dyndns.org> Message-ID: <200706272300.35549.ville.skytta@iki.fi> On Wednesday 27 June 2007, Nicolas Mailhot wrote: > Le mercredi 27 juin 2007 ? 21:41 +0300, Ville Skytt? a ?crit : > > On Wednesday 27 June 2007, Axel Thimm wrote: > > > /srv was really left alone for several Fedora Core releases (only > > > bittorrent would install there), we should return to that setup (and > > > also move bittorrent away). > > > > Moving is tricky for many packages as there can be *lots* of content > > installed in the currently used dirs. It may and will in many cases > > require reorganizing partitions and/or disks. > > That's a bad argument. You could use it to block any distro change, Aww, please. > and > waiting longer only means more systems installed with a known-bad > policy. When a better policy is agreed on there is no win in delaying > implementation. Even if the "better policy" is essentially just a new interpretation of a (still) ambiguous, kind of self conflicting standard, and would in some cases mean knowingly breaking existing perfectly well working setups on upgrades? I don't think I can agree with that. What I can agree with is applying the new interpretation to newly introduced packages, and after the ambiguity in the specification has dissolved and the new interpretation been in practice for quite a while without no pressure to change it again in sight, only then inflicting the breakage, loud and clear, unless no other migration path is found. From Axel.Thimm at ATrpms.net Thu Jun 28 00:52:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 28 Jun 2007 02:52:41 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <1182973712.4097.10.camel@rousalka.dyndns.org> References: <20070626230829.GB14728@puariko.nirvana> <200706272101.59750.ville.skytta@iki.fi> <1182967730.19160.5.camel@rousalka.dyndns.org> <20070627181931.GD15327@puariko.nirvana> <1182969703.19160.18.camel@rousalka.dyndns.org> <20070627185201.GG15327@puariko.nirvana> <1182971167.3432.8.camel@rousalka.dyndns.org> <20070627192327.GI15327@puariko.nirvana> <1182973712.4097.10.camel@rousalka.dyndns.org> Message-ID: <20070628005241.GM15327@puariko.nirvana> On Wed, Jun 27, 2007 at 09:48:32PM +0200, Nicolas Mailhot wrote: > Bad excuse, we ship a lot of services default-disabled, we could ship > default-disabled srv layouts Yes, but nuking an rpm captured rpm layout means breaking rpm. > We can provide examples and templates. Users that know better will do > what they want as usual. No best policy is no excuse for no policy. $ ls /srv ftp httpd foo bar $ rm -fr /srv/* $ for domain in $domains; do mkdir -p /srv/$domain/{ftp,httpd,foo,bar}; done $ rpm -V vsftp httpd foo bar missing /srv/ftp ... missing /srv/httpd ... ... No, not really. > A distro rpm layout is a layout that just works with distro defaults, > which is already quite a high standard. There is no single standard, and there is good reason for that. > > If you don't know what data will be under /srv and how the sysadmin > > will be managing it you can' provide anything of this kind. > > You can provide a default webdav/ftp/samba layout, we've done so in conf > files for years. See, above, we don't have an rpm attribute that says "possibly ignore the following layout" liiiike we have with %config. > > And you can't enforce a model that works for half the users and > > not for the other half. > > Again you're making it a special case when the same arguments could be > used to advocate no choices in most of the filesystem. No, this comparision is not fair. Or give an example. The popular modeeeels in /srv usage are really relevant and break each other. > We're not gentoo we make choices for users and then let them amend > our choices. Ouch. No, we're a general purpose distro with different users, we will neither send the home user, not the professional syadmin home. > > > You can have a /srv/default and a /srv/local, or a /srv and > > > /local/srv, or whatever but two totally different policies is just > > > shooting ourselves in the foot. > > > > /srv is already in various FHS-compliant use on thousands of > > sites. You can't touch it really. And if you were to create a > > /vendor-default-and-examples/srv then you can use /var/lib/foo as > > well. > > No, /var/lib/foo is mixing local apps and content, that's the kind of > mixup that got stuff kicked from /home in the first place. This hierarchy holds state information pertaining to an application or the system. > > In fact many "data carrying" applications like name servers, MTAs > > etc. use /var in the FHS, although technically they would have to move > > that content to /srv, by /srv's definition. > > They should. They will someday. Or something else will deprecate /srv. They can't. Because there are choices that you can deprive the users from. > > And in fact? in a multi-domain setup one is often forced to do so > > to separate instances. > > That only means you have several resources, and you can map them to > several domains, not that the resources names should be domain names. No, I wrote instances vs virtual setups (although the latter got trimmed). -- 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 Jun 28 01:02:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 28 Jun 2007 03:02:43 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <200706271539.51590.jkeating@redhat.com> References: <20070626230829.GB14728@puariko.nirvana> <1182971167.3432.8.camel@rousalka.dyndns.org> <20070627192327.GI15327@puariko.nirvana> <200706271539.51590.jkeating@redhat.com> Message-ID: <20070628010243.GN15327@puariko.nirvana> On Wed, Jun 27, 2007 at 03:39:51PM -0400, Jesse Keating wrote: > On Wednesday 27 June 2007 15:23:27 Axel Thimm wrote: > > /srv is already in various FHS-compliant use on thousands of > > sites. You can't touch it really. And if you were to create a > > /vendor-default-and-examples/srv then you can use /var/lib/foo as > > well. > > > > In fact many "data carrying" applications like name servers, MTAs > > etc. use /var in the FHS, although technically they would have to move > > that content to /srv, by /srv's definition. > > I think the key thing here is that the FHS seems contradictory with regard > to /srv and we really would like some clarification so that we can create > appropriate packaging guidelines. The FHS is knowingly partial "contradictory" in some places, because the FHS' self-assigned task is not to design a hierarchy on the blackboard, but to capture best practices. The (old) discussion about bin64 or arch'd bindirs in general for example shows that while the FHS has been favourable towards this, they decided to not introduce it until a distribution shows actual interest in implementing it. People are concentrating their system's data under /srv mainly for mount and backup strategies, not because /var/lib wouldn't fit. The simple singleton non-virtualized applications can live very nicely under /var as they have actually been doing for a couple of decades. It's the more complex setups that make /srv attractive, and populating /srv with a fixed layout will make Fedora too inflexible for exactly the traget group that would benefit the most. So actually introducing a fixed layout into /srv party discards its existence. Consider /srv more similar to /usr/local and /home instead of any other vendor controlled filesystem path. -- 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 Jun 28 06:18:09 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 28 Jun 2007 08:18:09 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <20070628010243.GN15327@puariko.nirvana> References: <20070626230829.GB14728@puariko.nirvana> <1182971167.3432.8.camel@rousalka.dyndns.org> <20070627192327.GI15327@puariko.nirvana> <200706271539.51590.jkeating@redhat.com> <20070628010243.GN15327@puariko.nirvana> Message-ID: <1183011489.10377.14.camel@rousalka.dyndns.org> Le jeudi 28 juin 2007 ? 03:02 +0200, Axel Thimm a ?crit : > People are concentrating their system's data under /srv mainly for > mount and backup strategies, not because /var/lib wouldn't fit. Right. And the policy you're advocating is backup this bit if the admin used the default conf, and backup another one if he changed it. That's plain insane. You have /home user data /var/lib system apps data /srv data served by the system to other systems simple clean easy to understand > So actually introducing a fixed layout into /srv party discards its > existence. Please read the start of the thread again. I never advocated locking out /srv in a fixed layout. I advocated making a fixed layout in /srv for our needs, in a specific part of /srv, letting admins do whatever they want this the rest of /srv. I don't care if you want to organise stuff in /srv by domain zodiacal sign or dog name. I want the same ability I have on the rest of the filesystem, preconfigure stuff for users that do not have advanced needs. The binary you vs me is stupid there's zip reason we can not both create structures in /srv as long as there is a clear partitioning convention so we do not step on each other foot. -- 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 Thu Jun 28 09:39:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 28 Jun 2007 11:39:02 +0200 Subject: [Fedora-packaging] Re: /srv In-Reply-To: <1183011489.10377.14.camel@rousalka.dyndns.org> References: <20070626230829.GB14728@puariko.nirvana> <1182971167.3432.8.camel@rousalka.dyndns.org> <20070627192327.GI15327@puariko.nirvana> <200706271539.51590.jkeating@redhat.com> <20070628010243.GN15327@puariko.nirvana> <1183011489.10377.14.camel@rousalka.dyndns.org> Message-ID: <20070628093902.GA19040@puariko.nirvana> On Thu, Jun 28, 2007 at 08:18:09AM +0200, Nicolas Mailhot wrote: > Le jeudi 28 juin 2007 ? 03:02 +0200, Axel Thimm a ?crit : > > So actually introducing a fixed layout into /srv party discards its > > existence. > > Please read the start of the thread aga I wrote the start of the thread ... > I never advocated locking out /srv in a fixed layout. You did by advocating to hardcode it into the packages. > I advocated making a fixed layout in /srv for our needs, "Our" needs? How do you define "our"? With my Fedora hat on I say that "our" needs are to fulfill our various certainly non-marginal different user groups from small home setups to large systems. This is only accomplished by not applying any "Fedora layout" that is only chosen because "that's what rpm can do". That's a very poor design criterion for a layout-free entity. > in a specific part of /srv, letting admins do whatever they want > this the rest of /srv. /srv/I_hope_noone_has_been_using_this_folder_where_I_put_all_defaults_in > I don't care if you want to organise stuff in /srv by domain zodiacal > sign or dog name. I want the same ability I have on the rest of the > filesystem, preconfigure stuff for users that do not have advanced > needs. /var > The binary you vs me is stupid there's zip reason we can not both > create structures in /srv as long as there is a clear partitioning > convention so we do not step on each other foot. And the clear convention to step not on each other's feet is to not use any default layout, neither by zodiac, nor your dog's names. OK, to put this to an end (because we don't produce any new arguments), we agree that we disagree, and the FPC makes its vote once its members feel confident that they have the whole picture.. -- 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 Jun 29 01:28:39 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 28 Jun 2007 18:28:39 -0700 Subject: [Fedora-packaging] %{_datadir}/gtk-doc/ %doc? Message-ID: <1183080519.21296.21.camel@localhost.localdomain> Should files under %{_datadir}/gtk-doc/html be marked as %doc? They are API docs for libraries which are extracted using the gtk-doc toolset and viewable in devhelp. I've never seen a set of files that was necessary for the runtime operation of a library (and doubt that I will... they're API docs and usually included in a -devel subpackage.) On my current system I haven't found any files in %{_datadir}/gtk-doc/html that are marked as %doc. -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 Fri Jun 29 01:47:11 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 28 Jun 2007 20:47:11 -0500 Subject: [Fedora-packaging] %{_datadir}/gtk-doc/ %doc? In-Reply-To: <1183080519.21296.21.camel@localhost.localdomain> References: <1183080519.21296.21.camel@localhost.localdomain> Message-ID: <4684649F.9000105@math.unl.edu> Toshio Kuratomi wrote: > Should files under %{_datadir}/gtk-doc/html be marked as %doc? They are > API docs for libraries which are extracted using the gtk-doc toolset and > viewable in devhelp. I've never seen a set of files that was necessary > for the runtime operation of a library (and doubt that I will... they're > API docs and usually included in a -devel subpackage.) On my current > system I haven't found any files in %{_datadir}/gtk-doc/html that are > marked as %doc. > %doc +1 -- Rex From tmz at pobox.com Fri Jun 29 01:52:31 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 28 Jun 2007 21:52:31 -0400 Subject: [Fedora-packaging] %{_datadir}/gtk-doc/ %doc? In-Reply-To: <1183080519.21296.21.camel@localhost.localdomain> References: <1183080519.21296.21.camel@localhost.localdomain> Message-ID: <20070629015231.GB3127@psilocybe.teonanacatl.org> Toshio Kuratomi wrote: > Should files under %{_datadir}/gtk-doc/html be marked as %doc? They > are API docs for libraries which are extracted using the gtk-doc > toolset and viewable in devhelp. I've never seen a set of files > that was necessary for the runtime operation of a library (and doubt > that I will... they're API docs and usually included in a -devel > subpackage.) On my current system I haven't found any files in > %{_datadir}/gtk-doc/html that are marked as %doc. I think they should be marked %doc. (I added that to my working spec for libgpod some time ago. I was planning to put that into libgpod if/when I get to update the package.) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Money frees you from doing things you dislike. Since I dislike doing nearly everything, money is handy. -- Groucho Marx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From katzj at redhat.com Fri Jun 29 02:08:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 28 Jun 2007 22:08:04 -0400 Subject: [Fedora-packaging] %{_datadir}/gtk-doc/ %doc? In-Reply-To: <1183080519.21296.21.camel@localhost.localdomain> References: <1183080519.21296.21.camel@localhost.localdomain> Message-ID: <1183082884.3794.14.camel@aglarond.local> On Thu, 2007-06-28 at 18:28 -0700, Toshio Kuratomi wrote: > Should files under %{_datadir}/gtk-doc/html be marked as %doc? They are > API docs for libraries which are extracted using the gtk-doc toolset and > viewable in devhelp. I've never seen a set of files that was necessary > for the runtime operation of a library (and doubt that I will... they're > API docs and usually included in a -devel subpackage.) On my current > system I haven't found any files in %{_datadir}/gtk-doc/html that are > marked as %doc. They should be considered %doc, yes. But the right way to do so is to get it added to the list of docDirs within rpm. Attached patch should do it. Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: rpm-gtkdoc-docdir.patch Type: text/x-patch Size: 667 bytes Desc: not available URL: From a.badger at gmail.com Fri Jun 29 02:17:50 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 28 Jun 2007 19:17:50 -0700 Subject: [Fedora-packaging] %{_datadir}/gtk-doc/ %doc? In-Reply-To: <1183082884.3794.14.camel@aglarond.local> References: <1183080519.21296.21.camel@localhost.localdomain> <1183082884.3794.14.camel@aglarond.local> Message-ID: <1183083470.21296.22.camel@localhost.localdomain> On Thu, 2007-06-28 at 22:08 -0400, Jeremy Katz wrote: > On Thu, 2007-06-28 at 18:28 -0700, Toshio Kuratomi wrote: > > Should files under %{_datadir}/gtk-doc/html be marked as %doc? They are > > API docs for libraries which are extracted using the gtk-doc toolset and > > viewable in devhelp. I've never seen a set of files that was necessary > > for the runtime operation of a library (and doubt that I will... they're > > API docs and usually included in a -devel subpackage.) On my current > > system I haven't found any files in %{_datadir}/gtk-doc/html that are > > marked as %doc. > > They should be considered %doc, yes. But the right way to do so is to > get it added to the list of docDirs within rpm. Attached patch should > do it. > Great! Are you sending this on or should I open a bug against rpm? -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 katzj at redhat.com Fri Jun 29 02:31:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 28 Jun 2007 22:31:04 -0400 Subject: [Fedora-packaging] %{_datadir}/gtk-doc/ %doc? In-Reply-To: <1183083470.21296.22.camel@localhost.localdomain> References: <1183080519.21296.21.camel@localhost.localdomain> <1183082884.3794.14.camel@aglarond.local> <1183083470.21296.22.camel@localhost.localdomain> Message-ID: <1183084264.3794.20.camel@aglarond.local> On Thu, 2007-06-28 at 19:17 -0700, Toshio Kuratomi wrote: > On Thu, 2007-06-28 at 22:08 -0400, Jeremy Katz wrote: > > On Thu, 2007-06-28 at 18:28 -0700, Toshio Kuratomi wrote: > > > Should files under %{_datadir}/gtk-doc/html be marked as %doc? They are > > > API docs for libraries which are extracted using the gtk-doc toolset and > > > viewable in devhelp. I've never seen a set of files that was necessary > > > for the runtime operation of a library (and doubt that I will... they're > > > API docs and usually included in a -devel subpackage.) On my current > > > system I haven't found any files in %{_datadir}/gtk-doc/html that are > > > marked as %doc. > > > > They should be considered %doc, yes. But the right way to do so is to > > get it added to the list of docDirs within rpm. Attached patch should > > do it. > > > Great! Are you sending this on or should I open a bug against rpm? That mail was cc'd to rpm-maint. So I'll get it pushed through Jeremy From pnasrat at redhat.com Fri Jun 29 08:51:41 2007 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 29 Jun 2007 09:51:41 +0100 Subject: [Rpm-maint] Re: [Fedora-packaging] %{_datadir}/gtk-doc/ %doc? In-Reply-To: <1183082884.3794.14.camel@aglarond.local> References: <1183080519.21296.21.camel@localhost.localdomain> <1183082884.3794.14.camel@aglarond.local> Message-ID: <1183107102.12634.13.camel@enki.eridu> On Thu, 2007-06-28 at 22:08 -0400, Jeremy Katz wrote: > On Thu, 2007-06-28 at 18:28 -0700, Toshio Kuratomi wrote: > > Should files under %{_datadir}/gtk-doc/html be marked as %doc? They are > > API docs for libraries which are extracted using the gtk-doc toolset and > > viewable in devhelp. I've never seen a set of files that was necessary > > for the runtime operation of a library (and doubt that I will... they're > > API docs and usually included in a -devel subpackage.) On my current > > system I haven't found any files in %{_datadir}/gtk-doc/html that are > > marked as %doc. > > They should be considered %doc, yes. But the right way to do so is to > get it added to the list of docDirs within rpm. Attached patch should > do it. To be honest rather than a hard coded list in files.c we probably want a configurable list of dirs as a macro so policy can be site/distro/os specific. Paul From a.badger at gmail.com Fri Jun 29 18:51:32 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 29 Jun 2007 11:51:32 -0700 Subject: [Fedora-packaging] Multiple version naming overly restrictive? Message-ID: <1183143092.21296.71.camel@localhost.localdomain> Hey all, I just noticed this section of the packaging Guidelines: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#MultiplePackages says: ''' For many reasons, it is sometimes advantageous to keep multiple versions of a package in Fedora to be installed simultaneously. When doing so, the package name should reflect this fact. The most recent version of a package should use the base name with no versions, and all other addons should note their version in the name. ''' I think specifying that the latest package version has [basename] and the others have [basename][version] may be overly restrictive. We have precedent in gtk+ vs gtk2 (long term), gcc (3.x) vs gcc4 (short term), gtkhtml vs gtkhtml2 vs gtkhtml3 (long term) for doing things the other way. Do we really want to restrict this? If not, we could amend the text like this: ''' One package should use the base name with no versions and all other addons should note their version in the name. ''' -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: