From jonathan at jonmasters.org Sat Jun 3 00:47:01 2006 From: jonathan at jonmasters.org (Jon Masters) Date: Sat, 3 Jun 2006 01:47:01 +0100 Subject: [Fedora-packaging] kernel module packaging Message-ID: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> Hi folks, I'm working on some to-be-proposed updates to the kernel module packaging in Fedora Extras to allow us to track changes to the kernel ABI rather than purely the kernel release/version. This should make life easier and help to reduce the number of times that a minor kernel update (e.g. security fixes, etc.) forces all external drivers to be rebuilt. At http://www.kerneldrivers.org/ I have some sample packages that I'm working on, as well as a description of the process and how this relates to other Linux distributions, such as SuSE. I'm going to continue working on this, keep the wiki updated, and ultimately ask FESCo pretty soon if we can make a few minor changes to kmodtool and get this out there. Obviously, I'm very keen to hear from anyone else who wants to help :-) Thanks! Jon. From tcallawa at redhat.com Sat Jun 3 14:06:42 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 03 Jun 2006 09:06:42 -0500 Subject: [Fedora-packaging] kernel module packaging In-Reply-To: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> References: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> Message-ID: <1149343603.14611.31.camel@localhost.localdomain> On Sat, 2006-06-03 at 01:47 +0100, Jon Masters wrote: > Hi folks, > > I'm working on some to-be-proposed updates to the kernel module > packaging in Fedora Extras to allow us to track changes to the kernel > ABI rather than purely the kernel release/version. This should make > life easier and help to reduce the number of times that a minor kernel > update (e.g. security fixes, etc.) forces all external drivers to be > rebuilt. I'm not so sure this will work for Fedora. The ABI in the kernel is utterly inconsistent, and no work is being done upstream to try and keep the ABI consistent or predictable. In fact, in the majority of cases, a kernel module built against one kernel release/version will only work against that release/version. Effectively, the only ABI we can control in Fedora is the one for that kernel release/version. Now, RHEL is different, but these guidelines are Fedora specific. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From davej at redhat.com Sat Jun 3 17:01:22 2006 From: davej at redhat.com (Dave Jones) Date: Sat, 3 Jun 2006 13:01:22 -0400 Subject: [Fedora-packaging] kernel module packaging In-Reply-To: <1149343603.14611.31.camel@localhost.localdomain> References: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> <1149343603.14611.31.camel@localhost.localdomain> Message-ID: <20060603170122.GB1532@redhat.com> On Sat, Jun 03, 2006 at 09:06:42AM -0500, Tom 'spot' Callaway wrote: > On Sat, 2006-06-03 at 01:47 +0100, Jon Masters wrote: > > Hi folks, > > > > I'm working on some to-be-proposed updates to the kernel module > > packaging in Fedora Extras to allow us to track changes to the kernel > > ABI rather than purely the kernel release/version. This should make > > life easier and help to reduce the number of times that a minor kernel > > update (e.g. security fixes, etc.) forces all external drivers to be > > rebuilt. > > I'm not so sure this will work for Fedora. The ABI in the kernel is > utterly inconsistent, and no work is being done upstream to try and keep > the ABI consistent or predictable. I'd go as far as to say for Fedora, there *is no* kernel ABI, nor is it practical to make one. Dave -- http://www.codemonkey.org.uk From jonathan at jonmasters.org Mon Jun 5 12:29:10 2006 From: jonathan at jonmasters.org (Jon Masters) Date: Mon, 5 Jun 2006 13:29:10 +0100 Subject: [Fedora-packaging] Re: kernel module packaging In-Reply-To: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> References: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> Message-ID: <35fb2e590606050529u3ed2a48aic4df5915567910d9@mail.gmail.com> On Sat, Jun 03, 2006 at 13:01:22 -0400, Dave Jones wrote: > On Sat, Jun 03, 2006 at 09:06:42AM -0500, Tom 'spot' Callaway wrote: > > On Sat, 2006-06-03 at 01:47 +0100, Jon Masters wrote: > > > I'm working on some to-be-proposed updates to the kernel module > > > packaging in Fedora Extras to allow us to track changes to the kernel > > > ABI rather than purely the kernel release/version. This should make > > > life easier and help to reduce the number of times that a minor kernel > > > update (e.g. security fixes, etc.) forces all external drivers to be > > > rebuilt. > > I'm not so sure this will work for Fedora. The ABI in the kernel is > > utterly inconsistent, and no work is being done upstream to try and keep > > the ABI consistent or predictable. Sure. I understand. I guess what I'm saying is "look, you get this for free, it requires no extra effort on the part of the packager, but it may help reduce unnecessary updates". I understand the lack of a kernel ABI in Fedora - whenever part of the ABI changes, the module just becomes incompatible in its dependencies and you upgrade it in the usual way. > I'd go as far as to say for Fedora, there *is no* kernel ABI, nor > is it practical to make one. :-) Ok. Well, given that it doesn't hurt packagers or make their lives more difficult - isn't it worth making this available to them anyway? I'm cool with whatever the Fedora community want. Jon. P.S. This mail was hand munged via the archives, so it's going to break threading - for some reason I'm not getting fedora-packaging delivered directly right now even though I'm signed up. Will investigate. From tcallawa at redhat.com Mon Jun 5 12:55:59 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 05 Jun 2006 07:55:59 -0500 Subject: [Fedora-packaging] Re: kernel module packaging In-Reply-To: <35fb2e590606050529u3ed2a48aic4df5915567910d9@mail.gmail.com> References: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> <35fb2e590606050529u3ed2a48aic4df5915567910d9@mail.gmail.com> Message-ID: <1149512159.14611.148.camel@localhost.localdomain> On Mon, 2006-06-05 at 13:29 +0100, Jon Masters wrote: > Ok. Well, given that it doesn't hurt packagers or make their lives > more difficult - isn't it worth making this available to them anyway? > I'm cool with whatever the Fedora community want. The problem is this: By documenting it as part of our standards, we're implying that it is something with benefit to the packagers. Since there is no kernel ABI in Fedora or upstream (remember, all kernel ABIs in RHEL are artificial constructs), it does hurt packagers who are unaware of this fact. It leads them to believe that they don't need to use the full Requires: %{version}-%{release} in kernel-module addon packages, when they absolutely do. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jonathan at jonmasters.org Mon Jun 5 13:10:27 2006 From: jonathan at jonmasters.org (Jon Masters) Date: Mon, 5 Jun 2006 14:10:27 +0100 Subject: [Fedora-packaging] Re: kernel module packaging In-Reply-To: <1149512159.14611.148.camel@localhost.localdomain> References: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> <35fb2e590606050529u3ed2a48aic4df5915567910d9@mail.gmail.com> <1149512159.14611.148.camel@localhost.localdomain> Message-ID: <35fb2e590606050610g42e42af6of398a296fd01ab33@mail.gmail.com> On 6/5/06, Tom 'spot' Callaway wrote: > By documenting it as part of our standards, we're implying that it is > something with benefit to the packagers. Since there is no kernel ABI in > Fedora or upstream (remember, all kernel ABIs in RHEL are artificial > constructs), it does hurt packagers who are unaware of this fact. It > leads them to believe that they don't need to use the full Requires: > %{version}-%{release} in kernel-module addon packages, when they > absolutely do. Well, they wouldn't necessarily include that Requires line, because the kernel dependency is now against a set of binary checksums that determine compatibility. In fact, I'm not really calling for major packaging changes - by making a few changes to kmodtool behind the scenes, all of this is abstracted from the packager, who is free to demand a specific kernel or just let the dependency resolution figure out if the kernel and module will be compatible at RPM install time. The only issue really is how this would affect official "policy" with regards to kernel dependencies as you hinted at above. Jon. From tcallawa at redhat.com Mon Jun 5 13:56:19 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 05 Jun 2006 08:56:19 -0500 Subject: [Fedora-packaging] Re: kernel module packaging In-Reply-To: <35fb2e590606050610g42e42af6of398a296fd01ab33@mail.gmail.com> References: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> <35fb2e590606050529u3ed2a48aic4df5915567910d9@mail.gmail.com> <1149512159.14611.148.camel@localhost.localdomain> <35fb2e590606050610g42e42af6of398a296fd01ab33@mail.gmail.com> Message-ID: <1149515780.14611.152.camel@localhost.localdomain> On Mon, 2006-06-05 at 14:10 +0100, Jon Masters wrote: > On 6/5/06, Tom 'spot' Callaway wrote: > > > By documenting it as part of our standards, we're implying that it is > > something with benefit to the packagers. Since there is no kernel ABI in > > Fedora or upstream (remember, all kernel ABIs in RHEL are artificial > > constructs), it does hurt packagers who are unaware of this fact. It > > leads them to believe that they don't need to use the full Requires: > > %{version}-%{release} in kernel-module addon packages, when they > > absolutely do. > > Well, they wouldn't necessarily include that Requires line, because > the kernel dependency is now against a set of binary checksums that > determine compatibility. These binary checksums will change with every single kernel release/variant. I'm not sure I see the point of using an always unique binary checksum vs a %{version}-%{release}? > In fact, I'm not really calling for major packaging changes - by > making a few changes to kmodtool behind the scenes, all of this is > abstracted from the packager, who is free to demand a specific kernel > or just let the dependency resolution figure out if the kernel and > module will be compatible at RPM install time. The only issue really > is how this would affect official "policy" with regards to kernel > dependencies as you hinted at above. If kmodtool starts providing this by default, then there would be no need for the Requires: v-r in the policy. I suspect you'd need to convince the kmodtool author(s), not me. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jonathan at jonmasters.org Mon Jun 5 14:07:33 2006 From: jonathan at jonmasters.org (Jon Masters) Date: Mon, 5 Jun 2006 15:07:33 +0100 Subject: [Fedora-packaging] Re: kernel module packaging In-Reply-To: <1149515780.14611.152.camel@localhost.localdomain> References: <35fb2e590606021747m50ecd261q6c7545f5497e5b80@mail.gmail.com> <35fb2e590606050529u3ed2a48aic4df5915567910d9@mail.gmail.com> <1149512159.14611.148.camel@localhost.localdomain> <35fb2e590606050610g42e42af6of398a296fd01ab33@mail.gmail.com> <1149515780.14611.152.camel@localhost.localdomain> Message-ID: <35fb2e590606050707k361ad7c2y61072108f9564df2@mail.gmail.com> On 6/5/06, Tom 'spot' Callaway wrote: > > In fact, I'm not really calling for major packaging changes - by > > making a few changes to kmodtool behind the scenes, all of this is > > abstracted from the packager, who is free to demand a specific kernel > > or just let the dependency resolution figure out if the kernel and > > module will be compatible at RPM install time. The only issue really > > is how this would affect official "policy" with regards to kernel > > dependencies as you hinted at above. > > If kmodtool starts providing this by default, then there would be no > need for the Requires: v-r in the policy. I suspect you'd need to > convince the kmodtool author(s), not me. :) That's what I'm trying to do at the moment :-) With that done, there's no need to make user-visible changes to the packaging process at this stage, except that we can introduce a >= type dependency on the base kernel release if it's felt that a kernel version should be included in addition to the binary dependency information. To check out what I mean, take a rawhide kernel and do: rpm -q --provides kernel on it. You'll see a set of dependencies, one per directory of the kernel source used to build that kernel. For example kernel(kernel) = blah means that the checksum for built-ins in the /kernel subdirectory is blah. This is then matched against in the dependencies of the module. Part 2. I've also spoken to the SuSE folks about agreeing on a joint packaging standard for driver updates that could be used in Fedora, OpenSUSE and potentially in commercial products at a later stage. There's a channel for communication there so I want to explore that in the longer term - having a common set of RPM macros that encapsulate our differences and present a single spec file format. I don't know if you folks will love or hate that idea :-) Jon. From fedora at leemhuis.info Mon Jun 5 16:09:55 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 05 Jun 2006 18:09:55 +0200 Subject: [Fedora-packaging] new wiki-page: Packaging/FrequentlyMadeMistakes Message-ID: <1149523795.5767.11.camel@localhost.localdomain> Hi! Just FYI: I created a new page in the wiki at http://www.fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes I'd like to collect and describe some common and frequently made mistakes there that happen while packaging RPM-Files and putting them under review for Extras. Maybe that helps one or two packagers to avoid those mistakes. Currently it only lists three common problems that afaics new packagers often make -- but I'm sure there are many others so feel free to add them on the page. There are probably also some general mistakes that even experienced packagers tip into now and then -- please write them up on the page, too. tia CU thl -- Thorsten Leemhuis From shishz at hotpop.com Mon Jun 5 23:53:08 2006 From: shishz at hotpop.com (Zing) Date: Mon, 05 Jun 2006 19:53:08 -0400 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? Message-ID: I'm looking into packaging gtypist, which has an emacs add-on: gtypist-mode.{el,elc} I'd like to just put %{_datadir}/emacs/site-lisp/* in %files and be done with it but this seems to go in direct opposition to the following: ================================================================ http://fedoraproject.org/wiki/Packaging/ReviewGuidelines MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard ([WWW] http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. ================================================================= So I can (in my personal ascending in preference): 1. Require: emacs (this doesn't seem reasonable for people who don't use emacs since the lisp add-ons are usually optional) 2. do something like cscope and use triggers (just say no to triggers). 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, but is there a naming guideline for this situation? What would the name be? Is this worth the effort?) or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :) zing From jpo at lsd.di.uminho.pt Tue Jun 6 00:10:13 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Tue, 06 Jun 2006 01:10:13 +0100 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: References: Message-ID: <4484C7E5.1070805@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zing wrote: > I'm looking into packaging gtypist, which has an emacs add-on: > gtypist-mode.{el,elc} > > I'd like to just put %{_datadir}/emacs/site-lisp/* in %files and be done > with it but this seems to go in direct opposition to the following: > > ================================================================ > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > > MUST: A package must own all directories that it creates. If it does not > create a directory that it uses, then it should require a package which > does create that directory. The exception to this are directories listed > explicitly in the Filesystem Hierarchy Standard ([WWW] > http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume > that those directories exist. > > MUST: Packages must not own files or directories already owned by other > packages. The rule of thumb here is that the first package to be installed > should own the files or directories that other packages may rely upon. > This means, for example, that no package in Fedora should ever share > ownership with any of the files or directories owned by the filesystem or > man package. If you feel that you have a good reason to own a file or > directory that another package owns, then please present that at package > review time. > ================================================================= > > So I can (in my personal ascending in preference): > > 1. Require: emacs (this doesn't seem reasonable for people who > don't use emacs since the lisp add-ons are usually optional) > 2. do something like cscope and use triggers (just say no to triggers). > 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, > but is there a naming guideline for this situation? What would the name > be? Is this worth the effort?) > > or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :) Use triggers and ghost the emacs/xemacs directories. For an example see the fedora-rpmdevtools specfile. jpo - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEhMfkl0metZG9hRsRAox/AKDhIQaiRS2pyF5O88j7cOYGbFPELACeLk27 6O1QUQiLEjx7KpUgATy2mzE= =oAlO -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From tcallawa at redhat.com Tue Jun 6 13:27:37 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Jun 2006 08:27:37 -0500 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <4484C7E5.1070805@lsd.di.uminho.pt> References: <4484C7E5.1070805@lsd.di.uminho.pt> Message-ID: <1149600457.22448.21.camel@localhost.localdomain> On Tue, 2006-06-06 at 01:10 +0100, Jose Pedro Oliveira wrote: > > So I can (in my personal ascending in preference): > > > > 1. Require: emacs (this doesn't seem reasonable for people who > > don't use emacs since the lisp add-ons are usually optional) > > 2. do something like cscope and use triggers (just say no to triggers). > > 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, > > but is there a naming guideline for this situation? What would the name > > be? Is this worth the effort?) > > > > or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :) > > Use triggers and ghost the emacs/xemacs directories. For an example see > the fedora-rpmdevtools specfile. Or: Create a sub-package for the emacs lisp add-ons. Naming guideline for this situation is here: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonEmacs I think I'd prefer that over triggers, but either will probably pass review. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From Matt_Domsch at dell.com Tue Jun 6 14:19:13 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 6 Jun 2006 09:19:13 -0500 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <1149600457.22448.21.camel@localhost.localdomain> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> Message-ID: <20060606141912.GA28616@lists.us.dell.com> On Tue, Jun 06, 2006 at 08:27:37AM -0500, Tom 'spot' Callaway wrote: > On Tue, 2006-06-06 at 01:10 +0100, Jose Pedro Oliveira wrote: > > Use triggers and ghost the emacs/xemacs directories. For an example see > > the fedora-rpmdevtools specfile. > > Or: > > Create a sub-package for the emacs lisp add-ons. Naming guideline for > this situation is here: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonEmacs > > I think I'd prefer that over triggers, but either will probably pass > review. Linux Standard Base disallows the use of triggers (that's another argument against them). -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jpo at lsd.di.uminho.pt Tue Jun 6 15:53:56 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Tue, 06 Jun 2006 16:53:56 +0100 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <1149600457.22448.21.camel@localhost.localdomain> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> Message-ID: <4485A514.8010505@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom 'spot' Callaway wrote: > On Tue, 2006-06-06 at 01:10 +0100, Jose Pedro Oliveira wrote: > >>> So I can (in my personal ascending in preference): >>> >>> 1. Require: emacs (this doesn't seem reasonable for people who >>> don't use emacs since the lisp add-ons are usually optional) >>> 2. do something like cscope and use triggers (just say no to triggers). >>> 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, >>> but is there a naming guideline for this situation? What would the name >>> be? Is this worth the effort?) >>> >>> or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :) >> Use triggers and ghost the emacs/xemacs directories. For an example see >> the fedora-rpmdevtools specfile. > > Or: > > Create a sub-package for the emacs lisp add-ons. Naming guideline for > this situation is here: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonEmacs > > I think I'd prefer that over triggers, but either will probably pass > review. If you are talking about installing only one file like * emacs/xemacs mode file * emacs/xemacs init file * vim files (eg: syntax file) * bash-completion file it appears to me a little overkill to create a subpackage but I am opened to suggestions. Right now, almost every package that installs the above files appears to do so in different ways. Just try to see who owns the directories * rpm -qf /etc/bash_completion.d/ bash-completion-20060301-1.fc5 rpmlint-0.76-1.fc5 * rpm -qf /usr/share/emacs/site-lisp/ desktop-file-utils-0.10-6.1 libidn-0.6.2-1.1 autoconf-2.59-7 gforth-0.6.2-6.fc5 subversion-1.3.1-2.1 fedora-rpmdevtools-1.6-1.fc5 emacs-common-21.4-14 asymptote-1.06-5.fc5 * ... xemacs ... * ... vim ... and how many files are symbolic links. - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEhaUUl0metZG9hRsRAl9cAJ9t7/0mTTR6UL/L4SP7/+kFdZ721wCfco3k 5kQJGrEu3saHEQhIh6aWr8Y= =MnWk -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From toshio at tiki-lounge.com Tue Jun 6 16:39:10 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 06 Jun 2006 09:39:10 -0700 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <4485A514.8010505@lsd.di.uminho.pt> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> <4485A514.8010505@lsd.di.uminho.pt> Message-ID: <1149611950.3413.6.camel@localhost> On Tue, 2006-06-06 at 16:53 +0100, Jose Pedro Oliveira wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom 'spot' Callaway wrote: > > On Tue, 2006-06-06 at 01:10 +0100, Jose Pedro Oliveira wrote: > > > >>> So I can (in my personal ascending in preference): > >>> > >>> 1. Require: emacs (this doesn't seem reasonable for people who > >>> don't use emacs since the lisp add-ons are usually optional) > >>> 2. do something like cscope and use triggers (just say no to triggers). > >>> 3. create a sub-package just for the emacs lisp add-on. (seems cleanest, > >>> but is there a naming guideline for this situation? What would the name > >>> be? Is this worth the effort?) > >>> > >>> or... 4. Can I just go ahead with %{_datadir}/emacs/site-lisp/*? :) > >> Use triggers and ghost the emacs/xemacs directories. For an example see > >> the fedora-rpmdevtools specfile. > > > > Or: > > > > Create a sub-package for the emacs lisp add-ons. Naming guideline for > > this situation is here: > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonEmacs > > > > I think I'd prefer that over triggers, but either will probably pass > > review. > > If you are talking about installing only one file like > > * emacs/xemacs mode file > * emacs/xemacs init file > * vim files (eg: syntax file) My impression is that vim syntax files really need to be separate subpackages because the directory hierarchy they land in is versioned. Did you find a way around that? (Our discussion on IRC was cut short b/c of the FESCo meeting so I don't know if there's some neat trick you have in mind.) > * bash-completion file > > it appears to me a little overkill to create a subpackage but I am > opened to suggestions. > Overkill but arguably the cleanest. > Right now, almost every package that installs the above files appears > to do so in different ways. > > Just try to see who owns the directories > > * rpm -qf /etc/bash_completion.d/ > bash-completion-20060301-1.fc5 > rpmlint-0.76-1.fc5 So this is the third (and deprecated?) method -- multiple owners of the directories. -------------- 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 jpo at lsd.di.uminho.pt Tue Jun 6 18:07:45 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Tue, 06 Jun 2006 19:07:45 +0100 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <1149611950.3413.6.camel@localhost> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> <4485A514.8010505@lsd.di.uminho.pt> <1149611950.3413.6.camel@localhost> Message-ID: <4485C471.1070404@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Toshio Kuratomi wrote: [SINP] >> * vim files (eg: syntax file) > > My impression is that vim syntax files really need to be separate > subpackages because the directory hierarchy they land in is versioned. > Did you find a way around that? I managed to come up with a couple of trigger scripts that allowed me to install the vim syntax files and still support vim updates although limited to vim 6.3, 6.4, and 7.0 (FC-3 .. FC-6). The package ghosts the directories /usr/share/vim/vim{63,64,70} in order to avoid leaving unowned directories during vim upgrades or removals. > >> * bash-completion file >> >> it appears to me a little overkill to create a subpackage but I am >> opened to suggestions. >> > Overkill but arguably the cleanest. Yes. And you still haven't seen the scripts to install vim syntax files ;) See the FE asymptote package (specfile also available here http://gsd.di.uminho.pt/jpo/software/fedora/asymptote.spec). Again suggestions are welcome to avoid those fragile scripts. > >> Right now, almost every package that installs the above files appears >> to do so in different ways. >> >> Just try to see who owns the directories >> >> * rpm -qf /etc/bash_completion.d/ >> bash-completion-20060301-1.fc5 >> rpmlint-0.76-1.fc5 > > So this is the third (and deprecated?) method -- multiple owners of the > directories. jpo - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEhcRxl0metZG9hRsRAkvnAJ0Y9d3gxXb+vA0Q/b/N3ZuoMdcAewCfRrlD Xhum0ByzbmBX6cykhyDH4Z8= =6gNr -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From tcallawa at redhat.com Tue Jun 6 18:07:21 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Jun 2006 13:07:21 -0500 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <1149611950.3413.6.camel@localhost> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> <4485A514.8010505@lsd.di.uminho.pt> <1149611950.3413.6.camel@localhost> Message-ID: <1149617242.22448.39.camel@localhost.localdomain> On Tue, 2006-06-06 at 09:39 -0700, Toshio Kuratomi wrote: > So this is the third (and deprecated?) method -- multiple owners of the > directories. Owning directories is right out, because if/when rpm erase ordering is actually implemented correctly (at all?), this will be vital. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From toshio at tiki-lounge.com Tue Jun 6 18:38:24 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 06 Jun 2006 11:38:24 -0700 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <4485C471.1070404@lsd.di.uminho.pt> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> <4485A514.8010505@lsd.di.uminho.pt> <1149611950.3413.6.camel@localhost> <4485C471.1070404@lsd.di.uminho.pt> Message-ID: <1149619105.3413.49.camel@localhost> On Tue, 2006-06-06 at 19:07 +0100, Jose Pedro Oliveira wrote: > > > >> * bash-completion file > >> > >> it appears to me a little overkill to create a subpackage but I am > >> opened to suggestions. > >> > > Overkill but arguably the cleanest. > > Yes. And you still haven't seen the scripts to install vim syntax > files ;) > > See the FE asymptote package (specfile also available here > http://gsd.di.uminho.pt/jpo/software/fedora/asymptote.spec). > > Again suggestions are welcome to avoid those fragile scripts. > Icky :-( I can't think of a way to make them more robust, though. I'd be inclined to make a subpackage for the vim syntax files. The emacs trigger scripts are reasonably understandable and work over a wide range of emacs versions (I haven't gone back far enough to find a RHL release on which they won't work.) If upstream vim keeps up their release pace, the vim trigger scripts will be broken within two years. Additionally, the %ghost trick used for both vim and emacs cleanup will cause double ownership of directories which spot says is not just deprecated but a blocker. -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 jpo at lsd.di.uminho.pt Tue Jun 6 19:04:38 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Tue, 06 Jun 2006 20:04:38 +0100 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <1149619105.3413.49.camel@localhost> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> <4485A514.8010505@lsd.di.uminho.pt> <1149611950.3413.6.camel@localhost> <4485C471.1070404@lsd.di.uminho.pt> <1149619105.3413.49.camel@localhost> Message-ID: <4485D1C6.4020105@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Toshio, [SNIP] > Additionally, the %ghost trick used for both vim and emacs cleanup will > cause double ownership of directories which spot says is not just > deprecated but a blocker. Sorry but I disagree. Even (or better when) if rpm can remove packages in the correct order there are situations you can't avoid having two or more packages owning the same directory (for good examples check packages in the perl namespace). jpo PS - Several packages in the tetex namespace also own the same directories. - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEhdHGl0metZG9hRsRAhJBAKCVvlA1pED9JDYtmWFZF+M53G+yDgCg0P4E DNLLV+Hgvg8LSzzNOCpGndQ= =4tI1 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From tcallawa at redhat.com Tue Jun 6 19:25:10 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Jun 2006 14:25:10 -0500 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <4485D1C6.4020105@lsd.di.uminho.pt> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> <4485A514.8010505@lsd.di.uminho.pt> <1149611950.3413.6.camel@localhost> <4485C471.1070404@lsd.di.uminho.pt> <1149619105.3413.49.camel@localhost> <4485D1C6.4020105@lsd.di.uminho.pt> Message-ID: <1149621910.22448.73.camel@localhost.localdomain> On Tue, 2006-06-06 at 20:04 +0100, Jose Pedro Oliveira wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Toshio, > [SNIP] > > Additionally, the %ghost trick used for both vim and emacs cleanup will > > cause double ownership of directories which spot says is not just > > deprecated but a blocker. > > Sorry but I disagree. Even (or better when) if rpm can remove > packages in the correct order there are situations you can't > avoid having two or more packages owning the same directory > (for good examples check packages in the perl namespace). The only time we're permitting duplicate directory ownership is when there is not a clear dependency tree: Package A uses /usr/foo to store files Package B uses /usr/foo to store files Neither package relies on anything that creates /usr/foo, and either package can be installed independently. Then, and ONLY then can both packages own /usr/foo. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jpo at lsd.di.uminho.pt Tue Jun 6 20:02:16 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Tue, 06 Jun 2006 21:02:16 +0100 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <1149621910.22448.73.camel@localhost.localdomain> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> <4485A514.8010505@lsd.di.uminho.pt> <1149611950.3413.6.camel@localhost> <4485C471.1070404@lsd.di.uminho.pt> <1149619105.3413.49.camel@localhost> <4485D1C6.4020105@lsd.di.uminho.pt> <1149621910.22448.73.camel@localhost.localdomain> Message-ID: <4485DF48.6050807@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom 'spot' Callaway wrote: > On Tue, 2006-06-06 at 20:04 +0100, Jose Pedro Oliveira wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Toshio, >> [SNIP] >>> Additionally, the %ghost trick used for both vim and emacs cleanup will >>> cause double ownership of directories which spot says is not just >>> deprecated but a blocker. >> Sorry but I disagree. Even (or better when) if rpm can remove >> packages in the correct order there are situations you can't >> avoid having two or more packages owning the same directory >> (for good examples check packages in the perl namespace). > > The only time we're permitting duplicate directory ownership is when > there is not a clear dependency tree: > > Package A uses /usr/foo to store files > Package B uses /usr/foo to store files > Neither package relies on anything that creates /usr/foo, and either > package can be installed independently. Then, and ONLY then can both > packages own /usr/foo. What about these perl cenarios? Perl module A::B Perl module A::B::C (and requires A::B) 1) Perl module A::B is a perl core module perl module A::B::C is not (CPAN) Different directories trees (core vs vendor). 2) Both perl modules are CPAN modules with different perl(:MODULE_COMPAT_xxx) requirements Vendor directory tree but different perl versions requirements. 3) Both perl modules are CPAN modules with the same perl(:MODULE_COMPAT_xxx) requirements Removal order. Perl module A::B::C should always own the A directory (also owned by A::B) or not ? jpo jpo - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEhd9Il0metZG9hRsRArX5AJ4n/Dz3U9M+qU9ZM2fdIDnmecSUWwCgveK/ WjFIGezgDEIMHLu1pk9capA= =qJ61 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From tcallawa at redhat.com Tue Jun 6 23:13:37 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Jun 2006 18:13:37 -0500 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <4485DF48.6050807@lsd.di.uminho.pt> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> <4485A514.8010505@lsd.di.uminho.pt> <1149611950.3413.6.camel@localhost> <4485C471.1070404@lsd.di.uminho.pt> <1149619105.3413.49.camel@localhost> <4485D1C6.4020105@lsd.di.uminho.pt> <1149621910.22448.73.camel@localhost.localdomain> <4485DF48.6050807@lsd.di.uminho.pt> Message-ID: <1149635617.22448.98.camel@localhost.localdomain> On Tue, 2006-06-06 at 21:02 +0100, Jose Pedro Oliveira wrote: > What about these perl cenarios? > > Perl module A::B > Perl module A::B::C (and requires A::B) Thus, whenever Perl module A::B::C is installed, A::B will already be there. If they have a common directory, A::B should own it, not A::B::C. > Perl module A::B::C should always own the A directory > (also owned by A::B) or not ? No. Package at the top of the dependency chain should own it. So, if A::B is the top, then it should own the A directory, since A::B::C can't go in without A::B. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From jpo at lsd.di.uminho.pt Wed Jun 7 08:11:21 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Wed, 07 Jun 2006 09:11:21 +0100 Subject: [Fedora-packaging] proper way to install emacs lisp add-ons? In-Reply-To: <1149635617.22448.98.camel@localhost.localdomain> References: <4484C7E5.1070805@lsd.di.uminho.pt> <1149600457.22448.21.camel@localhost.localdomain> <4485A514.8010505@lsd.di.uminho.pt> <1149611950.3413.6.camel@localhost> <4485C471.1070404@lsd.di.uminho.pt> <1149619105.3413.49.camel@localhost> <4485D1C6.4020105@lsd.di.uminho.pt> <1149621910.22448.73.camel@localhost.localdomain> <4485DF48.6050807@lsd.di.uminho.pt> <1149635617.22448.98.camel@localhost.localdomain> Message-ID: <44868A29.9050903@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom 'spot' Callaway wrote: > On Tue, 2006-06-06 at 21:02 +0100, Jose Pedro Oliveira wrote: > >> What about these perl cenarios? >> >> Perl module A::B >> Perl module A::B::C (and requires A::B) > > Thus, whenever Perl module A::B::C is installed, A::B will already be > there. If they have a common directory, A::B should own it, not > A::B::C. Not true. Both modules need to own the A directory. The A directory may have different full paths or one of the modules A directory path may change in the future. >> Perl module A::B::C should always own the A directory >> (also owned by A::B) or not ? > > No. Package at the top of the dependency chain should own it. So, if > A::B is the top, then it should own the A directory, since A::B::C can't > go in without A::B. Both modules need to own the A directory. Assume again that we have two perl modules from CPAN 1) A::B 2) A::B::C which requires A::B let's also assume that both modules were both build with the same perl version (eg: 5.8.8) 1) A::B owns the /usr/lib/perl5/vendor_perl/5.8.8/A directory 2) A::B::C only owns the /usr/lib/perl5/vendor_perl/5.8.8/A/B directory (as you want) In a couple of months perl 5.8.9 gets released and a little latter one of the modules gets updated (let's assume A::B). Now the module A::B gets rebuild and it now owns /usr/lib/perl5/vendor_perl/5.8.9/A When you upgrade the module A::B the directory /usr/lib/perl5/vendor_perl/5.8.8/A will be unowned. Remember that Fedora Core perl maintains several old perl paths in its directory search path. Just see the output of "perl -V" or print the value of the @INC array. jpo - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEhoopl0metZG9hRsRAraSAJ9BRNpoBbNNdUKZZJB1SiRzGLXIbQCgwAIz ckELB4/wmtz1z2bwt14BuTs= =3Z/V -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From toshio at tiki-lounge.com Thu Jun 8 15:27:18 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 08 Jun 2006 08:27:18 -0700 Subject: [Fedora-packaging] Mono Packaging (was Re: On the subject of sponsors...) In-Reply-To: <4487EB5E.8070100@city-fan.org> References: <1149757812.22694.9.camel@mrwibble.mrwobble> <4487EB5E.8070100@city-fan.org> Message-ID: <1149780438.3152.14.camel@localhost> On Thu, 2006-06-08 at 10:18 +0100, Paul Howarth wrote: > > I'm still looking for mono packaging standards to be sorted out; for > instance, the %{_libdir} hack is still under debate, as is a move to put > mono stuff under %{_datadir}. Are we collecting the open questions about packaging mono apps anywhere? http://www.fedoraproject.org/wiki/Packaging/Mono seems to be an instruction manual for packaging mono rather than a lit of questions we need to solve (and lists the _libdir hack as a solution a bit prematurely, IMHO) Another open question would be how this affects us: http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs It's advocating using .dlls with unstable APIs the same way we normally use static libraries (including a local copy with the application). It has all the usual features of a static library scheme but fails to mention any security issues. Should packages entering Fedora be checked to make sure they *do not* follow this or are mono .dlls immune to the security concerns with normal static libraries? PS: This is moving into general packaging territory so I'm cross-posting it to fedora-packaging. Replies to fedora-packaging please. -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 9 18:07:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 Jun 2006 13:07:17 -0500 Subject: [Fedora-packaging] libtool archives (.la files) and rpm packaging Message-ID: Had some spare cycles today, so thought I'd share my highly editorial take on libtool .la file with the world. Enjoy. http://www.math.unl.edu/~rdieter1/libtool-archives-suck.html (Don't take it too seriously... well, a little bit...) -- Rex From enrico.scholz at informatik.tu-chemnitz.de Fri Jun 9 20:21:50 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Jun 2006 22:21:50 +0200 Subject: [Fedora-packaging] libtool archives (.la files) and rpm packaging In-Reply-To: (Rex Dieter's message of "Fri, 09 Jun 2006 13:07:17 -0500") References: Message-ID: <87mzcm3wrl.fsf@kosh.bigo.ensc.de> rdieter at math.unl.edu (Rex Dieter) writes: > Had some spare cycles today, so thought I'd share my highly editorial take > on libtool .la file with the world. Enjoy. > > http://www.math.unl.edu/~rdieter1/libtool-archives-suck.html It is not (only) *.la which sucks but the whole 'libtool' suite: * when having a package which provides multiple libraries which are linked together, you could create an efficient libfoo0 -> libfoo1 -> libfoo2 -> APP dependency chain. With libtool you will always end with libfoo0 --, libfoo0 ---> libfoo1 ---> APP libfoo0 ---> libfoo2 --' libfoo0 --> libfoo1 --' * libtool reorders linker options, so that | -Wl,--as-needed -lz -lfoo -lbar becomes | -lz -lfoo -lbar -Wl,--as-needed rendering the '-Wl,--as-needed' effectless * libtool is a bloaty shell script slowing down the build process significantly * integration into automake makes 'make -s' useless * it creates alwyas RPATHs in multilib environments (except you apply unofficial patches) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From michael at knox.net.nz Sun Jun 11 01:52:50 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sun, 11 Jun 2006 13:52:50 +1200 Subject: [Fedora-packaging] java packaging. Message-ID: <448B7772.9010800@knox.net.nz> Hey all, Since the correct way to build java packages is outlined here: http://fedoraproject.org/wiki/NativeJava and http://www.redhat.com/archives/fedora-extras-list/2006-June/msg00254.html Should there be a link from the packaging guide lines to the NativeJava wiki page ? Thanks Michael From ville.skytta at iki.fi Sun Jun 11 15:56:36 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 11 Jun 2006 18:56:36 +0300 Subject: [Fedora-packaging] RFC: init script naming Message-ID: <1150041396.12439.22.camel@localhost.localdomain> rpmlint currently whines if a package installs one init script, and the init script name doesn't match the package name. If more than one init scripts are installed from one package, it doesn't emit this warning. I don't think there are any naming guidelines for init scripts currently in effect, so I'm wondering if I should just filter out the warning in future rpmlint package revisions, or if people think that the way rpmlint currently wants the init scripts named would be make a good packaging guideline. Thoughts? From jkeating at j2solutions.net Sun Jun 11 16:15:11 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 11 Jun 2006 12:15:11 -0400 Subject: [Fedora-packaging] RFC: init script naming In-Reply-To: <1150041396.12439.22.camel@localhost.localdomain> References: <1150041396.12439.22.camel@localhost.localdomain> Message-ID: <1150042511.2363.17.camel@ender> On Sun, 2006-06-11 at 18:56 +0300, Ville Skytt? wrote: > > rpmlint currently whines if a package installs one init script, and the > init script name doesn't match the package name. If more than one init > scripts are installed from one package, it doesn't emit this warning. > > I don't think there are any naming guidelines for init scripts currently > in effect, so I'm wondering if I should just filter out the warning in > future rpmlint package revisions, or if people think that the way > rpmlint currently wants the init scripts named would be make a good > packaging guideline. > I think it is a good guideline if possible. When the name makes sense. package 'sendmail' makes sense to have a sendmail init.d script. There are a lot of examples though of package that has a daemon component named d. Maybe do a warning if the init script isn't %{name} || %{name}d ? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Lam at Lam.pl Sun Jun 11 17:33:44 2006 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 11 Jun 2006 19:33:44 +0200 Subject: [Fedora-packaging] RFC: init script naming In-Reply-To: <1150042511.2363.17.camel@ender> References: <1150041396.12439.22.camel@localhost.localdomain> <1150042511.2363.17.camel@ender> Message-ID: <1150047224.2853.28.camel@pensja.lam.pl> Dnia 11-06-2006, nie o godzinie 12:15 -0400, Jesse Keating napisa?(a): > I think it is a good guideline if possible. When the name makes sense. > package 'sendmail' makes sense to have a sendmail init.d script. There > are a lot of examples though of package that has a daemon > component named d. Maybe do a warning if the init script isn't > %{name} || %{name}d ? I still don't get why "sendmail" is good for package name and an init.d script name and "apache" is not. Sendmail is an MTA and I should start any MTA using for example "service smtpd start". Apache HTTP Server (see, it even doesn't contain "HTTPD" in its name!) is HTTP daemon, but not the only one out there, so while "service httpd start" looks good, the package name isn't good at all. I vote for package name being package name and init script being named after the function it performs. I know that it makes it impossible to have 7 httpds installed at a time, but: 1. they can't co-exist nicely anyhow (every httpd is configured to run on port 80, even hacking config files and running another one on port 81 is not an option for many firewalls) and 2. if the program to do a function changes name or is replaced by another program (sendmail by postfix, uw-imap by dovecot or something), I don't have to learn, which program replaces which and does what. I just need to know which service do I need to enable in ntsysv/system-config-services. This is important to make Fedora user-friendly and to make many different Fedora FAQ-s to work for more than one release. Alternatively, can't something like /etc/alternatives be used if many httpds/mtas/whatever are installed? Or even a multi-daemon system, where I have one /etc/init.d/httpd which can start any number of http daemons using their init scripts if they are configured (like /etc/init.d/network starts many interfaces depending on their configuration)? Debian took another route, I even have to know which Apache HTTPD version is installed, because the old one is called "apache" and newer "apache2". At least one of many httpds isn't preferred over other ones by using name like "the only "httpd" in the distribution" ;) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From notting at redhat.com Mon Jun 12 15:43:05 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jun 2006 11:43:05 -0400 Subject: [Fedora-packaging] RFC: init script naming In-Reply-To: <1150047224.2853.28.camel@pensja.lam.pl> References: <1150041396.12439.22.camel@localhost.localdomain> <1150042511.2363.17.camel@ender> <1150047224.2853.28.camel@pensja.lam.pl> Message-ID: <20060612154305.GD11296@nostromo.devel.redhat.com> Leszek Matok (Lam at Lam.pl) said: > I still don't get why "sendmail" is good for package name and an init.d > script name and "apache" is not. Sendmail is an MTA and I should start > any MTA using for example "service smtpd start". Leads to file conflicts. > Apache HTTP Server > (see, it even doesn't contain "HTTPD" in its name!) is HTTP daemon, but > not the only one out there, so while "service httpd start" looks good, > the package name isn't good at all. httpd is required as part of the apache trademark stuff, IIRC. > Alternatively, can't something like /etc/alternatives be used if many > httpds/mtas/whatever are installed? Or even a multi-daemon system, where > I have one /etc/init.d/httpd which can start any number of http daemons > using their init scripts if they are configured > (like /etc/init.d/network starts many interfaces depending on their > configuration)? Alternatives should be used less, not more. :) Bill From tcallawa at redhat.com Mon Jun 12 23:23:32 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 12 Jun 2006 18:23:32 -0500 Subject: [Fedora-packaging] Mono Packaging Issues Message-ID: <1150154612.5199.282.camel@localhost.localdomain> As I look into lifting the hold on Mono packages in Fedora Extras (aka, blessing the mono packaging guidelines found here: http://fedoraproject.org/wiki/Packaging/Mono), I'd like to state my opinions on the following blocker issues: 1. Redefining libdir for mono packages: If mono and its tools cannot find a library on a 64bit architecture when it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken on that architecture, and needs to be fixed. This is a serious flaw, and I will not have us doing ugly hacks in spec files to work around mono's ineptitude. Every other core component is able to handle this, this bug should be filed and fixed. 2. Putting DLLs in %{_datadir} vs %{_libdir}: The FHS says that /usr/share (aka, %{_datadir}) is for "Architecture Independent Data". These DLL files do not seem to qualify as "Architecture Independent Data". I think that having them live in the: %{_libdir}/mono/ hierarchy seems to be the most appropriate for them at this point in time. Obviously, this can be revisited if upstream changes the default location. The gacutil command should be putting these DLL files in the right place. 3. Forcing local copies of DLL libraries instead of using system installed DLLs. This concept is documented upstream here: http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs IMHO, this is a really stupid and braindead idea. In fact, I've yet to talk to anyone who actually thinks this is a good idea. This is the same thing as static linking a private copy of a library instead of using the system shared lib. We do NOT permit this sort of behavior in Fedora, and mono is no exception. I've copied alexl on this email, since he is the mono owner in Fedora Core, and likely has an opinion or two. ;) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From toshio at tiki-lounge.com Tue Jun 13 05:41:26 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 12 Jun 2006 22:41:26 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150154612.5199.282.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> Message-ID: <1150177286.3175.49.camel@localhost> Hi spot! On Mon, 2006-06-12 at 18:23 -0500, Tom 'spot' Callaway wrote: > 1. Redefining libdir for mono packages: > > If mono and its tools cannot find a library on a 64bit architecture > when > it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken > on that architecture, and needs to be fixed. I agree. > 2. Putting DLLs in %{_datadir} vs %{_libdir}: > > The FHS says that /usr/share (aka, %{_datadir}) is for "Architecture > Independent Data". These DLL files do not seem to qualify as > "Architecture Independent Data". I think that having them live in the: > %{_libdir}/mono/ hierarchy seems to be the most appropriate for them > at > this point in time. Obviously, this can be revisited if upstream > changes > the default location. The gacutil command should be putting these DLL > files in the right place. > My understanding is .dlls and .exes are architecture independent. Should they end up in %{_libdir} or always end up in /usr/lib? Fedora's Python and Perl place arch independent data into /usr/lib, (I assume so that they can be noarch) should mono as well? All the *-sharp packages on my system currently follow this convention but beagle, tomboy, and banshee end up in %{_libdir}. Perhaps relevantly, these three are primarily applications but they do supply .dlls. I have only one package on my system that installs something into /usr/lib(!mono): gtk-sharp2 => /usr/lib/gtk-sharp-2.0/gconfsharp-schemagen.exe. By contrast the beagle/tomboy/banshee triumvirate install to %{_libdir}/[PKGNAME] Should this be allowed by the guidelines or should all mono packages go under /usr/lib/mono (similar to the python and perl hierarchies in /usr/lib) The above examples illustrate that applications and libraries are currently defaulting to different areas. Does it make sense to put applications in a different area than libraries? Python and Perl seem to use /usr/lib for arch independent libraries, %{_libdir} for arch dependent libraries, and %{_datadir}/[PKGNAME] for arch-independent program-specific scripts. (ex: rpmlint). There is one mono application under review (nant) that places its files in %{_datadir)/[PKGNAME]. Do we need to move this or is it fine as is? If we separate applications and libraries, how do we determine which .dlls belong in an application directory and which belong in a library directory? ELF shared libraries have ldconfig as a tipoff. I can think of the following tipoffs for a mono library, are there others? The .dll is listed in a pkgconfig .pc file. The package attempts to setup the .dll in the GAC. (What are the telltales of this?) Forcing everything to /usr/lib/mono would be the easiest to review but would cause a lot of hard to justify changing of upstream's install locations. OTOH, the hodgepodge of locations we have now is not conducive to good reviewing because it leaves all these ambiguous areas. Where do you see the logical lines falling? > 3. Forcing local copies of DLL libraries instead of using system > installed DLLs. > This concept is documented upstream here: > http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs > IMHO, this is a really stupid and braindead idea. In fact, I've yet to > talk to anyone who actually thinks this is a good idea. This is the > same > thing as static linking a private copy of a library instead of using > the > system shared lib. We do NOT permit this sort of behavior in Fedora, > and > mono is no exception. Here here! What are the easy ways to detect this issue? 1) Upstream tarball contains .dlls that were not rebuilt from source contained in the package. 2) Look through the installed .dlls for any that have the same name as system .dlls or are suspiciously out of place (Package is myDiary and contains mysql.dll, sqlite.dll, and gtk-sharp.dll) 3) Source directories look odd: PKGNAME/ src/ data/ libs/ gtk-sharp/ atk-sharp/ Anything else? -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 paul at all-the-johnsons.co.uk Tue Jun 13 06:25:34 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 13 Jun 2006 07:25:34 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150154612.5199.282.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> Message-ID: <1150179934.8482.32.camel@T7.Linux> Hi, > 1. Redefining libdir for mono packages: > > If mono and its tools cannot find a library on a 64bit architecture when > it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken > on that architecture, and needs to be fixed. This is a serious flaw, and > I will not have us doing ugly hacks in spec files to work around mono's > ineptitude. Every other core component is able to handle this, this bug > should be filed and fixed. I've moaned about this until I'm blue in the face on the mono-devel lists for almost 8 months now (basically since I moved to 64 bit architecture) and there doesn't seem to be any real desire to do anything. I think the problem has been disguised by how SuSE package mono applications. In their somewhat insane spec files, they define all mono packages as being noarch, which means everything goes into /usr/lib rather than anywhere else. This, to me, is as bad a hack as my libdir one. I have a feeling that the only way it will get fixed is if one of us sits down and fixes the problem. It could possibly be just a quick change to the configure.ac scripts so that /usr/lib is set as libdir in there. Thanks for having a look Tom, much appreciated. Hope the hotel room isn't that bad... TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Tue Jun 13 06:35:08 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 13 Jun 2006 09:35:08 +0300 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150177286.3175.49.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> Message-ID: <1150180509.2743.8.camel@localhost.localdomain> On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote: > Fedora's Python and Perl place arch independent data into /usr/lib, It can be argued that this is a packaging glitch (which is hard to fix in a backwards compatible manner) in both of them. From toshio at tiki-lounge.com Tue Jun 13 07:33:20 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 13 Jun 2006 00:33:20 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150180509.2743.8.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> Message-ID: <1150184000.3175.73.camel@localhost> On Tue, 2006-06-13 at 09:35 +0300, Ville Skytt? wrote: > On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote: > > > Fedora's Python and Perl place arch independent data into /usr/lib, > > It can be argued that this is a packaging glitch (which is hard to fix > in a backwards compatible manner) in both of them. True. But in my response to spot, I'm using these examples to ask if all the arch independent data should be consolidated into one place rather than whether that place is /usr/lib or /usr/share. If you want to bring that point up you can but after thinking about it this weekend I couldn't come up with a truly compelling reason. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Jun 13 07:43:06 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jun 2006 09:43:06 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150180509.2743.8.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> Message-ID: <1150184586.30155.115.camel@mccallum.corsepiu.local> On Tue, 2006-06-13 at 09:35 +0300, Ville Skytt? wrote: > On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote: > > > Fedora's Python and Perl place arch independent data into /usr/lib, > > It can be argued that this is a packaging glitch A different view is: It's generalization and simplification. > (which is hard to fix > in a backwards compatible manner) in both of them. What would it buy you? ... In first place complexity ... Ralf From nicolas.mailhot at laposte.net Tue Jun 13 09:44:15 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 Jun 2006 11:44:15 +0200 (CEST) Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150177286.3175.49.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> Message-ID: <9734.192.54.193.51.1150191855.squirrel@rousalka.dyndns.org> Le Mar 13 juin 2006 07:41, Toshio Kuratomi a ?crit : >> 3. Forcing local copies of DLL libraries instead of using system >> installed DLLs. >> This concept is documented upstream here: >> http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs >> IMHO, this is a really stupid and braindead idea. In fact, I've yet to >> talk to anyone who actually thinks this is a good idea. This is the >> same >> thing as static linking a private copy of a library instead of using >> the >> system shared lib. We do NOT permit this sort of behavior in Fedora, >> and >> mono is no exception. > > Here here! > > What are the easy ways to detect this issue? If upstream bundles dlls they don't even rebuild from sources, you can steal a trick from the java packages and always end up %setup with a blanket rm of DLL files (won't take care of common stuff which *is* rebuilt, but a lot of the times windoze developpers don't bother with this step when they do bundling) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Jun 13 09:46:47 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 Jun 2006 11:46:47 +0200 (CEST) Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150184000.3175.73.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> Message-ID: <20974.192.54.193.52.1150192007.squirrel@rousalka.dyndns.org> Le Mar 13 juin 2006 09:33, Toshio Kuratomi a ?crit : > On Tue, 2006-06-13 at 09:35 +0300, Ville Skytt? wrote: >> On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote: >> >> > Fedora's Python and Perl place arch independent data into /usr/lib, >> >> It can be argued that this is a packaging glitch (which is hard to fix >> in a backwards compatible manner) in both of them. > > True. But in my response to spot, I'm using these examples to ask if > all the arch independent data should be consolidated into one place > rather than whether that place is /usr/lib or /usr/share. Some languages like java DO put arch-indep stuff in /usr/share, so you can't take python and perl as the argument Fedora puts arch-indep stuff in /usr/lib so let's ignore the LSB and mono should too -- Nicolas Mailhot From ville.skytta at iki.fi Tue Jun 13 15:49:16 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 13 Jun 2006 18:49:16 +0300 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150184586.30155.115.camel@mccallum.corsepiu.local> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184586.30155.115.camel@mccallum.corsepiu.local> Message-ID: <1150213756.2743.24.camel@localhost.localdomain> On Tue, 2006-06-13 at 09:43 +0200, Ralf Corsepius wrote: > On Tue, 2006-06-13 at 09:35 +0300, Ville Skytt? wrote: > > On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote: > > > > > Fedora's Python and Perl place arch independent data into /usr/lib, > > > > It can be argued that this is a packaging glitch > A different view is: It's generalization and simplification. YMMV, but the way I read the FHS ("Architecture independent data goes to /usr/share"), this is against it. Ignoring backwards compatibility issues, it would be hardly any more difficult to have them in /usr/share than /usr/lib. > > (which is hard to fix > > in a backwards compatible manner) in both of them. > What would it buy you? ... In first place complexity ... FHS (and thus LSB) compliance, again the way I read it. Whether it's worth the pain of changing is another story, but IMO if there's no historical baggage to take into account (such as possibly in the Mono case there isn't), one should try to follow the standards. From rc040203 at freenet.de Tue Jun 13 16:10:26 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jun 2006 18:10:26 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150213756.2743.24.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184586.30155.115.camel@mccallum.corsepiu.local> <1150213756.2743.24.camel@localhost.localdomain> Message-ID: <1150215027.3042.9.camel@mccallum.corsepiu.local> On Tue, 2006-06-13 at 18:49 +0300, Ville Skytt? wrote: > On Tue, 2006-06-13 at 09:43 +0200, Ralf Corsepius wrote: > > On Tue, 2006-06-13 at 09:35 +0300, Ville Skytt? wrote: > > > On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote: > > > > > > > Fedora's Python and Perl place arch independent data into /usr/lib, > > > > > > It can be argued that this is a packaging glitch > > A different view is: It's generalization and simplification. > > YMMV, but the way I read the FHS ("Architecture independent data goes > to /usr/share"), this is against it. Note: "data". Which kind of data are we talking about? Scripts and arch-independent executables aren't necessarily "data". In my understanding, the FHS is talking about classical "data" files (non-executables), such as "pictures" and the like. Ralf From nicolas.mailhot at laposte.net Tue Jun 13 17:29:33 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 Jun 2006 19:29:33 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150215027.3042.9.camel@mccallum.corsepiu.local> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184586.30155.115.camel@mccallum.corsepiu.local> <1150213756.2743.24.camel@localhost.localdomain> <1150215027.3042.9.camel@mccallum.corsepiu.local> Message-ID: <1150219773.10172.27.camel@rousalka.dyndns.org> Le mardi 13 juin 2006 ? 18:10 +0200, Ralf Corsepius a ?crit : > Which kind of data are we talking about? Scripts and arch-independent > executables aren't necessarily "data". Doesn't mean anything in english, the specific work we have in French for doing computer stuff if often translated as data processing, so the LSB author might just have wanted to write "Architecture independent stuff" elegantly. My personal reading is the authors of the spec wanted stuff which couldn't be nfs-shared between systems with different architectures in /usr/lib, and the rest in /usr/share. In that case the rest does include the dlls. The thing is not LSB vs how Red Hat used to do stuff like some people try to put it, lots of Red Hat packagers have chosen for a long time to put their arch-independant (byte)code in /usr/share : - java bytecode in /usr/share/java - lisp code in /usr/share/(x)emacs - xslt code in /usr/share/sgml/ or /usr/share/xml - php code in /usr/share/webappname (squirelmail for example) - tcl code in /usr/share/tclfoo/ dssl, tex also comes to mind The *vast* majority of noarch/interpreted languages have long chosen /usr/share as home. Perl and python are the exception, probably because they mix native with arch-independant code, and no one ever asked their packagers to clean up their packaging style. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From toshio at tiki-lounge.com Tue Jun 13 17:40:35 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 13 Jun 2006 10:40:35 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150177286.3175.49.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> Message-ID: <1150220435.3330.45.camel@localhost> On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote: > On Mon, 2006-06-12 at 18:23 -0500, Tom 'spot' Callaway wrote: > > 2. Putting DLLs in %{_datadir} vs %{_libdir}: > > > > The FHS says that /usr/share (aka, %{_datadir}) is for "Architecture > > Independent Data". These DLL files do not seem to qualify as > > "Architecture Independent Data". I think that having them live in the: > > %{_libdir}/mono/ hierarchy seems to be the most appropriate for them > > at > > this point in time. Obviously, this can be revisited if upstream > > changes > > the default location. The gacutil command should be putting these DLL > > files in the right place. > > > My understanding is .dlls and .exes are architecture independent. Ugh. Sorry guys, I think my understanding of the architecture independence of .dlls and .exes is mistaken: [1] Miguel posts to the Debian list about problems with their packaging guidelines, including the tidbit that although the current Mono .dlls are compiled to CIL and therefore arch independent, they do not have to be this way:: http://lists.alioth.debian.org/pipermail/pkg-mono-devel/2005-February/000370.html [2] The old, problematic guidelines Miguel is critiquing. Among other things, it contains the assumptions about arch-independence that Miguel says are wrong:: http://wiki.debian.org/?MonoConventions [3] A new Debian roadmap for mono integration written up shortly after one of the Debian developers talked with Miguel via IRC. This is short and succinct with several useful tidbits:: http://wiki.debian.org/?MonoDebianPlan [4] The Debian mono packaging guidelines draft. This is longer and a work in progress. I haven't finished plowing through it but it sounds like Debian has been examining this issue and has started to canonicalize some of their knowledge so it should be good fodder:: http://pkg-mono.alioth.debian.org/cli-policy/ Given this, my questions change to:: * Do the Core mono packages belong in %{_libdir} (ie, /usr/lib64 on x86_64 and /usr/lib on 32bit systems) rather than /usr/lib? - If so, is this a requirement before we can place Extras packages into the proper, %{_libdir}, directories? * Do all mono packages belong under %{_libdir}/mono or should there be more flexibility? How much? (Allow %{_libdir}/[PKGNAME]? Allow %{_datadir}/PKGNAME because upstream should know if their package is truly arch independent?) - If we allow more flexibility (for instance, allowing nant to install to %{_datadir}) how do we check that the .dlls and .exes are truly platform independent? - Related questions I have after reading [3]: Do .dlls and .exes become platform dependent simply by linking to C-language glue libraries? Do we need to consider all mono packages as being platform dependent because of AOT-compile? I tried the mentioned "grep -i dllimport" test here and failed to come up with any matches so I obviously don't fully understand that page. * Once again, putting everything under %{_libdir}/mono would be easiest for doing reviews but it may require us to do a lot of patching to get things into the right directories. FWIW, Debian installs Nant into /usr/lib/mono/ so it appears they have decided patching upstream's install locations is the proper procedure. http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=nant&version=unstable&arch=all -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 ianburrell at gmail.com Tue Jun 13 17:52:08 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Tue, 13 Jun 2006 10:52:08 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150179934.8482.32.camel@T7.Linux> References: <1150154612.5199.282.camel@localhost.localdomain> <1150179934.8482.32.camel@T7.Linux> Message-ID: On 6/12/06, Paul wrote: > Hi, > > > 1. Redefining libdir for mono packages: > > > > If mono and its tools cannot find a library on a 64bit architecture when > > it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken > > on that architecture, and needs to be fixed. This is a serious flaw, and > > I will not have us doing ugly hacks in spec files to work around mono's > > ineptitude. Every other core component is able to handle this, this bug > > should be filed and fixed. > > I've moaned about this until I'm blue in the face on the mono-devel > lists for almost 8 months now (basically since I moved to 64 bit > architecture) and there doesn't seem to be any real desire to do > anything. > > I think the problem has been disguised by how SuSE package mono > applications. In their somewhat insane spec files, they define all mono > packages as being noarch, which means everything goes into /usr/lib > rather than anywhere else. > > This, to me, is as bad a hack as my libdir one. > > I have a feeling that the only way it will get fixed is if one of us > sits down and fixes the problem. It could possibly be just a quick > change to the configure.ac scripts so that /usr/lib is set as libdir in > there. > It sounds like what is needed is another variable which determines where the arch-independent code for mono goes. libdir would have its normal arch-dependent meaning, /usr/lib or /usr/lib64. The new variable, lets call it monodir for example, would always be /usr/lib/mono. There will always be packages which use libdir for installing shared libraries and mono code and using libdir for both purposes will always create problems. - Ian From paul at all-the-johnsons.co.uk Tue Jun 13 21:22:58 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 13 Jun 2006 22:22:58 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150220435.3330.45.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150220435.3330.45.camel@localhost> Message-ID: <1150233778.8482.44.camel@T7.Linux> Hi, > Given this, my questions change to:: > * Do the Core mono packages belong in %{_libdir} (ie, /usr/lib64 on > x86_64 and /usr/lib on 32bit systems) rather than /usr/lib? If I've read the replies so far, yes. > - If so, is this a requirement before we can place Extras packages > into the proper, %{_libdir}, directories? The problem is that for libraries, if something needs to link to it, the .pc file isn't usually found if you've installed to the default 64 bit directory. > * Do all mono packages belong under %{_libdir}/mono or should there be > more flexibility? How much? (Allow %{_libdir}/[PKGNAME]? Allow > %{_datadir}/PKGNAME because upstream should know if their package is > truly arch independent?) should know and do know are not the same. For quite a few packages (such as gtk-sharp), they are already in %{_libdir}/[PKGNAME] > - If we allow more flexibility (for instance, allowing nant to install > to %{_datadir}) how do we check that the .dlls and .exes are truly > platform independent? No idea - I would imagine in the same way as you would check something written in Java. > * Once again, putting everything under %{_libdir}/mono would be easiest > for doing reviews but it may require us to do a lot of patching to get > things into the right directories. It depends if we patch the spec file or the configure files. The spec is much simpler than the configure scripts. > FWIW, Debian installs Nant into /usr/lib/mono/ so it appears they have > decided patching upstream's install locations is the proper procedure. I'd rather we come up with a FC specific solution than rely on two conflicting points of view coming from the SuSE and Debian camps - having used both, I can say that I wouldn't trust either to get things even remotely right. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Tue Jun 13 22:28:18 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 13 Jun 2006 15:28:18 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150233778.8482.44.camel@T7.Linux> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150220435.3330.45.camel@localhost> <1150233778.8482.44.camel@T7.Linux> Message-ID: <1150237698.3330.124.camel@localhost> On Tue, 2006-06-13 at 22:22 +0100, Paul wrote: > Toshio wrote: > > - If so, is this a requirement before we can place Extras packages > > into the proper, %{_libdir}, directories? > > The problem is that for libraries, if something needs to link to it, > the .pc file isn't usually found if you've installed to the default 64 > bit directory. > The .pc file isn't found by what? pkg-config? A configure script? Some other program in the build process? We have to know what's making the mistakes in order to fix it. > > * Do all mono packages belong under %{_libdir}/mono or should there be > > more flexibility? How much? (Allow %{_libdir}/[PKGNAME]? Allow > > %{_datadir}/PKGNAME because upstream should know if their package is > > truly arch independent?) > > should know and do know are not the same. For quite a few packages (such > as gtk-sharp), they are already in %{_libdir}/[PKGNAME] > Do you mean gtk-sharp2? Do you mean it installs a helper app into /usr/lib/[PKGNAME]? I'm being very careful to differentiate between /usr/lib and %{_libdir} because /usr/lib has multiple roles on x86_64 in Fedora Core. (Place for 32bit libraries. Repository for arch independent python and perl libraries.) > > - If we allow more flexibility (for instance, allowing nant to install > > to %{_datadir}) how do we check that the .dlls and .exes are truly > > platform independent? > No idea - I would imagine in the same way as you would check something > written in Java. > Java jars are bytecode. Native code is compiled into a .so. From reading the links I posted earlier, it appears that .dlls and .exes can contain both arch independent and platform specific code. So filename extension is not an indicator. I haven't found any indication that file(1) knows the difference either. -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 paul at all-the-johnsons.co.uk Tue Jun 13 23:27:58 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 14 Jun 2006 00:27:58 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150237698.3330.124.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150220435.3330.45.camel@localhost> <1150233778.8482.44.camel@T7.Linux> <1150237698.3330.124.camel@localhost> Message-ID: <1150241278.8482.54.camel@T7.Linux> Hi, > > > The problem is that for libraries, if something needs to link to it, > > the .pc file isn't usually found if you've installed to the default 64 > > bit directory. > > > The .pc file isn't found by what? pkg-config? A configure script? > Some other program in the build process? We have to know what's making > the mistakes in order to fix it. I'm not actually sure, though I would imagine it's pkg-config. When I run a spec file, it executes the configure script which itself calls pkg-config for the libs. > > > * Do all mono packages belong under %{_libdir}/mono or should there be > > > more flexibility? How much? (Allow %{_libdir}/[PKGNAME]? Allow > > > %{_datadir}/PKGNAME because upstream should know if their package is > > > truly arch independent?) > > > > should know and do know are not the same. For quite a few packages (such > > as gtk-sharp), they are already in %{_libdir}/[PKGNAME] > > > Do you mean gtk-sharp2? Yes. Sorry. It's been a damned long day. > Do you mean it installs a helper app into /usr/lib/[PKGNAME]? It installs gapi2xml.pl, gapi_codegen.exe, gapi_fixup.exe, gapi-parser.exe, gapi_pp.pl and gconfsharp-schemagen.exe > I'm being very careful to differentiate between /usr/lib and %{_libdir} > because /usr/lib has multiple roles on x86_64 in Fedora Core. (Place for > 32bit libraries. Repository for arch independent python and perl > libraries.) Thanks - I knew there was something special about /usr/lib on 64 bit, but never actually what it was! > > > - If we allow more flexibility (for instance, allowing nant to install > > > to %{_datadir}) how do we check that the .dlls and .exes are truly > > > platform independent? > > > No idea - I would imagine in the same way as you would check something > > written in Java. > > > Java jars are bytecode. Native code is compiled into a .so. From > reading the links I posted earlier, it appears that .dlls and .exes can > contain both arch independent and platform specific code. So filename > extension is not an indicator. I haven't found any indication that > file(1) knows the difference either. I'm actually there is a safe way to do it other than having a 64 bit box with everything 64 bit on it and see if the 32 bit binary works. Not a very good idea though - too many false positives. I've looked at monodis, but that won't do the job and can't find anything on google either. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Jun 14 00:25:29 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 13 Jun 2006 19:25:29 -0500 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150177286.3175.49.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> Message-ID: <1150244729.28309.21.camel@localhost.localdomain> On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote: > My understanding is .dlls and .exes are architecture independent. This doesn't sound right to me. That doesn't mean that it isn't right, it just sounds weird. file says that the mono dll files are: MS-DOS executable PE for MS Windows (DLL) (console) Intel 80386 32-bit and file thinks that the mono exe files are: MS-DOS executable PE for MS Windows (console) Intel 80386 32-bit Now, my understanding is that mono uses these DLL files as libraries, the EXE files as binaries. Are they compiled from source, or provided as is for use? If they're not compiled from source, this seems like a violation of Fedora policies (no binary only bits, please). Presuming that they are compiled from source, they should be architecture specific. I did not think that C# was an interpreted language like python/perl... is it more like Java (runtime)? > Should they end up in %{_libdir} or always end up in /usr/lib? Fedora's > Python and Perl place arch independent data into /usr/lib, (I assume so > that they can be noarch) should mono as well? Well, there are several questions there: 1. Are the DLLs and EXEs truly architecture independent? 2. Are the EXEs used like binaries? (They certainly seem to be) 3. How much will these mono apps break if we move the EXE location to %{_bindir}? (In my tests with tomboy, it seems to work fine if i move the EXE to %{_bindir} and edit the /usr/bin/tomboy wrapper script) 4. How much will mono (and its app) go nuts if we move the DLLs to to /usr/share ? 4. How much will upstream (and unpackaged mono apps built from source) go nuts if we move our packaged mono bits out of the fake /usr/lib tree? Let's leave perl and python out of this for the time being and focus on mono, where we have the opportunity to do things "correctly" early on, without several years of baggage and precedence. > All the *-sharp packages > on my system currently follow this convention but beagle, tomboy, and > banshee end up in %{_libdir}. Well, to be more specific, they end up in: %{_libdir}/%{name} > If we separate applications and libraries, how do we determine > which .dlls belong in an application directory and which belong in a > library directory? I'm hoping this is as clear cut as "DLL == library, EXE == binary". > What are the easy ways to detect this issue? Man, I really don't think there are easy ways to detect this. Is a package including a DLL file that exists in another package? > 1) Upstream tarball contains .dlls that were not rebuilt from source > contained in the package. Yeah, thats a huge freaking no-no. That alone should invalidate the package for Fedora inclusion. > 2) Look through the installed .dlls for any that have the same name as > system .dlls or are suspiciously out of place (Package is myDiary and > contains mysql.dll, sqlite.dll, and gtk-sharp.dll) Yeah. It is worth noting that banshee seems to be doing this: /usr/lib/banshee/hal-sharp.dll But I don't see anything else using mono(hal-sharp). > 3) Source directories look odd: > PKGNAME/ > src/ > data/ > libs/ > gtk-sharp/ > atk-sharp/ > > Anything else? Yeah, not that I can think of. Mmmm, this gives a new meaning to DLL hell. Thoughts? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Wed Jun 14 03:15:33 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Jun 2006 05:15:33 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150237698.3330.124.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150220435.3330.45.camel@localhost> <1150233778.8482.44.camel@T7.Linux> <1150237698.3330.124.camel@localhost> Message-ID: <1150254934.3042.30.camel@mccallum.corsepiu.local> On Tue, 2006-06-13 at 15:28 -0700, Toshio Kuratomi wrote: > I'm being very careful to differentiate between /usr/lib and %{_libdir} > because /usr/lib has multiple roles on x86_64 in Fedora Core. (Place for > 32bit libraries. Repository for arch independent python and perl > libraries.) Well, actually you have to distinguish between /usr/lib and the multilib dirs, which actually are /usr/lib/. and /usr/lib/../lib64 Ralf From paul at all-the-johnsons.co.uk Wed Jun 14 07:11:55 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 14 Jun 2006 08:11:55 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150244729.28309.21.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150244729.28309.21.camel@localhost.localdomain> Message-ID: <1150269115.8482.65.camel@T7.Linux> Hi, > Now, my understanding is that mono uses these DLL files as libraries, > the EXE files as binaries. Are they compiled from source, or provided as > is for use? If they're not compiled from source, this seems like a > violation of Fedora policies (no binary only bits, please). From what I've packaged, everything is source built. > Presuming that they are compiled from source, they should be > architecture specific. I did not think that C# was an interpreted > language like python/perl... is it more like Java (runtime)? Yes. > > Should they end up in %{_libdir} or always end up in /usr/lib? Fedora's > > Python and Perl place arch independent data into /usr/lib, (I assume so > > that they can be noarch) should mono as well? > > Well, there are several questions there: > > 1. Are the DLLs and EXEs truly architecture independent? No. I have code which identifies itself as 64 bit and 32 bit. > 2. Are the EXEs used like binaries? (They certainly seem to be) Yes. The are effectively binaries. > 3. How much will these mono apps break if we move the EXE location to > %{_bindir}? (In my tests with tomboy, it seems to work fine if i move > the EXE to %{_bindir} and edit the /usr/bin/tomboy wrapper script) It depends on the app. monodevelop hates being moved. > 4. How much will mono (and its app) go nuts if we move the DLLs to > to /usr/share ? A lot - unless you specify to look somewhere, the likes of MD goes bizerk. > 4. How much will upstream (and unpackaged mono apps built from source) > go nuts if we move our packaged mono bits out of the fake /usr/lib tree? That's less of a problem IMO. I don't see them going loopy over the Debian or Mandriva bods. > > If we separate applications and libraries, how do we determine > > which .dlls belong in an application directory and which belong in a > > library directory? > > I'm hoping this is as clear cut as "DLL == library, EXE == binary". Speaking with some of my mates on the darkside over the last couple of days, they refer to the exe as binaries and dlls as libs. Okay, that could just be for ease of conversation... > > What are the easy ways to detect this issue? > > Man, I really don't think there are easy ways to detect this. Is a > package including a DLL file that exists in another package? Quite probably, yes. > > 1) Upstream tarball contains .dlls that were not rebuilt from source > > contained in the package. > > Yeah, thats a huge freaking no-no. That alone should invalidate the > package for Fedora inclusion. Sometimes though they have to do that to build the binary which then rebuilds the source (sort of chicken and egg) > Mmmm, this gives a new meaning to DLL hell. Thoughts? Welcome to the wonderful world of Microsoft lads. Seriously, this is one of the problems of .NET that people scream about on Win32 platforms and there doesn't seem to be anything that can be done as the code has to work in exactly the same way irrespective of platform (the CIL does the grunt work). Upshot, they have to have the directory structure they have - the app looks in a particular directory to try and find the dll, but there is nothing in the system that says look in the common area. gac is a nice attempt to get around this, but even that is only so far. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Wed Jun 14 07:20:17 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 14 Jun 2006 00:20:17 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150244729.28309.21.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150244729.28309.21.camel@localhost.localdomain> Message-ID: <1150269617.3111.75.camel@localhost> On Tue, 2006-06-13 at 19:25 -0500, Tom 'spot' Callaway wrote: > On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote: > > > My understanding is .dlls and .exes are architecture independent. > > This doesn't sound right to me. That doesn't mean that it isn't right, > it just sounds weird. > If you've gotten to my latest message, you'll see I'm partially wrong about this. > file says that the mono dll files are: > MS-DOS executable PE for MS Windows (DLL) (console) Intel 80386 32-bit > > and file thinks that the mono exe files are: > MS-DOS executable PE for MS Windows (console) Intel 80386 32-bit > I believe that most of those dll and exe's are compiled to CIL (Common Intermediate Language) which is then run by the CLR (in our case, mono) similar to how java bytecode is run on the java runtime. The PE is a container for the CIL vaguely similar to a jar file being a renamed zip. > Now, my understanding is that mono uses these DLL files as libraries, > the EXE files as binaries. Are they compiled from source, or provided as > is for use? If they're not compiled from source, this seems like a > violation of Fedora policies (no binary only bits, please). > In the boo package review there was one revision where the upstream tarball was all precompiled .dlls and .exes. After pointing this out, the packager (Paul Johnson) found the tarball with source and packaged that instead. If it's common for upstream projects to distribute both source and binary versions of their mono packages we'll have to be vigilant about checking the source tarballs really contain sources and not precompiled CIL PEs that install with make install. > Presuming that they are compiled from source, they should be > architecture specific. I did not think that C# was an interpreted > language like python/perl... is it more like Java (runtime)? > It's similar to Java byte code. However, if I'm reading Miguel's post to the Debian list correctly, the PE's can become non-portable if they consume functions from native libraries. I'm unclear whether this is something that happens when the developer writes the code or when it is linked. > > Should they end up in %{_libdir} or always end up in /usr/lib? Fedora's > > Python and Perl place arch independent data into /usr/lib, (I assume so > > that they can be noarch) should mono as well? > > Well, there are several questions there: > > 1. Are the DLLs and EXEs truly architecture independent? At this point, the answer is, they may or may not be and I haven't run across an easy way to check yet. This is one of the reasons Debian has changed their mind about putting them into %{_datadir}. The other reeason is that the .dlls can be precompiled to native code to make startup quicker. It seems that at the time Debian changed away from %{_datadir}, these precompiled libraries had to be placed alongside the .dlls. This would obviously be wrong for %{_datadir}. > 2. Are the EXEs used like binaries? (They certainly seem to be) Yes. But the standard usage seems to be to include a script that is installed to %{_bindir} and invoked the application where it resides with the rest of the code. I know of some python applications (rpmlint) and java applications (azureus) that do the same thing. > 3. How much will these mono apps break if we move the EXE location to > %{_bindir}? (In my tests with tomboy, it seems to work fine if i move > the EXE to %{_bindir} and edit the /usr/bin/tomboy wrapper script) I don't know. It's interesting to note that Debian was placing the EXE's into %{_datadir} and writing a wrapper script to place in %{_bindir} before they started discussing this with Miguel. In that discussion they found that upstream projects were being encouraged to write their own wrappers and put the EXEs into /usr/lib (I don't know if this was %{_libdir} or /usr/lib). Note: I just moved banshee.exe to /var/tmp and changed /usr/bin/banshee to point at it. /usr/bin/banshee fails with an error that it could not find Banshee.Base. Banshee.Base.dll lives in %{_libdir}/banshee/ which is normally where banshee.exe would be. > 4. How much will mono (and its app) go nuts if we move the DLLs to > to /usr/share ? Since it seems there's no good way to tell if a .dll is dependent on the arch or not, I'm withdrawing the idea of moving them to %{_datadir} so this question is now moot. I presently think they should go to %{_libdir} (rather than /usr/lib where Core's mono package currently lives.) > 4. How much will upstream (and unpackaged mono apps built from source) > go nuts if we move our packaged mono bits out of the fake /usr/lib tree? > This mailing list post[1]_ says that PLD has been using %{_libdir} since before 2005 and feels that upstream accepts their position. Debian was using %{_datadir} and Miguel gave them reasons he thought that was wrong. They seem to have changed to using /usr/lib but I'm unclear whether /usr/lib == %{_libdir} or the way we use /usr/lib in Fedora multilib (does Debian have multilib?) [1]_ http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2005-February/015273.html > Let's leave perl and python out of this for the time being and focus on > mono, where we have the opportunity to do things "correctly" early on, > without several years of baggage and precedence. > True. Although we'd still have upstream to shift to a new location. > > All the *-sharp packages > > on my system currently follow this convention but beagle, tomboy, and > > banshee end up in %{_libdir}. > > Well, to be more specific, they end up in: %{_libdir}/%{name} > True. > > > If we separate applications and libraries, how do we determine > > which .dlls belong in an application directory and which belong in a > > library directory? > > I'm hoping this is as clear cut as "DLL == library, EXE == binary". > I think my Banshee experiment shows this is harder than that. My guess is if we separate banshee.exe from the DLLs it's intended to reside in the same directory with, then those DLLs need to be registered with the GAC. If we do that are we placing something that isn't intended to be shared into a shared area? > > What are the easy ways to detect this issue? > > Man, I really don't think there are easy ways to detect this. Is a > package including a DLL file that exists in another package? > > > 1) Upstream tarball contains .dlls that were not rebuilt from source > > contained in the package. > > Yeah, thats a huge freaking no-no. That alone should invalidate the > package for Fedora inclusion. > > > 2) Look through the installed .dlls for any that have the same name as > > system .dlls or are suspiciously out of place (Package is myDiary and > > contains mysql.dll, sqlite.dll, and gtk-sharp.dll) > > Yeah. It is worth noting that banshee seems to be doing this: > > /usr/lib/banshee/hal-sharp.dll > > But I don't see anything else using mono(hal-sharp). > > > 3) Source directories look odd: > > PKGNAME/ > > src/ > > data/ > > libs/ > > gtk-sharp/ > > atk-sharp/ > > > > Anything else? > > Yeah, not that I can think of. > > Mmmm, this gives a new meaning to DLL hell. Thoughts? Give me back my Linux :-) My current gut feeling is that all EXE and DLLs belong in %{_libdir} rather than /usr/lib. DLLs that are meant to be used only as part of a single package belong with the EXE. The EXE + DLLs go in %{_libdir}/[PKGNAME]. Other DLLs (I'm assuming all other dlls are meant to be used publically) belong in %{_libdir}/mono/ as part of the GAC. This seems reviewable and hopefully does not require too much work to make upstream packages conform. Reviewing packages for suspect DLLs is going to be hard. Eventually we might be able to compile a list of known dlls that we have on the system and so shouldn't be included in a package but it's going to be an uphill battle as new libraries (and new versions of libraries) are created. Convincing the mono-project that their recommendation has security implications and they should consider withdrawing it may help. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Jun 14 08:05:01 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Jun 2006 10:05:01 +0200 (CEST) Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150269617.3111.75.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150244729.28309.21.camel@localhost.localdomain> <1150269617.3111.75.camel@localhost> Message-ID: <2662.192.54.193.51.1150272301.squirrel@rousalka.dyndns.org> Le Mer 14 juin 2006 09:20, Toshio Kuratomi a ?crit : > In the boo package review there was one revision where the upstream > tarball was all precompiled .dlls and .exes. After pointing this out, > the packager (Paul Johnson) found the tarball with source and packaged > that instead. If it's common for upstream projects to distribute both > source and binary versions of their mono packages we'll have to be > vigilant about checking the source tarballs really contain sources and > not precompiled CIL PEs that install with make install. I believe that since .Net cloned a big part of Java, Java and Mono target the same kind of windows developper with no rpm of FHS background, both mono and java upstreams are pretty close WRT the packaging problems they cause. If the java and mono Red Hat / Fedora packagers are not religious about the langage bit, they may find more than worth their time cooperating on common packaging solutions -- Nicolas Mailhot From paul at all-the-johnsons.co.uk Wed Jun 14 08:38:44 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Wed, 14 Jun 2006 09:38:44 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150269617.3111.75.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150244729.28309.21.camel@localhost.localdomain> <1150269617.3111.75.camel@localhost> Message-ID: <1150274324.2678.0.camel@mrwibble.mrwobble> Hi, > In the boo package review there was one revision where the upstream > tarball was all precompiled .dlls and .exes. After pointing this out, > the packager (Paul Johnson) found the tarball with source and packaged > that instead. If it's common for upstream projects to distribute both > source and binary versions of their mono packages we'll have to be > vigilant about checking the source tarballs really contain sources and > not precompiled CIL PEs that install with make install. The boo packagers made a boo-boo with 0.7.6-2334 which was fixed in 2337 and that mistake was they didn't include the source. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From paul at all-the-johnsons.co.uk Wed Jun 14 18:43:26 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 14 Jun 2006 19:43:26 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150184000.3175.73.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> Message-ID: <1150310606.10582.3.camel@T7.Linux> Hi, I've asked about the architecture agnostisism on the mono-developers list and had this back 8--> On Wed, 2006-06-14 at 09:49 +0100, PFJ wrote: > Is there any sure fire way to detect if either a dll or binary compiled > with mono is platform agnostic or platform specific? It all depends on what your definition of "platform agnostic" and "platform specific" is. :-) The best example of a "platform specific" assembly would be a "mixed mode" assembly, in which actual x86/AMD64/Itanium/etc. code is placed into the assembly along with the platform agnostic CIL code. However, only .NET tools can create such mixed mode assemblies, and Mono doesn't support their execution on any platform, so they're currently not a concern (and likely won't ever be, for a variety of reasons). Consequently, any assembly of consequence executing under Mono will contain *only* platform agnostic CIL code. The only thing left to determine whether an assembly is platform specific is the use of Platform Invoke (P/Invoke), and this is _not_ trivial, as "portable" P/Invoke code can be written, but platform-specific platform code can also be written. Classic example: `struct stat' in C#: public struct stat { public ulong st_dev, st_ino; public uint st_mode; private uint _padding_; public ulong st_nlink, st_uid, st_gid, st_rdev; public long st_size, st_blksize, st_blocks, st_atime, st_mtime, st_ctime; } Question: is that structure definition portable for use with fstat(2)? Answer: Maybe. :-) It should work on 64-bit ABIs (since long/ulong are 64-bit integer types), but it will fail badly on 32-bit ABIs, and it will fail on any ABI in which the member ordering differs. Consequently, such a structure would be platform specific if used with a DllImport statement, but there is NO EASY WAY for a program to make this determination. :-/ (Plus, it can get more complicated, particularly if such a structure is instead used with some native library which will accept that structure, such as Mono.Posix.dll & libMonoPosixHelper.so, which uses a 64-bit ABI throughout, and libMonoPosixHelper.so converts this to a 32-bit ABI as appropriate.) So it's easiest to assume that all CIL code is platform agnostic. > There is currently a debate about this on the fedora-packagers list, but > as yet, no one is able to determine a simple way to see where things > need to go (in respects to agnostic going in /usr/share and platform > specific in /usr/lib or /usr/lib64). As FC has only recently taken mono > as part of it's core distro, the packagers (me included) want to get > this right from the outset. I would suggest looking at what SuSE and Debian/Ubuntu have done with this, as they have all encountered these issues. Following in their footsteps would help consistency, and make it easier to repackage existing programs. I believe that they currently use /usr/lib for everything. However, this gets considerably more complicated, as applications may bundle native libraries with them -- take Blam! and F-Spot as examples: $ ls /usr/lib/f-spot FlickrNet.dll libfspoteog.so.0.0.0 libfspot.so.0 f-spot.exe libfspotjpegtran.so libfspot.so.0.0.0 f-spot.exe.config libfspotjpegtran.so.0 libgphoto2-sharp.dll libfspoteog.so libfspotjpegtran.so.0.0.0 libgphoto2-sharp.dll.config libfspoteog.so.0 libfspot.so SemWeb.dll The *.dll and *.exe files may be platform agnostic, but the *.so* files certainly are NOT. So the easiest solution may be to check to see if any native libraries are bundled with the app, and if that's the case stick it under the appropriate /usr/lib or /usr/lib64 directory. Otherwise, stick with /usr/lib. <--8 It doesn't exactly help, but does confirm that really, %_libdir should be getting used. I do find it odd though that they suggest looking at Debian and SuSE as they both do things differently (out of the two, I think I'd go with the SuSE system rather than the Debian one) TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Jun 14 19:56:19 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 14 Jun 2006 14:56:19 -0500 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150310606.10582.3.camel@T7.Linux> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> Message-ID: <1150314980.30379.73.camel@localhost.localdomain> On Wed, 2006-06-14 at 19:43 +0100, Paul wrote: > > The *.dll and *.exe files may be platform agnostic, but the *.so* > files > certainly are NOT. > > So the easiest solution may be to check to see if any native libraries > are bundled with the app, and if that's the case stick it under the > appropriate /usr/lib or /usr/lib64 directory. Otherwise, stick > with /usr/lib. In the attempt to make the hurting stop, I propose that we do the following: If the mono package includes .so files, it should use %{_libdir}/%{name}. If the mono package does not include .so files, it should be BuildArch: noarch and use /usr/lib. EXE files should have a symlink to %{_bindir}. Mono apps should NOT ship local copies of existant system DLLs without a really really good reason. I don't like it, but I think its easier to just draw the line there than try to rework an entire language. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nicolas.mailhot at laposte.net Wed Jun 14 20:17:33 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Jun 2006 22:17:33 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150314980.30379.73.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> Message-ID: <1150316254.9863.0.camel@rousalka.dyndns.org> Le mercredi 14 juin 2006 ? 14:56 -0500, Tom 'spot' Callaway a ?crit : > If the mono package does not include .so files, it should be BuildArch: > noarch and use /usr/lib. Why on earth do you want it in /usr/lib if you know it's arch-independant ? -- 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 tcallawa at redhat.com Wed Jun 14 20:34:48 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 14 Jun 2006 15:34:48 -0500 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150316254.9863.0.camel@rousalka.dyndns.org> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> Message-ID: <1150317288.30379.76.camel@localhost.localdomain> On Wed, 2006-06-14 at 22:17 +0200, Nicolas Mailhot wrote: > Le mercredi 14 juin 2006 ? 14:56 -0500, Tom 'spot' Callaway a ?crit : > > > If the mono package does not include .so files, it should be BuildArch: > > noarch and use /usr/lib. > > Why on earth do you want it in /usr/lib if you know it's > arch-independant ? Because they're still libraries, in a weird perverted Windowsy way? It might be worth examining exactly what Debian/Ubuntu/SuSE do here. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From nicolas.mailhot at laposte.net Wed Jun 14 20:44:21 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Jun 2006 22:44:21 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150317288.30379.76.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> Message-ID: <1150317861.9863.9.camel@rousalka.dyndns.org> Le mercredi 14 juin 2006 ? 15:34 -0500, Tom 'spot' Callaway a ?crit : > On Wed, 2006-06-14 at 22:17 +0200, Nicolas Mailhot wrote: > > Le mercredi 14 juin 2006 ? 14:56 -0500, Tom 'spot' Callaway a ?crit : > > > > > If the mono package does not include .so files, it should be BuildArch: > > > noarch and use /usr/lib. > > > > Why on earth do you want it in /usr/lib if you know it's > > arch-independant ? > > Because they're still libraries, in a weird perverted Windowsy way? So what ? Are their any less libraries than jar files ? lisp packages ? All those end up in /usr/share in Fedora now, as the FHS demands The "it's code, therefore it shouldn't go in /usr/share" argument is bogus. We have a ton of code in /usr/share, both shared and app-specific -- 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 paul at all-the-johnsons.co.uk Wed Jun 14 20:48:03 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 14 Jun 2006 21:48:03 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150317288.30379.76.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> Message-ID: <1150318083.10582.7.camel@T7.Linux> Hi, > It might be worth examining exactly what Debian/Ubuntu/SuSE do here. SuSE declares everything to be noarch - doesn't matter what it is. This really screws everything up. Debian/Ubuntu have an awful mess to contend with. Let's have something that works. I agree with what you've suggested Tom. I'll get on and check that my packages are not including .so files. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- 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 paul at all-the-johnsons.co.uk Wed Jun 14 21:06:13 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 14 Jun 2006 22:06:13 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150318083.10582.7.camel@T7.Linux> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150318083.10582.7.camel@T7.Linux> Message-ID: <1150319173.10582.28.camel@T7.Linux> Hi, > > It might be worth examining exactly what Debian/Ubuntu/SuSE do here. > > SuSE declares everything to be noarch - doesn't matter what it is. This > really screws everything up. > > Debian/Ubuntu have an awful mess to contend with. Let's have something > that works. I agree with what you've suggested Tom. I'll get on and > check that my packages are not including .so files. Problem : the configure script generates the .pc file as well as finding the bits required from pre-installed packages. Having noarch in the BuildArch there causes the configure script to moan and die. It also runs the automake things to generate the makefiles. This could be a problem Huston.... TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Jun 14 21:17:05 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 14 Jun 2006 16:17:05 -0500 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150319173.10582.28.camel@T7.Linux> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150318083.10582.7.camel@T7.Linux> <1150319173.10582.28.camel@T7.Linux> Message-ID: <1150319825.30379.79.camel@localhost.localdomain> On Wed, 2006-06-14 at 22:06 +0100, Paul wrote: > Hi, > > > > It might be worth examining exactly what Debian/Ubuntu/SuSE do here. > > > > SuSE declares everything to be noarch - doesn't matter what it is. This > > really screws everything up. > > > > Debian/Ubuntu have an awful mess to contend with. Let's have something > > that works. I agree with what you've suggested Tom. I'll get on and > > check that my packages are not including .so files. > > Problem : the configure script generates the .pc file as well as finding > the bits required from pre-installed packages. Having noarch in the > BuildArch there causes the configure script to moan and die. It also > runs the automake things to generate the makefiles. How exactly is this dying? Is it dying because of something that the % configure macro is passing? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From smooge at gmail.com Wed Jun 14 21:18:01 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 14 Jun 2006 15:18:01 -0600 Subject: [Fedora-packaging] Proposal: Standardized License tags Message-ID: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> As of this morning, the Fedora Core and Extras repositories have 2884 src.rpm packages in them. Going through them, there are 191 different licenses listed.. many of them variants of the same name (and sometimes a mis-spelling). Some of the names are useful, and others are odd: libselinux -- License: Public domain (uncopyrighted) or cmucl -- License: Public Domain/MIT needs an explanation on the mailling lists every now and then. [Like can you license public domain stuff? Some license tags give the version of the license.. others also add in where the person can get a definitive copy of the license. I would like to start a discussion on having a list of licenses names to be put in these tags to make it easier for people to keep track of what is installed on a system. Something like GNU GPL version 2 or higher [see /usr/share/fedora-licenses/GPL_v2] GNU LGPL version 2 or higher [see /usr/share/fedora-license/LGPL_v2] GNU GPL version 2 ONLY [see /usr/share/fedora-licenses/GPL_v2] Mozilla Public License (MPL) version 2.0 [see /usr/share/fedora-licenses/MPL_2.0] etc. in the cases of BSD-like/BSD-ish/etc you would refer to the packages license.. but would use the same syntax. it would also help to have something more clear on the packages listed as Distributable (all ~100 of them).. having to figure out the restrictions on each one is a pain. -- Stephen J Smoogen. CSIRT/Linux System Administrator From tcallawa at redhat.com Wed Jun 14 21:20:41 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 14 Jun 2006 16:20:41 -0500 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150317861.9863.9.camel@rousalka.dyndns.org> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150317861.9863.9.camel@rousalka.dyndns.org> Message-ID: <1150320041.30379.84.camel@localhost.localdomain> On Wed, 2006-06-14 at 22:44 +0200, Nicolas Mailhot wrote: > Le mercredi 14 juin 2006 ? 15:34 -0500, Tom 'spot' Callaway a ?crit : > > On Wed, 2006-06-14 at 22:17 +0200, Nicolas Mailhot wrote: > > > Le mercredi 14 juin 2006 ? 14:56 -0500, Tom 'spot' Callaway a ?crit : > > > > > > > If the mono package does not include .so files, it should be BuildArch: > > > > noarch and use /usr/lib. > > > > > > Why on earth do you want it in /usr/lib if you know it's > > > arch-independant ? > > > > Because they're still libraries, in a weird perverted Windowsy way? > > So what ? > Are their any less libraries than jar files ? lisp packages ? > > All those end up in /usr/share in Fedora now, as the FHS demands > > The "it's code, therefore it shouldn't go in /usr/share" argument is > bogus. We have a ton of code in /usr/share, both shared and app-specific OK, so if we put everything in %{_datadir}/%{name}, the following questions arise: 1. Does this work? Or do the apps stop working? 2. Can we still put the .so files in %{_libdir}/%{name}, symlink them back to %{_datadir}/%{name}? Does this work? Or do the apps stop working? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From michael at knox.net.nz Wed Jun 14 21:23:15 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 15 Jun 2006 09:23:15 +1200 Subject: [Fedora-packaging] Proposal: Standardized License tags In-Reply-To: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> References: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> Message-ID: <44907E43.7090700@knox.net.nz> Stephen John Smoogen wrote: > As of this morning, the Fedora Core and Extras repositories have 2884 > src.rpm packages in them. Going through them, there are 191 different > licenses listed.. many of them variants of the same name (and > sometimes a mis-spelling). Some of the names are useful, and others > are odd: > > libselinux -- License: Public domain (uncopyrighted) > > or > > cmucl -- License: Public Domain/MIT > > needs an explanation on the mailling lists every now and then. [Like > can you license public domain stuff? > > Some license tags give the version of the license.. others also add in > where the person can get a definitive copy of the license. I would > like to start a discussion on having a list of licenses names to be > put in these tags to make it easier for people to keep track of what > is installed on a system. > > Something like > > GNU GPL version 2 or higher [see /usr/share/fedora-licenses/GPL_v2] > GNU LGPL version 2 or higher [see /usr/share/fedora-license/LGPL_v2] > GNU GPL version 2 ONLY [see /usr/share/fedora-licenses/GPL_v2] > Mozilla Public License (MPL) version 2.0 [see > /usr/share/fedora-licenses/MPL_2.0] > > etc. > > in the cases of BSD-like/BSD-ish/etc you would refer to the packages > license.. but would use the same syntax. > > it would also help to have something more clear on the packages listed > as Distributable (all ~100 of them).. having to figure out the > restrictions on each one is a pain. > Hi, these are the "valid" licenses as per rpmlint's config found in /usr/share/rpmlint/config: Apache Software License Artistic BSD Commercial CPL Distributable FDL Freeware GPL IBM Public License LaTeX Project Public License LGPL MIT MPL NetHack General Public License Non-distributable Public Domain Python Software Foundation License QPL Ruby License Sun Public License SIL Open Font License W3C Software License zlib License I don't think this list is "authoritive" however, FE packages are meant to pass rpmlint checks before inclusion. Also after reviewing these, looks as if rpmlint's list should be trimmed to remove unacceptable licenses like "Commercial" and "freeware" Michael From tcallawa at redhat.com Wed Jun 14 21:25:00 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 14 Jun 2006 16:25:00 -0500 Subject: [Fedora-packaging] Proposal: Standardized License tags In-Reply-To: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> References: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> Message-ID: <1150320300.30379.90.camel@localhost.localdomain> On Wed, 2006-06-14 at 15:18 -0600, Stephen John Smoogen wrote: > As of this morning, the Fedora Core and Extras repositories have 2884 > src.rpm packages in them. Going through them, there are 191 different > licenses listed.. many of them variants of the same name (and > sometimes a mis-spelling). Some of the names are useful, and others > are odd: > > libselinux -- License: Public domain (uncopyrighted) Isn't this due to unique restrictions around NSA generated source code? > Something like > > GNU GPL version 2 or higher [see /usr/share/fedora-licenses/GPL_v2] > GNU LGPL version 2 or higher [see /usr/share/fedora-license/LGPL_v2] > GNU GPL version 2 ONLY [see /usr/share/fedora-licenses/GPL_v2] > Mozilla Public License (MPL) version 2.0 [see > /usr/share/fedora-licenses/MPL_2.0] Do we really need to overload this License field with all that? I'd prefer: GPL version 2 or higher LGPL version 2 or higher GPL version 2 MPL version 2.0 Where the syntax is: $LICENSE_SHORT_NAME version $LICENSE_VERSION or higher > it would also help to have something more clear on the packages listed > as Distributable (all ~100 of them).. having to figure out the > restrictions on each one is a pain. Yeah, we should audit the "Distributable" packages. Got a list of those? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From paul at all-the-johnsons.co.uk Wed Jun 14 21:22:42 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 14 Jun 2006 22:22:42 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150319825.30379.79.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150318083.10582.7.camel@T7.Linux> <1150319173.10582.28.camel@T7.Linux> <1150319825.30379.79.camel@localhost.localdomain> Message-ID: <1150320163.10582.32.camel@T7.Linux> Hi, > > Problem : the configure script generates the .pc file as well as finding > > the bits required from pre-installed packages. Having noarch in the > > BuildArch there causes the configure script to moan and die. It also > > runs the automake things to generate the makefiles. > > How exactly is this dying? Is it dying because of something that the % > configure macro is passing? checking build system type... i686-redhat-linux-gnu checking host system type... i686-redhat-linux-gnu checking target system type... Invalid configuration `noarch-redhat-linux-gnu': machine `noarch-redhat' not recognised It looks like it doesn't like the target. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Jun 14 21:31:24 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Jun 2006 23:31:24 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150320041.30379.84.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150317861.9863.9.camel@rousalka.dyndns.org> <1150320041.30379.84.camel@localhost.localdomain> Message-ID: <1150320684.9863.15.camel@rousalka.dyndns.org> Le mercredi 14 juin 2006 ? 16:20 -0500, Tom 'spot' Callaway a ?crit : > On Wed, 2006-06-14 at 22:44 +0200, Nicolas Mailhot wrote: > > Le mercredi 14 juin 2006 ? 15:34 -0500, Tom 'spot' Callaway a ?crit : > > > On Wed, 2006-06-14 at 22:17 +0200, Nicolas Mailhot wrote: > > > > Le mercredi 14 juin 2006 ? 14:56 -0500, Tom 'spot' Callaway a ?crit : > > > > > > > > > If the mono package does not include .so files, it should be BuildArch: > > > > > noarch and use /usr/lib. > > > > > > > > Why on earth do you want it in /usr/lib if you know it's > > > > arch-independant ? > > > > > > Because they're still libraries, in a weird perverted Windowsy way? > > > > So what ? > > Are their any less libraries than jar files ? lisp packages ? > > > > All those end up in /usr/share in Fedora now, as the FHS demands > > > > The "it's code, therefore it shouldn't go in /usr/share" argument is > > bogus. We have a ton of code in /usr/share, both shared and app-specific > > OK, so if we put everything in %{_datadir}/%{name}, the following > questions arise: 1. You probably want to create a %{_datadir}/mono or %{_datadir}/c# root 2. if the mono stack is too dumb to work if the .dll and .so are not in the same dir, you should symlink the dlls to %{_libdir} since it's difficult to create a symlink pointing both to /usr/lib and /usr/lib64 on a x86_64 system > 1. Does this work? Or do the apps stop working? > 2. Can we still put the .so files in %{_libdir}/%{name}, symlink them > back to %{_datadir}/%{name}? Does this work? Or do the apps stop > working? You know after reading this thread I fear the apps will stop working whatever way we choose, and we won't avoid fixing mono to work with our chosen policy. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at all-the-johnsons.co.uk Wed Jun 14 21:27:15 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 14 Jun 2006 22:27:15 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150320041.30379.84.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150317861.9863.9.camel@rousalka.dyndns.org> <1150320041.30379.84.camel@localhost.localdomain> Message-ID: <1150320435.10582.35.camel@T7.Linux> Hi, > > The "it's code, therefore it shouldn't go in /usr/share" argument is > > bogus. We have a ton of code in /usr/share, both shared and app-specific > > OK, so if we put everything in %{_datadir}/%{name}, the following > questions arise: > > 1. Does this work? Or do the apps stop working? Quite a few just die. Some don't. Some give you UK weather results (depends on what you're doing). You don't get this if they're in /usr/lib > 2. Can we still put the .so files in %{_libdir}/%{name}, symlink them > back to %{_datadir}/%{name}? Does this work? Or do the apps stop > working? See above. Mono is *very* picky on where things go. See my other posting on the Windows style that has to be adopted for Mono to work on different platforms. TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Jun 14 21:41:33 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Jun 2006 23:41:33 +0200 Subject: [Fedora-packaging] Proposal: Standardized License tags In-Reply-To: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> References: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> Message-ID: <1150321293.9863.25.camel@rousalka.dyndns.org> Le mercredi 14 juin 2006 ? 15:18 -0600, Stephen John Smoogen a ?crit : > Something like > > GNU GPL version 2 or higher [see /usr/share/fedora-licenses/GPL_v2] > GNU LGPL version 2 or higher [see /usr/share/fedora-license/LGPL_v2] > GNU GPL version 2 ONLY [see /usr/share/fedora-licenses/GPL_v2] > Mozilla Public License (MPL) version 2.0 [see > /usr/share/fedora-licenses/MPL_2.0] I think Mandriva packages common licenses in separate packages, and have packages which use those licenses depend on those packages. But last time this was brought on the table people felt this was dangerous legally and each package should have its own license payload. Now what hasn't been tried yet is to have this payload install in standard places, which if my understanding of rpm is correct will work, as long as each GPL version 2 package (for example) uses the same file with no indenting changes And come to think of it, if rpm barfs because two files install the same license text, but the md5sum of the license files differ, well there is some risk one of the projects is not using the original license anymore, but some "improved" (and probably no longer OSI-compliant) version. However since some licensing templates put the author/project name in the license text, all licenses may not fit in this scheme. Gwaaaa, why do you put this on the table, head is hurting, need to go to sleep ;) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From smooge at gmail.com Wed Jun 14 21:46:35 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 14 Jun 2006 15:46:35 -0600 Subject: [Fedora-packaging] Proposal: Standardized License tags In-Reply-To: <1150320300.30379.90.camel@localhost.localdomain> References: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> <1150320300.30379.90.camel@localhost.localdomain> Message-ID: <80d7e4090606141446h2f3d439dg3d1dbfbf1c949144@mail.gmail.com> On 6/14/06, Tom 'spot' Callaway wrote: > On Wed, 2006-06-14 at 15:18 -0600, Stephen John Smoogen wrote: > > As of this morning, the Fedora Core and Extras repositories have 2884 > > src.rpm packages in them. Going through them, there are 191 different > > licenses listed.. many of them variants of the same name (and > > sometimes a mis-spelling). Some of the names are useful, and others > > are odd: > > > > libselinux -- License: Public domain (uncopyrighted) > > Isn't this due to unique restrictions around NSA generated source code? > Yes. I think it comes under a special exemption for certain US Government written code.. BUT I am not sure. > > Something like > > > > GNU GPL version 2 or higher [see /usr/share/fedora-licenses/GPL_v2] > > GNU LGPL version 2 or higher [see /usr/share/fedora-license/LGPL_v2] > > GNU GPL version 2 ONLY [see /usr/share/fedora-licenses/GPL_v2] > > Mozilla Public License (MPL) version 2.0 [see > > /usr/share/fedora-licenses/MPL_2.0] > > Do we really need to overload this License field with all that? I'd > prefer: No I do not.. I do wish to have a standard place for Licenses to help deal with searching for the LGPL Copying that Firefox should have because it is covered under the MPL and LGPL. I know i have copies of the LGPL elsewhere.. but knowing that it is in one spot would help. > > GPL version 2 or higher > LGPL version 2 or higher > GPL version 2 > MPL version 2.0 > > Where the syntax is: > > $LICENSE_SHORT_NAME version $LICENSE_VERSION or higher > I was wondering about that. Some code has things like GPL v2 ONLY and some has GPL v2 or higher and some just says GPL version 2. > > it would also help to have something more clear on the packages listed > > as Distributable (all ~100 of them).. having to figure out the > > restrictions on each one is a pain. > > Yeah, we should audit the "Distributable" packages. Got a list of those? > Canna -- License: Distributable FreeWnn -- License: Distributable adjtimex -- License: distributable aspell-en -- License: distributable aspell-nl -- License: distributable awesfx -- License: GPL/distributable bin2iso -- License: Distributable (Unknown) bitmap-fonts -- License: distributable bitstream-vera-fonts -- License: Redistributable, with restrictions blacs -- License: Freely distributable bwidget -- License: Distributable cleanfeed -- License: distributable conserver -- License: Distributable cyrus-sasl -- License: Freely Distributable dejavu-fonts -- License: Redistributable, with restrictions dhcp -- License: distributable diffstat -- License: distributable docbook-dtds -- License: Distributable docbook-simple -- License: Distributable docbook-style-dsssl -- License: Distributable docbook-style-xsl -- License: Distributable dos2unix -- License: Freely distributable epic -- License: Distributable erlang-esdl -- License: Distributable eruby -- License: distributable file -- License: distributable fonts-ISO8859-2 -- License: Freely distributable fonts-KOI8-R -- License: distributable fonts-japanese -- License: Distributable fonts-korean -- License: Distributable freeze -- License: Distributable gnuplot -- License: Redistributable, with restrictions h2ps -- License: Distributable hunky-fonts -- License: Redistributable, with restrictions jadetex -- License: Distributable jam -- License: Distributable jlint -- License: Distributable kinput2 -- License: Distributable kon2 -- License: distributable krb5 -- License: MIT, freely distributable. krbafs -- License: Freely Distributable lapack -- License: Freely distributable libjpeg -- License: distributable libtabe -- License: Redistributable libtiff -- License: distributable linuxdoc-tools -- License: Freely distributable lv -- License: distributable macutils -- License: Distributable man-pages -- License: distributable man-pages-cs -- License: Distributable man-pages-da -- License: Distributable man-pages-de -- License: Distributable man-pages-es -- License: Distributable man-pages-fr -- License: Distributable man-pages-it -- License: Distributable man-pages-ja -- License: Distributable man-pages-pl -- License: Distributable man-pages-ru -- License: Distributable mathml-fonts -- License: Distributable mgopen-fonts -- License: Redistributable, with restrictions mod_auth_pam -- License: Distributable ncftp -- License: Distributable ncompress -- License: distributable ncurses -- License: distributable nhpf -- License: Distributable ntp -- License: distributable openjade -- License: Distributable opensp -- License: Distributable paraview -- License: Distributable perl-Crypt-Blowfish -- License: Distributable perl-File-MMagic -- License: Distributable perl-Mail-Sender -- License: Distributable perl-Mail-Sendmail -- License: Distributable perl-TermReadKey -- License: Distributable perl-Time-modules -- License: Distributable ppp -- License: distributable psutils -- License: distributable pvm -- License: freely distributable python-imaging -- License: Distributable python-numarray -- License: Distributable qhull -- License: Distributable ruby-mysql -- License: Distributable scalapack -- License: Freely distributable symlinks -- License: distributable t1utils -- License: Distributable tcp_wrappers -- License: Distributable tcsh -- License: distributable tetex -- License: distributable tetex-font-kerkis -- License: Distributable tin -- License: Distributable torque -- License: Freely redistributable (See PBS_License.txt) transfig -- License: distributable ttf2pt1 -- License: Distributable udunits -- License: Freely distributable (BSD-like) ufsparse -- License: Distributable unix2dos -- License: distributable uqm-content -- License: Distributable util-linux -- License: distributable vixie-cron -- License: distributable wings -- License: Distributable xinetd -- License: Distributable (BSD-like) zasx -- License: GPL and freely distributable content zip -- License: distributable zoo -- License: Distributable > ~spot > -- > Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 > Fedora Extras Steering Committee Member (RPM Standards and Practices) > Aurora Linux Project Leader: http://auroralinux.org > Lemurs, llamas, and sparcs, oh my! > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- Stephen J Smoogen. CSIRT/Linux System Administrator From paul at all-the-johnsons.co.uk Wed Jun 14 21:43:49 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 14 Jun 2006 22:43:49 +0100 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150320684.9863.15.camel@rousalka.dyndns.org> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150317861.9863.9.camel@rousalka.dyndns.org> <1150320041.30379.84.camel@localhost.localdomain> <1150320684.9863.15.camel@rousalka.dyndns.org> Message-ID: <1150321430.10582.38.camel@T7.Linux> Hi, > You know after reading this thread I fear the apps will stop working > whatever way we choose, and we won't avoid fixing mono to work with our > chosen policy. If we don't change where the mono installer wants to put things (other than /usr/lib for shared libs), then everything works out the box. Unless it relies on gtk-2.9 and then it dies horribly (look what happens if you use monodevelop [either my rpm or from SVN] and try to create a new project!) TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- 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 ianburrell at gmail.com Wed Jun 14 22:33:14 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Wed, 14 Jun 2006 15:33:14 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150317861.9863.9.camel@rousalka.dyndns.org> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150317861.9863.9.camel@rousalka.dyndns.org> Message-ID: On 6/14/06, Nicolas Mailhot wrote: > Le mercredi 14 juin 2006 ? 15:34 -0500, Tom 'spot' Callaway a ?crit : > > On Wed, 2006-06-14 at 22:17 +0200, Nicolas Mailhot wrote: > > > > > > Why on earth do you want it in /usr/lib if you know it's > > > arch-independant ? > > > > Because they're still libraries, in a weird perverted Windowsy way? > > So what ? > Are their any less libraries than jar files ? lisp packages ? > > All those end up in /usr/share in Fedora now, as the FHS demands > Are they any less libraries than Perl, Ruby, or Python code? Those all end up in /usr/lib. > The "it's code, therefore it shouldn't go in /usr/share" argument is > bogus. We have a ton of code in /usr/share, both shared and app-specific > Those three languages are grandfathered in because they expect to install code and shared libraries in /usr/lib. They now put shared libraries and code that uses them under /usr/lib64 and noarch packages in /usr/lib. Mono is probably in the same boat. It might be possible to put the arch-independent code in /usr/share but it would create compatibility problems with existing packages, other distributions, and the installers expectations. Probably not worth the trouble for LHS purity. - Ian From toshio at tiki-lounge.com Wed Jun 14 22:34:09 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 14 Jun 2006 15:34:09 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150310606.10582.3.camel@T7.Linux> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> Message-ID: <1150324449.3236.38.camel@localhost> On Wed, 2006-06-14 at 19:43 +0100, Paul wrote: > Hi, > > I've asked about the architecture agnostisism on the mono-developers > list and had this back > > 8--> > On Wed, 2006-06-14 at 09:49 +0100, PFJ wrote: > The best example of a "platform specific" assembly would be a "mixed > mode" assembly, in which actual x86/AMD64/Itanium/etc. code is placed > into the assembly along with the platform agnostic CIL code. > > However, only .NET tools can create such mixed mode assemblies, and Mono > doesn't support their execution on any platform, so they're currently > not a concern (and likely won't ever be, for a variety of reasons). > Good. So as long as all source is rebuilt with mono we don't have to worry about this issue. DLLs and EXEs will contain CIL only. > The only thing left to determine whether an assembly is platform > specific is the use of Platform Invoke (P/Invoke), and this is _not_ > trivial, as "portable" P/Invoke code can be written, but > platform-specific platform code can also be written. Classic example: > `struct stat' in C#: > > public struct stat { > public ulong st_dev, st_ino; > public uint st_mode; > private uint _padding_; > public ulong st_nlink, st_uid, st_gid, st_rdev; > public long st_size, st_blksize, st_blocks, st_atime, > st_mtime, st_ctime; > } > > Question: is that structure definition portable for use with fstat(2)? > > Answer: Maybe. :-) It should work on 64-bit ABIs (since long/ulong are > 64-bit integer types), but it will fail badly on 32-bit ABIs, and it > will fail on any ABI in which the member ordering differs. > Consequently, such a structure would be platform specific if used with a > DllImport statement, but there is NO EASY WAY for a program to make this > determination. :-/ > > (Plus, it can get more complicated, particularly if such a structure is > instead used with some native library which will accept that structure, > such as Mono.Posix.dll & libMonoPosixHelper.so, which uses a 64-bit ABI > throughout, and libMonoPosixHelper.so converts this to a 32-bit ABI as > appropriate.) > > So it's easiest to assume that all CIL code is platform agnostic. > I don't see how the OTP came to this conclusion. The example is illustrating that there is no easy way to tell if CIL code is platform specific or platform independent. In the absence of knowing that, we should be assuming the code is platform specific, not platform agnostic as he suggests. > I would suggest looking at what SuSE and Debian/Ubuntu have done with > this, as they have all encountered these issues. Following in their > footsteps would help consistency, and make it easier to repackage > existing programs. > > I believe that they currently use /usr/lib for everything. > AFAIK Debian does not have multilib so our separation of %{_libdir} from /usr/lib does not occur there. I don't know about SuSE. > However, this gets considerably more complicated, as applications may > bundle native libraries with them -- take Blam! and F-Spot as examples: [snip example] > The *.dll and *.exe files may be platform agnostic, but the *.so* files > certainly are NOT. > > So the easiest solution may be to check to see if any native libraries > are bundled with the app, and if that's the case stick it under the > appropriate /usr/lib or /usr/lib64 directory. Otherwise, stick > with /usr/lib. Given that it is difficult to determine whether a .dll contains platform specific or platform agnostic code, I'd argue that everything should go to %{_libdir}. My reading of Debian's switch from %{_datadir} to %{_libdir} implies that they think the same way. BTW: Here's Debian's guidelines. All DLLs they reference goes to their arch specific directory (Remember, they are non-multilib): The package's applications, libraries and meta-data must be installed into /usr/lib/packagename. Libraries that will be installed into the GAC should be installed into /usr/lib/cli/packagename-X.Y (for more details about the X.Y version see GAC versioning). The commonly seen /usr/lib/mono/packagename path should only be used for Mono project packages. Never install native "glue" libraries into /usr/lib, instead install them at /usr/lib/cli/packagename-X.Y. When moving libraries update the references to the new location using a DLL Map. See the Mono DLL maps secion for an example. The only exception here is for native libraries that are of wider use; can be used other packages. Native libraries should be packaged according to the Library Packaging Guide in a Debain Policy conformant way. Never ever install application files (.exe) directly into /usr/bin. Instead create a wrapper script into /usr/bin to allow them to be run without the .exe suffix. http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-file-locations -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 15 03:04:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 14 Jun 2006 22:04:59 -0500 Subject: [Fedora-packaging] Re: Proposal: Standardized License tags In-Reply-To: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> References: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> Message-ID: Stephen John Smoogen wrote: > Some of the names are useful, and others are odd: > cmucl -- License: Public Domain/MIT Origin of that is: http://bugzilla.redhat.com/bugzilla/166796#c13 and http://bugzilla.redhat.com/bugzilla/166796#c14 Please correct me if my interpretation of the license text was erroneous. -- Rex From rc040203 at freenet.de Thu Jun 15 03:48:46 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Jun 2006 05:48:46 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150320163.10582.32.camel@T7.Linux> References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150318083.10582.7.camel@T7.Linux> <1150319173.10582.28.camel@T7.Linux> <1150319825.30379.79.camel@localhost.localdomain> <1150320163.10582.32.camel@T7.Linux> Message-ID: <1150343326.12910.0.camel@mccallum.corsepiu.local> On Wed, 2006-06-14 at 22:22 +0100, Paul wrote: > Hi, > > > > Problem : the configure script generates the .pc file as well as finding > > > the bits required from pre-installed packages. Having noarch in the > > > BuildArch there causes the configure script to moan and die. It also > > > runs the automake things to generate the makefiles. > > > > How exactly is this dying? Is it dying because of something that the % > > configure macro is passing? > > checking build system type... i686-redhat-linux-gnu > checking host system type... i686-redhat-linux-gnu > checking target system type... Invalid configuration > `noarch-redhat-linux-gnu': machine `noarch-redhat' not recognised > > It looks like it doesn't like the target. Please show us the corresponding call to configure. Ralf From ville.skytta at iki.fi Thu Jun 15 06:35:37 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 15 Jun 2006 09:35:37 +0300 Subject: [Fedora-packaging] Proposal: Standardized License tags In-Reply-To: <44907E43.7090700@knox.net.nz> References: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> <44907E43.7090700@knox.net.nz> Message-ID: <1150353337.2743.48.camel@localhost.localdomain> On Thu, 2006-06-15 at 09:23 +1200, Michael J. Knox wrote: > these are the "valid" licenses as per rpmlint's config found in > /usr/share/rpmlint/config: I suggest forgetting about that list, the next version of upstream rpmlint will have an updated list of valid license names synced with http://www.opensource.org/licenses/, see DEFAULT_VALID_LICENSES at http://rpmlint.zarb.org/cgi-bin/trac.cgi/browser/trunk/TagsCheck.py?rev=1164 The FE rpmlint package will revert to using that list by default. From nicolas.mailhot at laposte.net Thu Jun 15 06:36:21 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Jun 2006 08:36:21 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150317861.9863.9.camel@rousalka.dyndns.org> Message-ID: <1150353381.25665.11.camel@rousalka.dyndns.org> Le mercredi 14 juin 2006 ? 15:33 -0700, Ian Burrell a ?crit : > Those three languages are grandfathered in because they expect to > install code and shared libraries in /usr/lib. They now put shared > libraries and code that uses them under /usr/lib64 and noarch packages > in /usr/lib. > > Mono is probably in the same boat. It might be possible to put the > arch-independent code in /usr/share but it would create compatibility > problems with existing packages, other distributions, and the > installers expectations. Probably not worth the trouble for FHS > purity. The other distros do not have consistent practice, mono in Fedora is very new with few packages so far, it *is* the right time to make the right choice before you have enough old baggage so your argument holds sway. Red Hat customers always end up forcing Red Hat to follow 'FHS purity' even if Red Hat doesn't want it?, so if your argument is it's hard now why it'll be harder later and you'll have to do it anyway? (mark my words). lib64 stuff requiring lib stuff (or the reverse) is going to be a terrific can of worms as soon as the 64bit OO.o port completes and people start looking at killing /usr/lib on 64bit systems. multilib and the FHS are both old enough we shouldn't be making such stupid mistakes today. Regards, ? Red Hat didn't like /srv or media it still is slowly migrating to them anyway ? but perl and python are doing it it can't be so bad - did you really miss the threads on python noarch problems some months ago ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 15 06:40:31 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 15 Jun 2006 08:40:31 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150320041.30379.84.camel@localhost.localdomain> (Tom Callaway's message of "Wed, 14 Jun 2006 16:20:41 -0500") References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150317861.9863.9.camel@rousalka.dyndns.org> <1150320041.30379.84.camel@localhost.localdomain> Message-ID: <87y7vyly5c.fsf@kosh.bigo.ensc.de> tcallawa at redhat.com ("Tom 'spot' Callaway") writes: > 2. Can we still put the .so files in %{_libdir}/%{name}, symlink them > back to %{_datadir}/%{name}? Does this work? It will not work, when /usr/share is NFS-shared between an i386 and x86_64 machine. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Jun 15 07:01:14 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Jun 2006 09:01:14 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: References: <1150154612.5199.282.camel@localhost.localdomain> <1150177286.3175.49.camel@localhost> <1150180509.2743.8.camel@localhost.localdomain> <1150184000.3175.73.camel@localhost> <1150310606.10582.3.camel@T7.Linux> <1150314980.30379.73.camel@localhost.localdomain> <1150316254.9863.0.camel@rousalka.dyndns.org> <1150317288.30379.76.camel@localhost.localdomain> <1150317861.9863.9.camel@rousalka.dyndns.org> Message-ID: <1150354874.25665.18.camel@rousalka.dyndns.org> Le mercredi 14 juin 2006 ? 15:33 -0700, Ian Burrell a ?crit : > Probably not worth the trouble for LHS purity. If you don't aim for LHS purity, the FSB secret police will get at you. More seriously you're confusing the LSB as a whole with the FHS it references. LSB is crap nobody expects you to follow it. FHS is fairly good and followed closely my all big distros. Users do expect Fedora to follow it. As previous RHL/FC examples proved, you can duck your head on the sand and say the FHS didn't write some_decision, but some_decision will still be online in the spec users read, and after a few years of harassment by users demanding why you don't apply some_decision you'll have a change of heart and decide applying it is not so painful after all (certainly less than handling all the bug reports / support requests not applying it generates) -- 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 jamatos at fc.up.pt Thu Jun 15 10:20:34 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 15 Jun 2006 11:20:34 +0100 Subject: [Fedora-packaging] Proposal: Standardized License tags In-Reply-To: <80d7e4090606141446h2f3d439dg3d1dbfbf1c949144@mail.gmail.com> References: <80d7e4090606141418y30b13c87ub7ca41de66d03c60@mail.gmail.com> <1150320300.30379.90.camel@localhost.localdomain> <80d7e4090606141446h2f3d439dg3d1dbfbf1c949144@mail.gmail.com> Message-ID: <200606151120.35069.jamatos@fc.up.pt> On Wednesday 14 June 2006 22:46, Stephen John Smoogen wrote: > python-imaging -- License: Distributable -------------------------------------------------------------------- Software License -------------------------------------------------------------------- The Python Imaging Library is Copyright (c) 1997-2005 by Secret Labs AB Copyright (c) 1995-2005 by Fredrik Lundh By obtaining, using, and/or copying this software and/or its associated documentation, you agree that you have read, understood, and will comply with the following terms and conditions: Permission to use, copy, modify, and distribute this software and its associated documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appears in all copies, and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Secret Labs AB or the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. SECRET LABS AB AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL SECRET LABS AB OR THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -------------------------------------------------------------------- I guess that this fits into http://www.opensource.org/licenses/bsd-license.php since it has the no-endorsement clause. OTOH IANAL (a nice use of acronyms ;-). -- Jos? Ab?lio From tibbs at math.uh.edu Fri Jun 16 01:38:08 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 15 Jun 2006 20:38:08 -0500 Subject: [Fedora-packaging] Namespace for cross-compilation tools? Message-ID: I was looking through the old review tickets and saw Ralf's submission of i386-rtems4.7-binutils. I don't believe that's a good name, but I can't really think of what it should be named. binutils-i386-rtems4.7 is one possibility, but then the gcc package would end up as gcc-newlib-i386-rtems4.7 which isn't logically connected to the binutils package. How about a "cross" namespace: cross-target-utility would give us cross-i386-rtems4.7-binutils and cross-i386-rtems4.7-gcc-newlib. - J< From rc040203 at freenet.de Fri Jun 16 03:59:27 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 05:59:27 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: References: Message-ID: <1150430367.12910.12.camel@mccallum.corsepiu.local> On Thu, 2006-06-15 at 20:38 -0500, Jason L Tibbitts III wrote: > I was looking through the old review tickets and saw Ralf's submission > of i386-rtems4.7-binutils. I don't believe that's a good name, Why? This name is the name being used for GNU crosstool toolchains for many years (> a decade). It corresponds to the target canonicalization tuple internally being used by binutils/gcc/gdb, and the autotools. Also using $target as package prefix is convenient when browsing repositories, because all packages will be sorted neighboring in directory listings. > but I > can't really think of what it should be named. binutils-i386-rtems4.7 > is one possibility, but then the gcc package would end up as > gcc-newlib-i386-rtems4.7 which isn't logically connected to the > binutils package. > > How about a "cross" namespace: cross-target-utility would give us > cross-i386-rtems4.7-binutils and cross-i386-rtems4.7-gcc-newlib. >From my view: -{binutils|gcc|gdb|libc|newlib} Prefixing these packages with "cross" to me is meaningless, because it's redundant. Also remember: The applications inside are native (=Linux)applications, it's only that they target "a foreign system". Ralf From tibbs at math.uh.edu Fri Jun 16 04:19:25 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 15 Jun 2006 23:19:25 -0500 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1150430367.12910.12.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 16 Jun 2006 05:59:27 +0200") References: <1150430367.12910.12.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> Why? What is "i386" and why does it have a subpackage of "rtems4.7"? RC> This name is the name being used for GNU crosstool toolchains for RC> many years (> a decade). It corresponds to the target RC> canonicalization tuple internally being used by binutils/gcc/gdb, RC> and the autotools. So? We are free to make decisions for ourselves instead of blindly using someone else's naming convention. If the name is completely confusing (as it is to me) then surely we should talk about it before just stuffing it into the repository. We have no guidelines for this kind of thing, so it warrants discussion. This is the proper list for such discussion, right? RC> Prefixing these packages with "cross" to me is meaningless, RC> because it's redundant. There doesn't seem to be any other part of the package name that would suggest such. - J< From rc040203 at freenet.de Fri Jun 16 04:49:27 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 06:49:27 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: References: <1150430367.12910.12.camel@mccallum.corsepiu.local> Message-ID: <1150433368.12910.31.camel@mccallum.corsepiu.local> On Thu, 2006-06-15 at 23:19 -0500, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> Why? > > What is "i386" and why does it have a subpackage of "rtems4.7"? > > RC> This name is the name being used for GNU crosstool toolchains for > RC> many years (> a decade). It corresponds to the target > RC> canonicalization tuple internally being used by binutils/gcc/gdb, > RC> and the autotools. > > So? Yes. Target canonicalization tuples are standardized (In particular in binutils, GCC and gdb) and shared between *all* projects using config.guess and config.sub (I.e. all package using the autotools). > We are free to make decisions for ourselves instead of blindly > using someone else's naming convention. Yes, it's our freedom to waste time on re- and over engineering parts others have spend decades on. A gcc cross compiler's components are called - You can even find traces of this in Fedora: e.g. /usr/bin/i386-redhat-linux-gcc /usr/bin/i386-redhat-linux-c++ I.e. people will be looking for - > If the name is completely > confusing (as it is to me) then surely we should talk about it before > just stuffing it into the repository. Would packages be called i386-cygwin-gcc or i386-redhat-gcc i586-suse-gcc sparc-sun-solaris2.8-gcc be confusing to you? IMO, they are self-explanatory. Ralf From michael at knox.net.nz Fri Jun 16 05:04:24 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 16 Jun 2006 17:04:24 +1200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1150433368.12910.31.camel@mccallum.corsepiu.local> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> Message-ID: <44923BD8.8050807@knox.net.nz> Ralf Corsepius wrote: > On Thu, 2006-06-15 at 23:19 -0500, Jason L Tibbitts III wrote: >>>>>>> "RC" == Ralf Corsepius writes: >> RC> Why? >> >> What is "i386" and why does it have a subpackage of "rtems4.7"? >> >> RC> This name is the name being used for GNU crosstool toolchains for >> RC> many years (> a decade). It corresponds to the target >> RC> canonicalization tuple internally being used by binutils/gcc/gdb, >> RC> and the autotools. >> >> So? > Yes. Target canonicalization tuples are standardized (In particular in > binutils, GCC and gdb) and shared between *all* projects using > config.guess and config.sub (I.e. all package using the autotools). > >> We are free to make decisions for ourselves instead of blindly >> using someone else's naming convention. > Yes, it's our freedom to waste time on re- and over engineering parts > others have spend decades on. > > A gcc cross compiler's components are called > - > > You can even find traces of this in Fedora: > e.g. > /usr/bin/i386-redhat-linux-gcc > /usr/bin/i386-redhat-linux-c++ > > I.e. people will be looking for - > >> If the name is completely >> confusing (as it is to me) then surely we should talk about it before >> just stuffing it into the repository. > Would packages be called > i386-cygwin-gcc > or > i386-redhat-gcc > i586-suse-gcc > sparc-sun-solaris2.8-gcc > > be confusing to you? > > IMO, they are self-explanatory. Why is the binary target name being used for the package name? That's not intuitive to an end user at all IMHO. I think confusing the binary target name with the actual package name is a mistake. gcc is gcc, not i386-redhat-linux-gcc OpenSUSE uses cross--gcc/binutils/whatever-version debian looks like it uses gcc/binutils/whatever--version Personally I like the cross-prefix, its a lot more obvious to an end user what the package is and is for, but thats just me. Michael From rc040203 at freenet.de Fri Jun 16 06:26:16 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 08:26:16 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <44923BD8.8050807@knox.net.nz> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> Message-ID: <1150439176.12910.61.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 17:04 +1200, Michael J. Knox wrote: > Ralf Corsepius wrote: > > On Thu, 2006-06-15 at 23:19 -0500, Jason L Tibbitts III wrote: > >>>>>>> "RC" == Ralf Corsepius writes: > >> RC> Why? > >> > >> What is "i386" and why does it have a subpackage of "rtems4.7"? > >> > >> RC> This name is the name being used for GNU crosstool toolchains for > >> RC> many years (> a decade). It corresponds to the target > >> RC> canonicalization tuple internally being used by binutils/gcc/gdb, > >> RC> and the autotools. > >> > >> So? > > Yes. Target canonicalization tuples are standardized (In particular in > > binutils, GCC and gdb) and shared between *all* projects using > > config.guess and config.sub (I.e. all package using the autotools). > > > >> We are free to make decisions for ourselves instead of blindly > >> using someone else's naming convention. > > Yes, it's our freedom to waste time on re- and over engineering parts > > others have spend decades on. > > > > A gcc cross compiler's components are called > > - > > > > You can even find traces of this in Fedora: > > e.g. > > /usr/bin/i386-redhat-linux-gcc > > /usr/bin/i386-redhat-linux-c++ > > > > I.e. people will be looking for - > > > >> If the name is completely > >> confusing (as it is to me) then surely we should talk about it before > >> just stuffing it into the repository. > > Would packages be called > > i386-cygwin-gcc > > or > > i386-redhat-gcc > > i586-suse-gcc > > sparc-sun-solaris2.8-gcc > > > > be confusing to you? > > > > IMO, they are self-explanatory. > > Why is the binary target name being used for the package name? That's > not intuitive to an end user at all IMHO. > > I think confusing the binary target name with the actual package name is > a mistake. > > gcc is gcc, not i386-redhat-linux-gcc Wrong. What you have installed is an i386-redhat-linux-gcc rsp. a x86-68-redhat-linux-gcc (more precisely, a GCC having been configured for host=-redhat-linux). As this gcc also is the native gcc, it also is being installed as "gcc", which justifies the package to be called gcc. > OpenSUSE uses cross--gcc/binutils/whatever-version > debian looks like it uses gcc/binutils/whatever--version What is the ? That's the essential part of it. A "cross-i386-gcc" would be complete non-sense, because a cross tool chain depends on the OS and several components more. An i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or a i386-redhat-gcc or a i386-suse-gcc. I presume they are abbreviating and using as a synonym for "-suse-linux". ... Debian ..., their packaging is the worst of all possible choices. It's neither browsable, nor complete nor correct, nor current. Basically looks like rotten packages to me. > Personally I like the cross-prefix, its a lot more obvious to an end > user what the package is and is for, but thats just me. Everybody being used to cross tool chains, knows that the tools insided are called -. Finally a different view on this issue: A GNU cross toolchain consists of several packages which comes in different, multiple incarnations. Packaging-wise, this situation is not any different from packages which can be built against different base infrastructures, say: xorg-mydriver vs. xfree-mydriver gnome-coolguitool vs. kde-coolguitool perl-XXXX perl7-XXXX or (Real world example) Coin2-* vs. Inventor-* Ralf From rc040203 at freenet.de Fri Jun 16 06:35:13 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 08:35:13 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> Message-ID: <1150439713.12910.65.camel@mccallum.corsepiu.local> > ------- Additional Comments From jko at redhat.com 2006-06-15 02:45 EST ------- > ------- Additional Comments From jkeating at redhat.com 2006-06-11 11:04 EST ------- > NEEDSWORK > - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built. Why? I thought, RH was going to use the *same* conventions as Fedora? Apparently not ... Ralf From michael at knox.net.nz Fri Jun 16 07:39:03 2006 From: michael at knox.net.nz (Michael J Knox) Date: Fri, 16 Jun 2006 19:39:03 +1200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1150439176.12910.61.camel@mccallum.corsepiu.local> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> Message-ID: <44926017.20308@knox.net.nz> Ralf Corsepius wrote: >> Why is the binary target name being used for the package name? That's >> not intuitive to an end user at all IMHO. >> >> I think confusing the binary target name with the actual package name is >> a mistake. >> >> gcc is gcc, not i386-redhat-linux-gcc >> > Wrong. What you have installed is an i386-redhat-linux-gcc rsp. a > x86-68-redhat-linux-gcc (more precisely, a GCC having been configured > for host=-redhat-linux). As this gcc also is the native gcc, it > also is being installed as "gcc", which justifies the package to be > called gcc. > Ok fair enough. >> OpenSUSE uses cross--gcc/binutils/whatever-version >> debian looks like it uses gcc/binutils/whatever--version >> > > What is the ? That's the essential part of it. > Its not it was /whatever/ implying insert cross tool here. > A "cross-i386-gcc" would be complete non-sense, because a cross tool > chain depends on the OS and several components more. An > i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or > a i386-redhat-gcc or a i386-suse-gcc. > Again, this is a packaging name, not a binary target. Packaged as cross-arm-gcc for example, tells me straigh way what this package is. However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy binutils? A binutils addon? I also think that having the arch (read i386 not rtems) in the name is not needed. RPM takes care of the arch. 1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm vs 2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm example 1 makes a lot of sense to me and is how I would expect to find the package naming convention. Also, is Fedora ever going to ship a cross compiler for SuSE? I doubt it. A cross compiler for cygwin? I doubt it. > I presume they are abbreviating and using as a synonym for > "-suse-linux". > > ... Debian ..., their packaging is the worst of all possible choices. > It's neither browsable, nor complete nor correct, nor current. > Basically looks like rotten packages to me. > I wont get into debian packaging, as I have the joy of looking after several user space packages and a kernel package for work, but its not all bad >> Personally I like the cross-prefix, its a lot more obvious to an end >> user what the package is and is for, but thats just me. >> > > Everybody being used to cross tool chains, knows that the tools insided > are called -. > > Aye.. I use an arm tool chain for the xscale on a daily basis and you are right, it is that is the naming convention of the tools. However, I strongly disagree that this should be the naming convention for the packages. As in my example, number 1 is much cleaner and obvious. Regards Michael From rc040203 at freenet.de Fri Jun 16 08:04:49 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 10:04:49 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <44926017.20308@knox.net.nz> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> Message-ID: <1150445090.12910.86.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 19:39 +1200, Michael J Knox wrote: > Ralf Corsepius wrote: > >> Why is the binary target name being used for the package name? That's > >> not intuitive to an end user at all IMHO. > >> > >> I think confusing the binary target name with the actual package name is > >> a mistake. > >> > >> gcc is gcc, not i386-redhat-linux-gcc > >> > > Wrong. What you have installed is an i386-redhat-linux-gcc rsp. a > > x86-68-redhat-linux-gcc (more precisely, a GCC having been configured > > for host=-redhat-linux). As this gcc also is the native gcc, it > > also is being installed as "gcc", which justifies the package to be > > called gcc. > > > > Ok fair enough. > >> OpenSUSE uses cross--gcc/binutils/whatever-version > >> debian looks like it uses gcc/binutils/whatever--version > >> > > > > What is the ? That's the essential part of it. > > > Its not it was /whatever/ implying insert cross tool here. > > A "cross-i386-gcc" would be complete non-sense, because a cross tool > > chain depends on the OS and several components more. An > > i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or > > a i386-redhat-gcc or a i386-suse-gcc. > > > Again, this is a packaging name, not a binary target. Packaged as > cross-arm-gcc for example, tells me straigh way what this package is. Nope. "arm-gcc" is complete non-sense, whether as a package name or as a target name. Again, the even the fact it is a cross compiler doesn't matter. It's a package. If one thinks your thought to an end, one ends up with any native into native- > > However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy > binutils? A binutils addon? With all due respect, now I can't resort to have doubts on your qualification. > I also think that having the arch (read i386 > not rtems) in the name is not needed. You have not understood. The package contain a cross-tool chain, i.e. native i386-redhat-linux applications having been configured to support binaries on other OSs (here: rtems) > RPM takes care of the arch. Nope, rpm only takes care about the build arch. It doesn't take care about target or host architectures You are mixing up host and target. > 1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > vs > 2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > example 1 makes a lot of sense to me Again, you are missing the point. cross-rtems4.7 is insufficient and is nonsense. There are many rtems cross toolschains, each of them addressing different -rtems permutations (e.g. sparc-rtems4.7, or mips-rtems4.7). They all contain native linux applications, but generate code/objs for different OSes/architectures. > Also, is Fedora ever going to ship a cross compiler for SuSE? I doubt > it. A cross compiler for cygwin? Do you want me to submit them? I have Fedora->FreeBSD6|Solaris5.7|MinGW| Cygwin and ca. 8 rtems targets pending? Due to license restrictions, Solaris won't ever go to the public, but I may very well submit the others I also could Canadian crossbuild Cygwin/MinGW rpms, of these toolchains, but ... I am not interesting in promoting these OSes. > >> Personally I like the cross-prefix, its a lot more obvious to an end > >> user what the package is and is for, but thats just me. > >> > > > > Everybody being used to cross tool chains, knows that the tools insided > > are called -. > > > > > Aye.. I use an arm tool chain for the xscale on a daily basis cf. below > and you > are right, it is that is the naming convention of the tools. !!!!!!!! Ralf -- RTEMS Steering Committee Member mailto:ralf.corsepius at rtems.org GCC Maintainer mailto:corsepiu at gcc.gnu.org From michael at knox.net.nz Fri Jun 16 08:11:10 2006 From: michael at knox.net.nz (Michael J Knox) Date: Fri, 16 Jun 2006 20:11:10 +1200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1150445090.12910.86.camel@mccallum.corsepiu.local> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150445090.12910.86.camel@mccallum.corsepiu.local> Message-ID: <4492679E.8070705@knox.net.nz> Ralf Corsepius wrote: > With all due respect, now I can't resort to have doubts on your > qualification. > Well, if I am not "qualified" to express my doubt or my opinion on such a topic, I will leave to those that might be. Thanks Michael From rc040203 at freenet.de Fri Jun 16 09:10:29 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 11:10:29 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <4492679E.8070705@knox.net.nz> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150445090.12910.86.camel@mccallum.corsepiu.local> <4492679E.8070705@knox.net.nz> Message-ID: <1150449029.12910.110.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 20:11 +1200, Michael J Knox wrote: > Ralf Corsepius wrote: > > With all due respect, now I can't resort to have doubts on your > > qualification. > > > Well, if I am not "qualified" to express my doubt or my opinion on such > a topic, I will leave to those that might be. Well, in case you're still interested, you might want to check one of my toolchains for -rtems4.7 targets: ftp://packman.iu-bremen.de/fedora/4/SRPMS/ [Sorry, due to lack of bandwith, nosrc.rpms only and due to lack of time and bandwidth no fc5 rpms, yet - I have them locally ... ] May-be you'll then understand why these are not .rpms. Ralf From tcallawa at redhat.com Fri Jun 16 12:44:24 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 16 Jun 2006 07:44:24 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150439713.12910.65.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> Message-ID: <1150461864.22820.21.camel@localhost.localdomain> On Fri, 2006-06-16 at 08:35 +0200, Ralf Corsepius wrote: > > ------- Additional Comments From jko at redhat.com 2006-06-15 02:45 EST ------- > > ------- Additional Comments From jkeating at redhat.com 2006-06-11 11:04 EST ------- > > NEEDSWORK > > - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built. > Why? I thought, RH was going to use the *same* conventions as Fedora? > > Apparently not ... Brew never supported %{?dist} tag, and the guidelines say that Core packages can't expect that tag to be there. HOWEVER: Just because they can't use the actual dist tag, if they want to add any sort of suffix, they have to use the dist tag syntax. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Fri Jun 16 13:09:15 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 15:09:15 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150461864.22820.21.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> Message-ID: <1150463355.12910.116.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 07:44 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-06-16 at 08:35 +0200, Ralf Corsepius wrote: > > > ------- Additional Comments From jko at redhat.com 2006-06-15 02:45 EST ------- > > > ------- Additional Comments From jkeating at redhat.com 2006-06-11 11:04 EST ------- > > > NEEDSWORK > > > - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built. > > Why? I thought, RH was going to use the *same* conventions as Fedora? > > > > Apparently not ... > > Brew never supported %{?dist} tag, ... never say "never" ... ;) > and the guidelines say that Core > packages can't expect that tag to be there. Well, exactly this is one of the points I consider to be a "must-be discussed soon". At least I consider consistent and clear conventions on "NEVR"'s, which %dist is part of, to be a minimum requirement for closer and better Core<->Extra (+external repos) interaction. To me, the current situation leaves much to be desired. Ralf From jkeating at redhat.com Fri Jun 16 13:25:38 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Jun 2006 09:25:38 -0400 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150463355.12910.116.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> Message-ID: <1150464338.32654.26.camel@ender> On Fri, 2006-06-16 at 15:09 +0200, Ralf Corsepius wrote: > > Brew never supported %{?dist} tag, > ... never say "never" ... ;) Indeed. Brew supported %{?dist} for about 4 hours, long enough for us to realize it broke some things in our infrastructure so it got punted till later. > > and the guidelines say that Core > > packages can't expect that tag to be there. > Well, exactly this is one of the points I consider to be a "must-be > discussed soon". > > At least I consider consistent and clear conventions on "NEVR"'s, > which > %dist is part of, to be a minimum requirement for closer and better > Core<->Extra (+external repos) interaction. > > To me, the current situation leaves much to be desired. The guidelines also mention that use of %{?dist} is optional and not necessary in _any_ package. As long as there is a clear upgrade path from FE4 -> FE5 -> devel than that is acceptable. As spot states though, if a new core package is going to use some sort of dist like part of the NEVR, it has to follow what %{?dist} would evaluate to, '.fc6' '.fc5' etc... This is one of the things I look at when reviewing a new Core package. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Fri Jun 16 13:39:53 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 15:39:53 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150464338.32654.26.camel@ender> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> Message-ID: <1150465194.12910.126.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 09:25 -0400, Jesse Keating wrote: > On Fri, 2006-06-16 at 15:09 +0200, Ralf Corsepius wrote: > > > Brew never supported %{?dist} tag, > > ... never say "never" ... ;) > > > and the guidelines say that Core > > > packages can't expect that tag to be there. > > Well, exactly this is one of the points I consider to be a "must-be > > discussed soon". > > > > At least I consider consistent and clear conventions on "NEVR"'s, > > which > > %dist is part of, to be a minimum requirement for closer and better > > Core<->Extra (+external repos) interaction. > > > > To me, the current situation leaves much to be desired. > > The guidelines also mention that use of %{?dist} is optional and not > necessary in _any_ package. One of the unclearnesses I don't find helpful. At the moment, we have various styles of release tags, which all are incompatible and without any guarantee of a clear upgrade path ... > As long as there is a clear upgrade path > from FE4 -> FE5 -> devel than that is acceptable. My view is different. I am in favor of one single and mandatory style of release tag - Which doesn't really matter, all that matters is consistency. > As spot states though, if a new core package is going to use some sort > of dist like part of the NEVR, it has to follow what %{?dist} would > evaluate to, '.fc6' '.fc5' etc... This is one of the things I look at > when reviewing a new Core package. Now consider packages moving from Core to Extras and vice versa., some packages using R: 1.2.FC5, others 1.fc5.2.3, others 1%{?dist}, or consider 3rd party add-on package providers ... We had discussed that many times before, but without actual result. The current work-around basically condenses to: Nobody cares much about anybody, this whole stuff is a swamp :-/ Ralf From tcallawa at redhat.com Fri Jun 16 13:55:47 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 16 Jun 2006 08:55:47 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150465194.12910.126.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> Message-ID: <1150466147.22820.65.camel@localhost.localdomain> On Fri, 2006-06-16 at 15:39 +0200, Ralf Corsepius wrote: > > The guidelines also mention that use of %{?dist} is optional and not > > necessary in _any_ package. > One of the unclearnesses I don't find helpful. > > At the moment, we have various styles of release tags, which all are > incompatible and without any guarantee of a clear upgrade path ... In Core? Yes. In Extras? No. Auditing the FC development tree for violations of naming policy would be nice. ;) > > As long as there is a clear upgrade path > > from FE4 -> FE5 -> devel than that is acceptable. > My view is different. I am in favor of one single and mandatory style of > release tag - Which doesn't really matter, all that matters is > consistency. I agree that the most vital item here is consistency. > Now consider packages moving from Core to Extras and vice versa., > some packages using R: 1.2.FC5, others 1.fc5.2.3, others 1%{?dist}, or > consider 3rd party add-on package providers ... > > We had discussed that many times before, but without actual result. The > current work-around basically condenses to: Nobody cares much about > anybody, this whole stuff is a swamp :-/ Breath in, breath out. ;) We obviously care, or we wouldn't be having these discussions, we'd be telling you to shut up and do what Red Hat says. Count the number of non-RH names on the Fedora packaging committee. Core pre FC6 was pretty fubar in a lot of ways. Core in FC6 is a whole new ball game. We're never going to get mandatory dist tag usage, but we can enforce that any suffix must follow the dist tag rules. In Extras, we have a smart enough buildsystem to handle using the %{dist} macro, and in Core, they'll have to hardcode it using the dist tag syntax. We will gain consistency here. There are lots of areas where core will have to improve to meet the guidelines, and none of them will happen over night. There are still a LOT of bugs to file. ;) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rc040203 at freenet.de Fri Jun 16 14:49:33 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 16:49:33 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150466147.22820.65.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> Message-ID: <1150469373.12910.142.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 08:55 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-06-16 at 15:39 +0200, Ralf Corsepius wrote: > > > > The guidelines also mention that use of %{?dist} is optional and not > > > necessary in _any_ package. > > One of the unclearnesses I don't find helpful. > > > > At the moment, we have various styles of release tags, which all are > > incompatible and without any guarantee of a clear upgrade path ... > > In Core? Yes. Some random examples: .. ant-antlr-1.6.5-1jpp_9fc.i386.rpm .. dmraid-devel-1.0.0.rc11-FC6.i386.rpm > In Extras? No. Yes. There exist packagers who (In FE devel) * don't use %{?dist} at all * some use N%{?dist} and increment N with each iteration. * some use N%{?dist}.M and increment M with each build-iteration Now consider moving such a package from FE to FC (and from mock to brew). > We obviously care, or we wouldn't be having these discussions, we'd be > telling you to shut up and do what Red Hat says. Count the number of > non-RH names on the Fedora packaging committee. Well, on one hand you told "Same packaging conventions in FC as in FE", the other hand you are telling "%{dist} won't ever be in brew". => project has failed even before it started? > There are lots of areas where core will have to improve to meet the > guidelines, and none of them will happen over night. Well, I'd put NEVR conventions on a top priority item on the agenda. Ralf From tcallawa at redhat.com Fri Jun 16 15:02:25 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 16 Jun 2006 10:02:25 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150469373.12910.142.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> Message-ID: <1150470146.22820.70.camel@localhost.localdomain> On Fri, 2006-06-16 at 16:49 +0200, Ralf Corsepius wrote: > On Fri, 2006-06-16 at 08:55 -0500, Tom 'spot' Callaway wrote: > > On Fri, 2006-06-16 at 15:39 +0200, Ralf Corsepius wrote: > > > > > > The guidelines also mention that use of %{?dist} is optional and not > > > > necessary in _any_ package. > > > One of the unclearnesses I don't find helpful. > > > > > > At the moment, we have various styles of release tags, which all are > > > incompatible and without any guarantee of a clear upgrade path ... > > > > In Core? Yes. > > Some random examples: > .. > ant-antlr-1.6.5-1jpp_9fc.i386.rpm > .. > dmraid-devel-1.0.0.rc11-FC6.i386.rpm Time to file bugs. ;) > > In Extras? No. > Yes. There exist packagers who (In FE devel) > * don't use %{?dist} at all > * some use N%{?dist} and increment N with each iteration. These are correct... > * some use N%{?dist}.M and increment M with each build-iteration ...and these are not. More bugs to file! > Well, on one hand you told "Same packaging conventions in FC as in FE", > the other hand you are telling "%{dist} won't ever be in brew". Both FC and FE have the option of using a dist tag. In FE, we have a nice macro thanks to our super awesome buildsystem. In FC, they don't have a nice macro. Rules are the same. If you use a dist tag, it has to meet the syntax as documented in the guidelines. > => project has failed even before it started? > > > There are lots of areas where core will have to improve to meet the > > guidelines, and none of them will happen over night. > > Well, I'd put NEVR conventions on a top priority item on the agenda. Seems like a valid point to me. This should be something that isn't difficult to audit, possibly even via automated script. Jesse, is this something that could bootstrap into Brew? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rdieter at math.unl.edu Fri Jun 16 15:10:10 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Jun 2006 10:10:10 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150470146.22820.70.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> Message-ID: <4492C9D2.8070406@math.unl.edu> Tom 'spot' Callaway wrote: > On Fri, 2006-06-16 at 16:49 +0200, Ralf Corsepius wrote: >>> In Extras? No. >> Yes. There exist packagers who (In FE devel) >> * don't use %{?dist} at all >> * some use N%{?dist} and increment N with each iteration. > > These are correct... > >> * some use N%{?dist}.M and increment M with each build-iteration > > ...and these are not. More bugs to file! I'd argue there are valid cases for using this latter construct(*), like fixing a packaging bug/error limited to only one fedora release/platform. I'd agree that that it's use should be rare. (*) especially for those packagers (like myself) that prefer to keep a single specfile sync'd for all fedora releases. -- Rex From rc040203 at freenet.de Fri Jun 16 15:17:45 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 17:17:45 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150470146.22820.70.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> Message-ID: <1150471066.12910.145.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 10:02 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-06-16 at 16:49 +0200, Ralf Corsepius wrote: > > On Fri, 2006-06-16 at 08:55 -0500, Tom 'spot' Callaway wrote: > > > On Fri, 2006-06-16 at 15:39 +0200, Ralf Corsepius wrote: > > > > Well, I'd put NEVR conventions on a top priority item on the agenda. > > Seems like a valid point to me. This should be something that isn't > difficult to audit, possibly even via automated script. Jesse, is this > something that could bootstrap into Brew? You are aware what other distros do/did? They let the build-system chose release tag to make sure it's unique and consistent. Ralf From rc040203 at freenet.de Fri Jun 16 15:22:03 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 17:22:03 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <4492C9D2.8070406@math.unl.edu> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <4492C9D2.8070406@math.unl.edu> Message-ID: <1150471323.12910.149.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 10:10 -0500, Rex Dieter wrote: > Tom 'spot' Callaway wrote: > > On Fri, 2006-06-16 at 16:49 +0200, Ralf Corsepius wrote: > > >>> In Extras? No. > >> Yes. There exist packagers who (In FE devel) > >> * don't use %{?dist} at all > >> * some use N%{?dist} and increment N with each iteration. > > > > These are correct... > > > >> * some use N%{?dist}.M and increment M with each build-iteration > > > > ...and these are not. More bugs to file! > > I'd argue there are valid cases for using this latter construct(*), like > fixing a packaging bug/error limited to only one fedora > release/platform. I'd agree that that it's use should be rare. I agree there are valid cases for doing this on "non-devel", but I can't imagine any reason for doing this on "devel". > (*) especially for those packagers (like myself) that prefer to keep a > single specfile sync'd for all fedora releases. Increment N, %{?dist} will do the rest. Ralf From tcallawa at redhat.com Fri Jun 16 15:16:02 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 16 Jun 2006 10:16:02 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <4492C9D2.8070406@math.unl.edu> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <4492C9D2.8070406@math.unl.edu> Message-ID: <1150470962.22820.73.camel@localhost.localdomain> On Fri, 2006-06-16 at 10:10 -0500, Rex Dieter wrote: > Tom 'spot' Callaway wrote: > > On Fri, 2006-06-16 at 16:49 +0200, Ralf Corsepius wrote: > > >>> In Extras? No. > >> Yes. There exist packagers who (In FE devel) > >> * don't use %{?dist} at all > >> * some use N%{?dist} and increment N with each iteration. > > > > These are correct... > > > >> * some use N%{?dist}.M and increment M with each build-iteration > > > > ...and these are not. More bugs to file! > > I'd argue there are valid cases for using this latter construct(*), like > fixing a packaging bug/error limited to only one fedora > release/platform. I'd agree that that it's use should be rare. IMHO, it is far too easy to abuse, and for people to use it without understanding why it is dangerous. > (*) especially for those packagers (like myself) that prefer to keep a > single specfile sync'd for all fedora releases. I think it is a minor price to pay to have to bump spec file number for each dist. No one says you have to _build_ those bumped spec files for dists where it isn't relevant (as long as you keep dist package NVR ordering correct, FC3 < FC4 < FC5 < FC6...). ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tibbs at math.uh.edu Fri Jun 16 15:27:36 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 16 Jun 2006 10:27:36 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150470146.22820.70.camel@localhost.localdomain> (Tom Callaway's message of "Fri, 16 Jun 2006 10:02:25 -0500") References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom Callaway writes: >> * some use N%{?dist}.M and increment M with each build-iteration TC> ...and these are not. More bugs to file! This method has been suggested for use on extras-list as the only way to bump a package version without also bumping the version of all later releases. I would suggest that's why it's being used currently. What would be the proper way to handle that situation? - J< From rc040203 at freenet.de Fri Jun 16 15:31:53 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 17:31:53 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> Message-ID: <1150471913.12910.154.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 10:27 -0500, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom Callaway writes: > > >> * some use N%{?dist}.M and increment M with each build-iteration > > TC> ...and these are not. More bugs to file! > > This method has been suggested for use on extras-list as the only way > to bump a package version without also bumping the version of all > later releases. I would suggest that's why it's being used > currently. That's exactly the "non-devel" case, I was referring to in my other mail. It's handy when spec files fork between FC-releases, and when packagers can't/don't want to kept them identical. Rex' case however is the opposite. He wants idential specs, so he can't avoid incrementing N. > What would be the proper way to handle that situation? Ralf From tibbs at math.uh.edu Fri Jun 16 15:43:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 16 Jun 2006 10:43:59 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150471913.12910.154.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 16 Jun 2006 17:31:53 +0200") References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150471913.12910.154.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> That's exactly the "non-devel" case, I was referring to in my RC> other mail. It's handy when spec files fork between FC-releases, RC> and when packagers can't/don't want to kept them identical. I agree, but it seems that spot doesn't and no mention of this is made in the guidelines. So it seems we need to convince spot and get the guidelines updated. (I agree that in the -devel case we should just stick with N%{?dist} where N is an integer >= 1.) - J< From rc040203 at freenet.de Fri Jun 16 15:54:09 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 17:54:09 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150470146.22820.70.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> Message-ID: <1150473250.12910.162.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 10:02 -0500, Tom 'spot' Callaway wrote: > On Fri, 2006-06-16 at 16:49 +0200, Ralf Corsepius wrote: > > On Fri, 2006-06-16 at 08:55 -0500, Tom 'spot' Callaway wrote: > > > On Fri, 2006-06-16 at 15:39 +0200, Ralf Corsepius wrote: > > > > > > > > The guidelines also mention that use of %{?dist} is optional and not > > > > > necessary in _any_ package. > > > > One of the unclearnesses I don't find helpful. > > > > > > > > At the moment, we have various styles of release tags, which all are > > > > incompatible and without any guarantee of a clear upgrade path ... > > > > > > In Core? Yes. > > > > Some random examples: > > .. > > ant-antlr-1.6.5-1jpp_9fc.i386.rpm > > .. > > dmraid-devel-1.0.0.rc11-FC6.i386.rpm > > Time to file bugs. ;) > > > > In Extras? No. > > Yes. There exist packagers who (In FE devel) > > * don't use %{?dist} at all > > * some use N%{?dist} and increment N with each iteration. > > These are correct... > > > * some use N%{?dist}.M and increment M with each build-iteration Example from FE6's package release mail having been sent a couple of minutes ago: poker-engine-1.0.15-3.fc6.1 > ...and these are not. More bugs to file! Forgot to mention the case I consider to be the most broken version: * N.M%{?dist} with unclear meaning of M E.g. these packages have just been released for FE6: dejavu-fonts-2.7.0-0.15.fc6 xscreensaver-5.00-7.1.fc6 Q: Are N and M supposed to be ? Ralf From rdieter at math.unl.edu Fri Jun 16 15:59:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Jun 2006 10:59:26 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150473250.12910.162.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> Message-ID: <4492D55E.1090507@math.unl.edu> Ralf Corsepius wrote: > On Fri, 2006-06-16 at 10:02 -0500, Tom 'spot' Callaway wrote: > Forgot to mention the case I consider to be the most broken version: > * N.M%{?dist} > with unclear meaning of M > > E.g. these packages have just been released for FE6: > dejavu-fonts-2.7.0-0.15.fc6 dejavu is based on a 2.7 prerelease. Probably should have some sort of "pre" in the Release tag. > xscreensaver-5.00-7.1.fc6 > > Q: Are N and M supposed to be ? Agreed. -- Rex From rc040203 at freenet.de Fri Jun 16 16:07:10 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Jun 2006 18:07:10 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <4492D55E.1090507@math.unl.edu> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <4492D55E.1090507@math.unl.edu> Message-ID: <1150474030.12910.168.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 10:59 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Fri, 2006-06-16 at 10:02 -0500, Tom 'spot' Callaway wrote: > > > Forgot to mention the case I consider to be the most broken version: > > * N.M%{?dist} > > with unclear meaning of M > > > > E.g. these packages have just been released for FE6: > > dejavu-fonts-2.7.0-0.15.fc6 > > dejavu is based on a 2.7 prerelease. Probably should have some sort of > "pre" in the Release tag. Why? The tar ball's release and the rpm's release don't have to be connected. I'd recommend to start with V: 2.7.0 and R: 1%{?dist} and to increment the Release tag, when a newer pre release or a final tarball is released and exchanged inside of the spec. (An alternative would be to use a different %Version, but that's a problem of its own.) Ralf From rdieter at math.unl.edu Fri Jun 16 16:15:45 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Jun 2006 11:15:45 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150474030.12910.168.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <4492D55E.1090507@math.unl.edu> <1150474030.12910.168.camel@mccallum.corsepiu.local> Message-ID: <4492D931.1000302@math.unl.edu> Ralf Corsepius wrote: > On Fri, 2006-06-16 at 10:59 -0500, Rex Dieter wrote: >> Ralf Corsepius wrote: >>> On Fri, 2006-06-16 at 10:02 -0500, Tom 'spot' Callaway wrote: >>> Forgot to mention the case I consider to be the most broken version: >>> * N.M%{?dist} >>> with unclear meaning of M >>> >>> E.g. these packages have just been released for FE6: >>> dejavu-fonts-2.7.0-0.15.fc6 >> dejavu is based on a 2.7 prerelease. Probably should have some sort of >> "pre" in the Release tag. > Why? Because the current NamingGuidelines say so: http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines#head-d97a3f40b6dd9d2288206ac9bd8f1bf9b791b22a -- Rex From jkeating at j2solutions.net Fri Jun 16 16:16:46 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jun 2006 12:16:46 -0400 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150471066.12910.145.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150471066.12910.145.camel@mccallum.corsepiu.local> Message-ID: <1150474606.9157.3.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-06-16 at 17:17 +0200, Ralf Corsepius wrote: > > Seems like a valid point to me. This should be something that isn't > > difficult to audit, possibly even via automated script. Jesse, is this > > something that could bootstrap into Brew? Tom, perhaps. Not any time soon though. > You are aware what other distros do/did? They let the build-system chose > release tag to make sure it's unique and consistent. > That works for specs that have %{?dist}, not so much for packages that are hardcoded. We will have to file bugs and thwap maintainers to use %{?dist} when it becomes available or follow the guidelines wrt what they use. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri Jun 16 16:16:32 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 16 Jun 2006 11:16:32 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150474030.12910.168.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 16 Jun 2006 18:07:10 +0200") References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <4492D55E.1090507@math.unl.edu> <1150474030.12910.168.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> I'd recommend to start with V: 2.7.0 and R: 1%{?dist} and to RC> increment the Release tag, when a newer pre release or a final RC> tarball is released and exchanged inside of the spec. If 2.7.0 doesn't actually exist yet, though, it's a bit disingenuous to release a package that indicates that it is 2.7.0. I recall that this has caused problems with various upstream developers in the past. In the case of dejavu, a snapshot is being packaged and the naming guidelines are quite clear on what the package should be named in that case. Unfortunately fixing it now would require that the version go backwards (or something horrible like an epoch bump). - J< From jkeating at j2solutions.net Fri Jun 16 16:17:52 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Jun 2006 12:17:52 -0400 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150469373.12910.142.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> Message-ID: <1150474672.9157.5.camel@dhcp83-49.boston.redhat.com> On Fri, 2006-06-16 at 16:49 +0200, Ralf Corsepius wrote: > Well, on one hand you told "Same packaging conventions in FC as in FE", > the other hand you are telling "%{dist} won't ever be in brew". > > => project has failed even before it started? Not once has anybody said %{?dist} wouldn't be used in brew. Not once. Please don't speak for us. I have stated that it is not _currently_ used but that I will be working to get it used post Test1. Just chill. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Fri Jun 16 16:42:02 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 16 Jun 2006 09:42:02 -0700 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <44926017.20308@knox.net.nz> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> Message-ID: <1150476123.3164.23.camel@localhost> On Fri, 2006-06-16 at 19:39 +1200, Michael J Knox wrote: > Ralf Corsepius wrote: > > A "cross-i386-gcc" would be complete non-sense, because a cross tool > > chain depends on the OS and several components more. An > > i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or > > a i386-redhat-gcc or a i386-suse-gcc. > > > Again, this is a packaging name, not a binary target. Packaged as > cross-arm-gcc for example, tells me straigh way what this package is. > However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy > binutils? A binutils addon? I also think that having the arch (read i386 > not rtems) in the name is not needed. RPM takes care of the arch. > > 1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > vs > 2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm #1 Leaves out important information and will lead to naming conflicts. Is this cross compiler going to generate code for rtems on a i386? A ppc? A sparc? We don't know. Whatever naming convention is chosen must include (i386, rtems4.7, binutils) as part of %{name} otherwise the name is incomplete and will clash with other packages. #2 Leaves the enduser browsing the package lists in the dark. As Jason Tibbits wrote: > What is "i386" and why does it have a subpackage of "rtems4.7"? This is partially because '-' is used as a separator in rpm packages (%{name}-%{version}-%{release}) and partially because we are conditioned to expect "i386" at the end of the rpm. I can see three choices: 1) Ignore the enduser confusion and go with Ralf's naming: i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm 2) Namespace the whole thing: cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm 3) Play games with the '-' to avoid the "it's an rpm separator" association: i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm FWIW, I think #2 has the most precedent. -Toshio From nicolas.mailhot at laposte.net Fri Jun 16 17:24:58 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Jun 2006 19:24:58 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <4492D55E.1090507@math.unl.edu> <1150474030.12910.168.camel@mccallum.corsepiu.local> Message-ID: <1150478698.2922.9.camel@rousalka.dyndns.org> Le vendredi 16 juin 2006 ? 11:16 -0500, Jason L Tibbitts III a ?crit : > >>>>> "RC" == Ralf Corsepius writes: > > RC> I'd recommend to start with V: 2.7.0 and R: 1%{?dist} and to > RC> increment the Release tag, when a newer pre release or a final > RC> tarball is released and exchanged inside of the spec. > > If 2.7.0 doesn't actually exist yet, though, it's a bit disingenuous > to release a package that indicates that it is 2.7.0. I recall that > this has caused problems with various upstream developers in the past. Unfortunately for you, that's both the common practice and what the guidelines advocate > In the case of dejavu, a snapshot is being packaged and the naming > guidelines are quite clear on what the package should be named in that > case. The guidelines say a pre-release should be numbered 0.%{X}.%{alphatag} with %{alphatag} the string that came from the version In this particular case I didn't bother with %{alphatag} because it has little or no use for FE users - the features tested do not depend on which particular pre-release snapshot is used. > Unfortunately fixing it now would require that the version go > backwards (or something horrible like an epoch bump). Nope. If you really want an alphatag I can add one and it will work without epochs or other horrible things, just because X will be incremented. I question the value of this change though. Also if someone could define the canonical alphatag for svn I would be grateful. (it's not just a date it's also a number so svn alphatag is a composition of svn date and number but in what order I can only guess) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tibbs at math.uh.edu Fri Jun 16 17:36:24 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 16 Jun 2006 12:36:24 -0500 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150478698.2922.9.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Fri, 16 Jun 2006 19:24:58 +0200") References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <4492D55E.1090507@math.unl.edu> <1150474030.12910.168.camel@mccallum.corsepiu.local> <1150478698.2922.9.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> Unfortunately for you, that's both the common practice and what NM> the guidelines advocate For me? Not at all. For upstream? Well, if someone comes to them saying there are problems with 2.7 when 2.7 doesn't exist yet, then that's unfortunate for them. It looks to me [1] like this is a dated snapshot and would, according to the guidelines, carry the last released version and a release tag consisting of the last build number incremented by one, a period, and the snapshot date. 1) The tarball name is dejavu-sfd-20060614-943.tar.gz which doesn't carry a 2.7 version anywhere. The internal documentation doesn't refer to 2.7 anywhere. - J< From nicolas.mailhot at laposte.net Fri Jun 16 17:46:13 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Jun 2006 19:46:13 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <4492D55E.1090507@math.unl.edu> <1150474030.12910.168.camel@mccallum.corsepiu.local> <1150478698.2922.9.camel@rousalka.dyndns.org> Message-ID: <1150479973.2922.17.camel@rousalka.dyndns.org> Le vendredi 16 juin 2006 ? 12:36 -0500, Jason L Tibbitts III a ?crit : > It looks to me [1] like this is a dated snapshot and would, according to > the guidelines, carry the last released version and a release tag > consisting of the last build number incremented by one, a period, and > the snapshot date. Read the guidelines again The guidelines distinguish between pre-release and post-release snapshot (the example given is a post-release snapshot). Upstream is in last-week-of-freeze-before-release and that qualifies for pre-release snapshot to me, even if they didn't bother with the next release number yet. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Fri Jun 16 18:11:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Jun 2006 20:11:41 +0200 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> Message-ID: <1150481501.2922.28.camel@rousalka.dyndns.org> Le vendredi 16 juin 2006 ? 13:38 -0400, buildsys at fedoraproject.org a ?crit : > Job failed on arch noarch > > > Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/11111-dejavu-fonts-2.7.0-0.16.943~20060614svn.fc6/ Well either something strange is happening, or the buildsys does not like my alphatag. If the buildsys does not like ~, what separator could I use ? I need to construct an alphatag out of svn number, svn date, svn string For obvious reasons : - svn number and svn date must be separated, - the separator must be part of the base latin block - - is taken as rpm field separator - . is taken as in-field separator - : is taken as epoch separator - _ is ugly, and besides CVS flattens . in _ when making up tags, so it would collide with . ~ was nice and even defined as separator character in the Gnome character map, but it seems it's a no-go too Any ideas ? Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tcallawa at redhat.com Fri Jun 16 18:19:53 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 16 Jun 2006 13:19:53 -0500 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <1150481501.2922.28.camel@rousalka.dyndns.org> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> Message-ID: <1150481993.27412.4.camel@localhost.localdomain> On Fri, 2006-06-16 at 20:11 +0200, Nicolas Mailhot wrote: > Le vendredi 16 juin 2006 ? 13:38 -0400, buildsys at fedoraproject.org a > ?crit : > > Job failed on arch noarch > > > > > > Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/11111-dejavu-fonts-2.7.0-0.16.943~20060614svn.fc6/ > > Well either something strange is happening, or the buildsys does not > like my alphatag. > > If the buildsys does not like ~, what separator could I use ? > I need to construct an alphatag out of svn number, svn date, svn string How about just using the svn date or the svn number, but not both? ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From rdieter at math.unl.edu Fri Jun 16 18:21:02 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Jun 2006 13:21:02 -0500 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <1150481501.2922.28.camel@rousalka.dyndns.org> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> Message-ID: <4492F68E.5090307@math.unl.edu> Nicolas Mailhot wrote: > If the buildsys does not like ~, what separator could I use ? > I need to construct an alphatag out of svn number, svn date, svn string > > For obvious reasons : > - svn number and svn date must be separated, > - the separator must be part of the base latin block > - - is taken as rpm field separator > - . is taken as in-field separator Despite your reservation about '.', that's probably the best option. -- Rex From nicolas.mailhot at laposte.net Fri Jun 16 18:53:16 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Jun 2006 20:53:16 +0200 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <4492F68E.5090307@math.unl.edu> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> <4492F68E.5090307@math.unl.edu> Message-ID: <1150483996.2922.33.camel@rousalka.dyndns.org> Le vendredi 16 juin 2006 ? 13:21 -0500, Rex Dieter a ?crit : > Nicolas Mailhot wrote: > > > If the buildsys does not like ~, what separator could I use ? > > I need to construct an alphatag out of svn number, svn date, svn string > > > > For obvious reasons : > > - svn number and svn date must be separated, > > - the separator must be part of the base latin block > > - - is taken as rpm field separator > > - . is taken as in-field separator > > Despite your reservation about '.', that's probably the best option. It seems plus (+) works, is easy to type and read, and is not already taken (so no one will accuse me of breaking alphatag in multiple fields). I now christen 'svnnumber'+'svndate'svn my official svn alphatag. If no one objects and I remember how I'll put it in the wiki too. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Fri Jun 16 19:00:47 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Jun 2006 21:00:47 +0200 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <1150483996.2922.33.camel@rousalka.dyndns.org> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> <4492F68E.5090307@math.unl.edu> <1150483996.2922.33.camel@rousalka.dyndns.org> Message-ID: <1150484448.2922.35.camel@rousalka.dyndns.org> Le vendredi 16 juin 2006 ? 20:53 +0200, Nicolas Mailhot a ?crit : > Le vendredi 16 juin 2006 ? 13:21 -0500, Rex Dieter a ?crit : > > Nicolas Mailhot wrote: > > > > > If the buildsys does not like ~, what separator could I use ? > > > I need to construct an alphatag out of svn number, svn date, svn string > > > > > > For obvious reasons : > > > - svn number and svn date must be separated, > > > - the separator must be part of the base latin block > > > - - is taken as rpm field separator > > > - . is taken as in-field separator > > > > Despite your reservation about '.', that's probably the best option. > > It seems plus (+) works, is easy to type and read, and is not already > taken (so no one will accuse me of breaking alphatag in multiple > fields). > > I now christen 'svnnumber'+'svndate'svn my official svn alphatag. > > If no one objects and I remember how I'll put it in the wiki too. Oh well, seems the page is locked up so whom should I ping to get it changed ? Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rdieter at math.unl.edu Fri Jun 16 19:03:32 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Jun 2006 14:03:32 -0500 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <1150483996.2922.33.camel@rousalka.dyndns.org> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> <4492F68E.5090307@math.unl.edu> <1150483996.2922.33.camel@rousalka.dyndns.org> Message-ID: <44930084.3030605@math.unl.edu> Nicolas Mailhot wrote: > Le vendredi 16 juin 2006 ? 13:21 -0500, Rex Dieter a ?crit : >> Nicolas Mailhot wrote: >> >>> If the buildsys does not like ~, what separator could I use ? >>> I need to construct an alphatag out of svn number, svn date, svn string >>> >>> For obvious reasons : >>> - svn number and svn date must be separated, >>> - the separator must be part of the base latin block >>> - - is taken as rpm field separator >>> - . is taken as in-field separator >> Despite your reservation about '.', that's probably the best option. > > It seems plus (+) works, is easy to type and read, and is not already > taken (so no one will accuse me of breaking alphatag in multiple > fields). > > I now christen 'svnnumber'+'svndate'svn my official svn alphatag. > > If no one objects and I remember how I'll put it in the wiki too. Yuck, why not try to stuff any/all of !@#%$^*() into the Release tag too while you're at it... (: -- Rex From nicolas.mailhot at laposte.net Fri Jun 16 19:12:50 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Jun 2006 21:12:50 +0200 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <44930084.3030605@math.unl.edu> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> <4492F68E.5090307@math.unl.edu> <1150483996.2922.33.camel@rousalka.dyndns.org> <44930084.3030605@math.unl.edu> Message-ID: <1150485170.2922.39.camel@rousalka.dyndns.org> Le vendredi 16 juin 2006 ? 14:03 -0500, Rex Dieter a ?crit : > Nicolas Mailhot wrote: > > Le vendredi 16 juin 2006 ? 13:21 -0500, Rex Dieter a ?crit : > >> Nicolas Mailhot wrote: > >> > >>> If the buildsys does not like ~, what separator could I use ? > >>> I need to construct an alphatag out of svn number, svn date, svn string > >>> > >>> For obvious reasons : > >>> - svn number and svn date must be separated, > >>> - the separator must be part of the base latin block > >>> - - is taken as rpm field separator > >>> - . is taken as in-field separator > >> Despite your reservation about '.', that's probably the best option. > > > > It seems plus (+) works, is easy to type and read, and is not already > > taken (so no one will accuse me of breaking alphatag in multiple > > fields). > > > > I now christen 'svnnumber'+'svndate'svn my official svn alphatag. > > > > If no one objects and I remember how I'll put it in the wiki too. > > Yuck, why not try to stuff any/all of !@#%$^*() into the Release tag too > while you're at it... (: I only need one character separator now ;) + worked, so I won't try any other (have other things to do) Though come to think of it, the day someone gets around defining the git alphatag promises to be loads of fun. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tibbs at math.uh.edu Fri Jun 16 19:43:27 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 16 Jun 2006 14:43:27 -0500 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <1150484448.2922.35.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Fri, 16 Jun 2006 21:00:47 +0200") References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> <4492F68E.5090307@math.unl.edu> <1150483996.2922.33.camel@rousalka.dyndns.org> <1150484448.2922.35.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> Oh well, seems the page is locked up so whom should I ping to get NM> it changed ? The packaging committee. Currently spot is the only one with access. - J< From a.badger at gmail.com Fri Jun 16 19:52:48 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 16 Jun 2006 12:52:48 -0700 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <1150483996.2922.33.camel@rousalka.dyndns.org> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> <4492F68E.5090307@math.unl.edu> <1150483996.2922.33.camel@rousalka.dyndns.org> Message-ID: <1150487568.3164.72.camel@localhost> On Fri, 2006-06-16 at 20:53 +0200, Nicolas Mailhot wrote: > Le vendredi 16 juin 2006 ? 13:21 -0500, Rex Dieter a ?crit : > > Nicolas Mailhot wrote: > > > > > If the buildsys does not like ~, what separator could I use ? > > > I need to construct an alphatag out of svn number, svn date, svn string > > > > > > For obvious reasons : > > > - svn number and svn date must be separated, > > > - the separator must be part of the base latin block > > > - - is taken as rpm field separator > > > - . is taken as in-field separator > > > > Despite your reservation about '.', that's probably the best option. > > It seems plus (+) works, is easy to type and read, and is not already > taken (so no one will accuse me of breaking alphatag in multiple > fields). > > I now christen 'svnnumber'+'svndate'svn my official svn alphatag. > > If no one objects and I remember how I'll put it in the wiki too. I object :-) I think the Packaging Guidelines are unclear, but really specify two separate cases: 1) This prerelease is a tarball. In which case it should carry upstream's chosen %{alphatag}:: dejavu-sfd-2.7.0-0.X.20060614-943 2) This prerelease is a snapshot that has no upstream %{alphatag}, in which case you use DATEsvn: dejavu-sfd-2.7.0-0.X.20060614svn. Given that upstream is creating the tarball in this case, I can see either method being appropriate. However, I think mixing the two together should not become official policy. Prereleases and Snapshots:: I'm with tibbs in that I think snapshots should be considered postreleases, not prereleases. In the special case where there has been no previous release, it should be a postrelease of the fictitious version "0" release. It's rude to put upstream in the position of receiving bug reports about a non-existent version. Once upstream ships a tarball with the version updated, you can start shipping snapshots that are postreleases of that tarball. foo-2.6.9.tar.gz [Released 20060101] foo-20060614-943.tar.gz foo-2.6.9-0.1.20060614svn.rpm foo-2.7.0-pre1.tar.gz [Released 20060615] foo-2.7.0-0.1.pre1.rpm foo-20060616-999.tar.gz foo-2.7.0-0.2.pre1.20060616svn.rpm -Toshio From nicolas.mailhot at laposte.net Fri Jun 16 20:22:37 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Jun 2006 22:22:37 +0200 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <1150487568.3164.72.camel@localhost> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> <4492F68E.5090307@math.unl.edu> <1150483996.2922.33.camel@rousalka.dyndns.org> <1150487568.3164.72.camel@localhost> Message-ID: <1150489357.2710.16.camel@rousalka.dyndns.org> Le vendredi 16 juin 2006 ? 12:52 -0700, Toshio Kuratomi a ?crit : > On Fri, 2006-06-16 at 20:53 +0200, Nicolas Mailhot wrote: > > Le vendredi 16 juin 2006 ? 13:21 -0500, Rex Dieter a ?crit : > > > Nicolas Mailhot wrote: > > > > > > > If the buildsys does not like ~, what separator could I use ? > > > > I need to construct an alphatag out of svn number, svn date, svn string > > > > > > > > For obvious reasons : > > > > - svn number and svn date must be separated, > > > > - the separator must be part of the base latin block > > > > - - is taken as rpm field separator > > > > - . is taken as in-field separator > > > > > > Despite your reservation about '.', that's probably the best option. > > > > It seems plus (+) works, is easy to type and read, and is not already > > taken (so no one will accuse me of breaking alphatag in multiple > > fields). > > > > I now christen 'svnnumber'+'svndate'svn my official svn alphatag. > > > > If no one objects and I remember how I'll put it in the wiki too. > > I object :-) > > I think the Packaging Guidelines are unclear, but really specify two > separate cases: > > 1) This prerelease is a tarball. In which case it should carry > upstream's chosen %{alphatag}:: dejavu-sfd-2.7.0-0.X.20060614-943 You really do not want to use "-" in rpm fields, trust me > 2) This prerelease is a snapshot that has no upstream %{alphatag}, in > which case you use DATEsvn: dejavu-sfd-2.7.0-0.X.20060614svn. > > Given that upstream is creating the tarball in this case, I can see > either method being appropriate. However, I think mixing the two > together should not become official policy. It's not as clear-cut as this since upstream tarball is trivially named after a SVN checkout, so your alphatag is a svn alphatag anyway. Also the wiki example is very CVS-centered, in CVS you only have the date to work with but with more advanced the date alone is meaningless. Which is why they provide other means to identify a checkout (in svn's case a number, in git case an hash, etc) > Prereleases and Snapshots:: > > I'm with tibbs in that I think snapshots should be considered > postreleases, not prereleases. The guidelines text is very clear that being a snapshot is orthogonal to being pre or post : ? If a snapshot package is considered a "pre-release package", you should follow the guidelines listed in Pre-Release Packages, and use an %{alphatag} in the following format: ? Which is only sanity. If you're 99% of the way from release n to release n+1 presenting it as n is very misleading. The guidelines organisation unfortunately muddies waters a lot (if spot is reading this please separate alphatag definition from actual pre and post exmaples, right now it seems snapshots are the only form of post release, and all the others are pre releases.) > It's rude to put upstream in the position of > receiving bug reports about a non-existent version. It's rude to put upstream in the position of receiving reports for bugs in version N, when the user is actually running N + lots_of_changes, and the problem is likely to be in the lots_of_changes_part. When releasing a pre or post version you're *not* releasing the version itself so *any* bug not specifying the pre or post will be rude to upstream. Flattening out everything as posts won't help a little bit, especially since you can't indicate any longer which real version you're closest to. That's why good alphatags matter. In this particular case the snapshot is getting more and more likely to end up as the actual 2.7.0 (which is less than two days away) so I'd be mad to declare it a 2.6.0. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From a.badger at gmail.com Fri Jun 16 20:40:38 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 16 Jun 2006 13:40:38 -0700 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <1150489357.2710.16.camel@rousalka.dyndns.org> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> <4492F68E.5090307@math.unl.edu> <1150483996.2922.33.camel@rousalka.dyndns.org> <1150487568.3164.72.camel@localhost> <1150489357.2710.16.camel@rousalka.dyndns.org> Message-ID: <1150490438.3164.83.camel@localhost> On Fri, 2006-06-16 at 22:22 +0200, Nicolas Mailhot wrote: > Le vendredi 16 juin 2006 ? 12:52 -0700, Toshio Kuratomi a ?crit : > > On Fri, 2006-06-16 at 20:53 +0200, Nicolas Mailhot wrote: > > > Le vendredi 16 juin 2006 ? 13:21 -0500, Rex Dieter a ?crit : > > > > Nicolas Mailhot wrote: > > > > > > > > > If the buildsys does not like ~, what separator could I use ? > > > > > I need to construct an alphatag out of svn number, svn date, svn string > > > > > > > > > > For obvious reasons : > > > > > - svn number and svn date must be separated, > > > > > - the separator must be part of the base latin block > > > > > - - is taken as rpm field separator > > > > > - . is taken as in-field separator > > > > > > > > Despite your reservation about '.', that's probably the best option. > > > > > > It seems plus (+) works, is easy to type and read, and is not already > > > taken (so no one will accuse me of breaking alphatag in multiple > > > fields). > > > > > > I now christen 'svnnumber'+'svndate'svn my official svn alphatag. > > > > > > If no one objects and I remember how I'll put it in the wiki too. > > > > I object :-) > > > > I think the Packaging Guidelines are unclear, but really specify two > > separate cases: > > > > 1) This prerelease is a tarball. In which case it should carry > > upstream's chosen %{alphatag}:: dejavu-sfd-2.7.0-0.X.20060614-943 > > You really do not want to use "-" in rpm fields, trust me > > > 2) This prerelease is a snapshot that has no upstream %{alphatag}, in > > which case you use DATEsvn: dejavu-sfd-2.7.0-0.X.20060614svn. > > > > Given that upstream is creating the tarball in this case, I can see > > either method being appropriate. However, I think mixing the two > > together should not become official policy. > > It's not as clear-cut as this since upstream tarball is trivially named > after a SVN checkout, so your alphatag is a svn alphatag anyway. > > Also the wiki example is very CVS-centered, in CVS you only have the > date to work with but with more advanced the date alone is meaningless. > Which is why they provide other means to identify a checkout (in svn's > case a number, in git case an hash, etc) > This has been discussed before. With the conclusion that DATES are better than revisions in case upstream switches VCSs. I stopped being lazy and actually searched for the post:: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00447.html mschwendt lists a solution which no one objected to... Use svn as the delimiter between the DATE and the Release:: dejavu-sfd-2.7.0-0.X.20060614svn943 > > It's rude to put upstream in the position of > > receiving bug reports about a non-existent version. > > It's rude to put upstream in the position of receiving reports for bugs > in version N, when the user is actually running N + lots_of_changes, and > the problem is likely to be in the lots_of_changes_part. > > When releasing a pre or post version you're *not* releasing the version > itself so *any* bug not specifying the pre or post will be rude to > upstream. Flattening out everything as posts won't help a little bit, > especially since you can't indicate any longer which real version you're > closest to. > Okay. I can see this view. -Toshio From michael at knox.net.nz Fri Jun 16 20:48:50 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 17 Jun 2006 08:48:50 +1200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1150476123.3164.23.camel@localhost> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> Message-ID: <44931932.2080906@knox.net.nz> Toshio Kuratomi wrote: > On Fri, 2006-06-16 at 19:39 +1200, Michael J Knox wrote: >> Ralf Corsepius wrote: >>> A "cross-i386-gcc" would be complete non-sense, because a cross tool >>> chain depends on the OS and several components more. An >>> i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or >>> a i386-redhat-gcc or a i386-suse-gcc. >>> >> Again, this is a packaging name, not a binary target. Packaged as >> cross-arm-gcc for example, tells me straigh way what this package is. >> However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy >> binutils? A binutils addon? I also think that having the arch (read i386 >> not rtems) in the name is not needed. RPM takes care of the arch. >> >> 1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm >> vs >> 2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > #1 Leaves out important information and will lead to naming conflicts. > Is this cross compiler going to generate code for rtems on a i386? A > ppc? A sparc? We don't know. Whatever naming convention is chosen > must include (i386, rtems4.7, binutils) as part of %{name} otherwise the > name is incomplete and will clash with other packages. Ah of course, yes :) > #2 Leaves the enduser browsing the package lists in the dark. As Jason > Tibbits wrote: >> What is "i386" and why does it have a subpackage of "rtems4.7"? > > This is partially because '-' is used as a separator in rpm packages > (%{name}-%{version}-%{release}) and partially because we are conditioned > to expect "i386" at the end of the rpm. > > I can see three choices: > > 1) Ignore the enduser confusion and go with Ralf's naming: > i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > 2) Namespace the whole thing: > cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > 3) Play games with the '-' to avoid the "it's an rpm separator" > association: > i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > FWIW, I think #2 has the most precedent. +1 on #2 Michael From nicolas.mailhot at laposte.net Fri Jun 16 21:11:43 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Jun 2006 23:11:43 +0200 Subject: [Fedora-packaging] Re: Build Error (Job 11111): dejavu-fonts-2_7_0-0_16_943~20060614svn_fc6 on fedora-development-extras In-Reply-To: <1150490438.3164.83.camel@localhost> References: <20060616173837.5CFA715217B@buildsys.fedoraproject.org> <1150481501.2922.28.camel@rousalka.dyndns.org> <4492F68E.5090307@math.unl.edu> <1150483996.2922.33.camel@rousalka.dyndns.org> <1150487568.3164.72.camel@localhost> <1150489357.2710.16.camel@rousalka.dyndns.org> <1150490438.3164.83.camel@localhost> Message-ID: <1150492303.2710.19.camel@rousalka.dyndns.org> Le vendredi 16 juin 2006 ? 13:40 -0700, Toshio Kuratomi a ?crit : > https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00447.html > > mschwendt lists a solution which no one objected to... Use svn as the > delimiter between the DATE and the Release:: > > dejavu-sfd-2.7.0-0.X.20060614svn943 it'd be nice if that was traced in the wiki, would have saved me some time :( Will do a new alphatag then. But unless FE is pushed tomorrow, final will be out before it hits users. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugs.michael at gmx.net Fri Jun 16 23:03:45 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 17 Jun 2006 01:03:45 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150470146.22820.70.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> Message-ID: <20060617010345.8c442306.bugs.michael@gmx.net> On Fri, 16 Jun 2006 10:02:25 -0500, Tom 'spot' Callaway wrote: > > Yes. There exist packagers who (In FE devel) > > * don't use %{?dist} at all > > * some use N%{?dist} and increment N with each iteration. > > These are correct... > > > * some use N%{?dist}.M and increment M with each build-iteration > > ...and these are not. More bugs to file! I disagree. It should be packager's freedom what to do in this least-significant position of the release field. If this style of bumping release versions were not permitted, we would see more unneeded mass-rebuilds of a package for all dists only to keep the upgrade path sane when a new build for only an older dist is needed. From bugs.michael at gmx.net Fri Jun 16 23:03:56 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 17 Jun 2006 01:03:56 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150473250.12910.162.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> Message-ID: <20060617010356.9f256a88.bugs.michael@gmx.net> On Fri, 16 Jun 2006 17:54:09 +0200, Ralf Corsepius wrote: > Forgot to mention the case I consider to be the most broken version: > * N.M%{?dist} > with unclear meaning of M > > E.g. these packages have just been released for FE6: > dejavu-fonts-2.7.0-0.15.fc6 The old pre-release case, where the most-significant part of release is made 0 and hence makes it possible to ship a final 2.7.0-1.fc6 in the future without bumping Epoch. > xscreensaver-5.00-7.1.fc6 This is bad. 7.1.fc6 is newer than 7.fc7. In general, '1' > 'f'. > Q: Are N and M supposed to be ? Yes. _But_ it's only N{?dist} and 0.N{?dist} for pre-releases. "0." is a prefix, which creates a new field for RPM version comparison and doesn't turn N into a non-integer. From bugs.michael at gmx.net Fri Jun 16 23:03:53 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 17 Jun 2006 01:03:53 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150470962.22820.73.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <4492C9D2.8070406@math.unl.edu> <1150470962.22820.73.camel@localhost.localdomain> Message-ID: <20060617010353.001453c2.bugs.michael@gmx.net> On Fri, 16 Jun 2006 10:16:02 -0500, Tom 'spot' Callaway wrote: > > (*) especially for those packagers (like myself) that prefer to keep a > > single specfile sync'd for all fedora releases. > > I think it is a minor price to pay to have to bump spec file number for > each dist. No one says you have to _build_ those bumped spec files for > dists where it isn't relevant (as long as you keep dist package NVR > ordering correct, FC3 < FC4 < FC5 < FC6...). This fails badly when you want to fix something on FC4 without needing a rebuild on FC5 or FC6. You don't want your users to "pay the price" for unneeded mass-rebuilds like it has been done before (= no changes in the binaries except for a bumped release). From bugs.michael at gmx.net Fri Jun 16 23:03:50 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 17 Jun 2006 01:03:50 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150466147.22820.65.camel@localhost.localdomain> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> Message-ID: <20060617010350.2a493f17.bugs.michael@gmx.net> On Fri, 16 Jun 2006 08:55:47 -0500, Tom 'spot' Callaway wrote: > We obviously care, or we wouldn't be having these discussions, we'd be > telling you to shut up and do what Red Hat says. Count the number of > non-RH names on the Fedora packaging committee. The _number_ is irrelevant if the people on the committee are in agreement, but things in Core are done differently nevertheless. Inside RH, there ought to be an instance of people who review the existing Packaging Guidelines and announce whether and where we can make the step from "guidelines" to "policies". From jkeating at redhat.com Fri Jun 16 23:18:16 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Jun 2006 19:18:16 -0400 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <20060617010350.2a493f17.bugs.michael@gmx.net> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <20060617010350.2a493f17.bugs.michael@gmx.net> Message-ID: <1150499896.4752.1.camel@ender> On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote: > The _number_ is irrelevant if the people on the committee are in > agreement, but things in Core are done differently nevertheless. Inside > RH, there ought to be an instance of people who review the existing > Packaging Guidelines and announce whether and where we can make the step > from "guidelines" to "policies". > Guidelines are policies for new packages. We haven't yet broached the touchy subject of mass changes to all existing packages, however we're doing those piece by piece. Example fixing the BuildRequires. Next could be NEVR or something similar. -- Jesse Keating Release Engineer: Fedora -------------- 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 paul at all-the-johnsons.co.uk Fri Jun 16 23:17:50 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 17 Jun 2006 00:17:50 +0100 Subject: [Fedora-packaging] Mono packaging guidelines Message-ID: <1150499870.29435.35.camel@T7.Linux> Hi, This is what has come to pass so far... 1. If the application just uses mcs and doesn't call gcc anywhere, then it should be BuildArch: noarch - if it is mixed, stick with a buildarch [*] 2. Because %configure isn't playing ball with noarch, you must define a target - don't worry what the target is, it'll be ignored 3. Due to a bug in rpmbuild with noarch (BZ 195487), the libdir hack is still required to ensure packages are built on 64 bit architecture 4. Lots of the errors thrown up by rpmlint can be ignored as mono apps are not ELF 5. Stick with putting things in /usr/lib rather than %{_datadir} - this is inline with upstream and other distros [*] The exceptions here are anything built using nant (such as boo) - you can't specify the architecture (from what I can see) Can I have some comments back so that this can move forward to the packager committee on high? TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Sat Jun 17 00:42:47 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 02:42:47 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <20060617010356.9f256a88.bugs.michael@gmx.net> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> Message-ID: <1150504967.12910.180.camel@mccallum.corsepiu.local> On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote: > On Fri, 16 Jun 2006 17:54:09 +0200, Ralf Corsepius wrote: > > > Forgot to mention the case I consider to be the most broken version: > > * N.M%{?dist} > > with unclear meaning of M > > > > E.g. these packages have just been released for FE6: > > dejavu-fonts-2.7.0-0.15.fc6 > > The old pre-release case, where the most-significant part of release is > made 0 and hence makes it possible to ship a final 2.7.0-1.fc6 in the > future without bumping Epoch. IMO, an over-engineered miss-feature in the guidelines. It prevents 3rd party packagers to supply packages. Otherwise, they could resort to use: 2.7.0-0%{?dist}.M > > xscreensaver-5.00-7.1.fc6 > > This is bad. 7.1.fc6 is newer than 7.fc7. In general, '1' > 'f'. > > Q: Are N and M supposed to be ? > > Yes. _But_ it's only N{?dist} and 0.N{?dist} for pre-releases. C.f. above. IMO, a defect of the guidelines and to be reconsider. Let's keep things simple, instead. > "0." is a > prefix, which creates a new field for RPM version comparison and doesn't > turn N into a non-integer. Ralf From rc040203 at freenet.de Sat Jun 17 00:51:05 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 02:51:05 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <20060617010345.8c442306.bugs.michael@gmx.net> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <20060617010345.8c442306.bugs.michael@gmx.net> Message-ID: <1150505466.12910.190.camel@mccallum.corsepiu.local> On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote: > On Fri, 16 Jun 2006 10:02:25 -0500, Tom 'spot' Callaway wrote: > > > > Yes. There exist packagers who (In FE devel) > > > * don't use %{?dist} at all > > > * some use N%{?dist} and increment N with each iteration. > > > > These are correct... > > > > > * some use N%{?dist}.M and increment M with each build-iteration > > > > ...and these are not. More bugs to file! > > I disagree. It should be packager's freedom what to do in this > least-significant position of the release field. And I disagree, with this. Conversely: This kind of "freedom" is the cause for a lack of simplicity, and the cause for the broken upstream path versioning errors being reported. With more restrictive conventions, these issues would not exist. > If this style of bumping release versions were not permitted, we would see > more unneeded mass-rebuilds of a package for all dists only to keep the > upgrade path sane when a new build for only an older dist is needed. Why would that happen? Make "N%{dist}.M" (w/ N,M ... int > 0) mandatory and drop the pre/post-release stuff. I don't see how epoch bumps would ever be needed. Ralf From rc040203 at freenet.de Sat Jun 17 01:14:28 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 03:14:28 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <44931932.2080906@knox.net.nz> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <44931932.2080906@knox.net.nz> Message-ID: <1150506868.12910.206.camel@mccallum.corsepiu.local> On Sat, 2006-06-17 at 08:48 +1200, Michael J. Knox wrote: > Toshio Kuratomi wrote: > > On Fri, 2006-06-16 at 19:39 +1200, Michael J Knox wrote: > >> Ralf Corsepius wrote: > >>> A "cross-i386-gcc" would be complete non-sense, because a cross tool > >>> chain depends on the OS and several components more. An > >>> i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or > >>> a i386-redhat-gcc or a i386-suse-gcc. > >>> > >> Again, this is a packaging name, not a binary target. Packaged as > >> cross-arm-gcc for example, tells me straigh way what this package is. > >> However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy > >> binutils? A binutils addon? I also think that having the arch (read i386 > >> not rtems) in the name is not needed. RPM takes care of the arch. > >> > >> 1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > >> vs > >> 2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > > > #1 Leaves out important information and will lead to naming conflicts. > > Is this cross compiler going to generate code for rtems on a i386? A > > ppc? A sparc? We don't know. Whatever naming convention is chosen > > must include (i386, rtems4.7, binutils) as part of %{name} otherwise the > > name is incomplete and will clash with other packages. > > Ah of course, yes :) > > > #2 Leaves the enduser browsing the package lists in the dark. As Jason > > Tibbits wrote: > >> What is "i386" and why does it have a subpackage of "rtems4.7"? > > > > This is partially because '-' is used as a separator in rpm packages > > (%{name}-%{version}-%{release}) and partially because we are conditioned > > to expect "i386" at the end of the rpm. > > > > I can see three choices: > > > > 1) Ignore the enduser confusion and go with Ralf's naming: > > i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > > > 2) Namespace the whole thing: > > cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > > > 3) Play games with the '-' to avoid the "it's an rpm separator" > > association: > > i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > > > FWIW, I think #2 has the most precedent. > > +1 on #2 -10 on #2 Redundant info, over engineering, featuritis. Users don't need to know it's a cross compiler/cross-toolchain nor do I see any need why this should be necessary. -maxint on #3 confusing. Ralf From shishz at hotpop.com Sat Jun 17 03:20:34 2006 From: shishz at hotpop.com (Zing) Date: Fri, 16 Jun 2006 23:20:34 -0400 Subject: [Fedora-packaging] Re: Namespace for cross-compilation tools? References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <44931932.2080906@knox.net.nz> <1150506868.12910.206.camel@mccallum.corsepiu.local> Message-ID: On Sat, 17 Jun 2006 03:14:28 +0200, Ralf Corsepius wrote: > On Sat, 2006-06-17 at 08:48 +1200, Michael J. Knox wrote: >> Toshio Kuratomi wrote: >> > I can see three choices: >> > >> > 1) Ignore the enduser confusion and go with Ralf's naming: >> > i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm >> > >> > 2) Namespace the whole thing: >> > cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm >> > >> > 3) Play games with the '-' to avoid the "it's an rpm separator" >> > association: >> > i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm >> > >> > FWIW, I think #2 has the most precedent. >> >> +1 on #2 > > -10 on #2 > Redundant info, over engineering, featuritis. > Users don't need to know it's a cross compiler/cross-toolchain nor do I > see any need why this should be necessary. > > -maxint on #3 > confusing. > > Ralf FWIW, +1 on #2 speaking as an end-user aesthetic (i like the namespace cross-* gives me). Or what about a virtual provides of "crosscompiler" as a compromise? zing From rc040203 at freenet.de Sat Jun 17 03:31:19 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 05:31:19 +0200 Subject: [Fedora-packaging] Re: Namespace for cross-compilation tools? In-Reply-To: References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <44931932.2080906@knox.net.nz> <1150506868.12910.206.camel@mccallum.corsepiu.local> Message-ID: <1150515079.12910.217.camel@mccallum.corsepiu.local> On Fri, 2006-06-16 at 23:20 -0400, Zing wrote: > On Sat, 17 Jun 2006 03:14:28 +0200, Ralf Corsepius wrote: > > > On Sat, 2006-06-17 at 08:48 +1200, Michael J. Knox wrote: > >> Toshio Kuratomi wrote: > >> > I can see three choices: > >> > > >> > 1) Ignore the enduser confusion and go with Ralf's naming: > >> > i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > >> > > >> > 2) Namespace the whole thing: > >> > cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > >> > > >> > 3) Play games with the '-' to avoid the "it's an rpm separator" > >> > association: > >> > i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm > >> > > >> > FWIW, I think #2 has the most precedent. > >> > >> +1 on #2 > > > > -10 on #2 > > Redundant info, over engineering, featuritis. > > Users don't need to know it's a cross compiler/cross-toolchain nor do I > > see any need why this should be necessary. > > > > -maxint on #3 > > confusing. > > > > Ralf > > FWIW, +1 on #2 speaking as an end-user aesthetic (i like the namespace > cross-* gives me). What does cross-* give you? Do you care about the fact it's a cross compiler? No, you don't. You don't want a "cross-compiler", you actually want a compiler targeting a certain target: You want a mips-elf-gcc or an arm-rtems4.7-gcc or a sparc-sun-solaris2.8-gcc. > Or what about a virtual provides of "crosscompiler" as a compromise? Completely meaningless. There is are many cross compilers. Each of them is targeting one of many targets, so a "Provides: crosscompiler" would cause conflicts. Ralf From michael at knox.net.nz Sat Jun 17 06:01:57 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 17 Jun 2006 18:01:57 +1200 Subject: [Fedora-packaging] Re: Namespace for cross-compilation tools? In-Reply-To: <1150515079.12910.217.camel@mccallum.corsepiu.local> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <44931932.2080906@knox.net.nz> <1150506868.12910.206.camel@mccallum.corsepiu.local> <1150515079.12910.217.camel@mccallum.corsepiu.local> Message-ID: <44939AD5.8080001@knox.net.nz> So how does this progress? We have had three suggested naming conventions, thanks to Toshio Kuratomi, with most of the weight leaning on #2, to recap them: 1) Ignore the enduser confusion and go with Ralf's naming: i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm 2) Namespace the whole thing: cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm 3) Play games with the '-' to avoid the "it's an rpm separator" association: i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm So far, there has been no resolve. Do we need to have more people have a say? Is this a storm in a tea cup? Thanks Michael From michael at knox.net.nz Sat Jun 17 06:07:31 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 17 Jun 2006 18:07:31 +1200 Subject: [Fedora-packaging] java packaging. In-Reply-To: <448B7772.9010800@knox.net.nz> References: <448B7772.9010800@knox.net.nz> Message-ID: <44939C23.50905@knox.net.nz> Michael J. Knox wrote: > Hey all, > > Since the correct way to build java packages is outlined here: > > http://fedoraproject.org/wiki/NativeJava > > and > > http://www.redhat.com/archives/fedora-extras-list/2006-June/msg00254.html > > Should there be a link from the packaging guide lines to the NativeJava > wiki page ? > If there is no objection, I would like to add a link from the http://fedoraproject.org/wiki/Extras developer section to the NativeJava page Thanks Michael From tibbs at math.uh.edu Sat Jun 17 06:17:44 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 17 Jun 2006 01:17:44 -0500 Subject: [Fedora-packaging] Re: Namespace for cross-compilation tools? In-Reply-To: <44939AD5.8080001@knox.net.nz> (Michael J. Knox's message of "Sat, 17 Jun 2006 18:01:57 +1200") References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <44931932.2080906@knox.net.nz> <1150506868.12910.206.camel@mccallum.corsepiu.local> <1150515079.12910.217.camel@mccallum.corsepiu.local> <44939AD5.8080001@knox.net.nz> Message-ID: >>>>> "MJK" == Michael J Knox writes: MJK> So how does this progress? At this point the operation and possibly even the composition of the packaging committee has not been finalized. So we'll need spot to weigh in; either he makes the decision as the sole component of the current committee or we finalize a committee make up, meeting schedule, quorum rule, voting process and such. - J< From rc040203 at freenet.de Sat Jun 17 07:29:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 09:29:43 +0200 Subject: [Fedora-packaging] Re: Namespace for cross-compilation tools? In-Reply-To: <44939AD5.8080001@knox.net.nz> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <44931932.2080906@knox.net.nz> <1150506868.12910.206.camel@mccallum.corsepiu.local> <1150515079.12910.217.camel@mccallum.corsepiu.local> <44939AD5.8080001@knox.net.nz> Message-ID: <1150529384.16123.23.camel@mccallum.corsepiu.local> On Sat, 2006-06-17 at 18:01 +1200, Michael J. Knox wrote: > Is this a storm in a tea cup? Yes, mostly. I've proposed a set of packages, which has not made any progress wrt. a review for almost 1/2 a year. Now, people start nitpicking/nagging on details, some of them don't understand. The next nitpicking I expect to happen is GCC using $prefix/$target_alias/, which tangles a defect/leak of the FHS. Then they will start nit-picking on the magic these spec files contain to work-around rpm's bugs wrt. handling foreign binaries. You probably will be able to relate why I feel really pissed about this. Ralf From nicolas.mailhot at laposte.net Sat Jun 17 09:45:25 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 17 Jun 2006 11:45:25 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150504967.12910.180.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> Message-ID: <1150537526.7377.3.camel@rousalka.dyndns.org> Le samedi 17 juin 2006 ? 02:42 +0200, Ralf Corsepius a ?crit : > On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote: > > On Fri, 16 Jun 2006 17:54:09 +0200, Ralf Corsepius wrote: > > > > > Forgot to mention the case I consider to be the most broken version: > > > * N.M%{?dist} > > > with unclear meaning of M > > > > > > E.g. these packages have just been released for FE6: > > > dejavu-fonts-2.7.0-0.15.fc6 > > > > The old pre-release case, where the most-significant part of release is > > made 0 and hence makes it possible to ship a final 2.7.0-1.fc6 in the > > future without bumping Epoch. > IMO, an over-engineered miss-feature in the guidelines. > > It prevents 3rd party packagers to supply packages. Otherwise, they > could resort to use: > 2.7.0-0%{?dist}.M So now they have to use 2.7.0-0.%{X}.%{alphatag}%{?dist} instead of 2.7.0-%{X}%{?dist}, and make sure their 0.%{X}.%{alphatag} il higher or equal than mine just as they'd have to make sure their %{X} would be higher or equal to mine. News at 11, what's broken ? -- 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 rc040203 at freenet.de Sat Jun 17 09:57:04 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 11:57:04 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150537526.7377.3.camel@rousalka.dyndns.org> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> <1150537526.7377.3.camel@rousalka.dyndns.org> Message-ID: <1150538225.16123.40.camel@mccallum.corsepiu.local> On Sat, 2006-06-17 at 11:45 +0200, Nicolas Mailhot wrote: > Le samedi 17 juin 2006 ? 02:42 +0200, Ralf Corsepius a ?crit : > > On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote: > > > On Fri, 16 Jun 2006 17:54:09 +0200, Ralf Corsepius wrote: > > > > > > > Forgot to mention the case I consider to be the most broken version: > > > > * N.M%{?dist} > > > > with unclear meaning of M > > > > > > > > E.g. these packages have just been released for FE6: > > > > dejavu-fonts-2.7.0-0.15.fc6 > > > > > > The old pre-release case, where the most-significant part of release is > > > made 0 and hence makes it possible to ship a final 2.7.0-1.fc6 in the > > > future without bumping Epoch. > > IMO, an over-engineered miss-feature in the guidelines. > > > > It prevents 3rd party packagers to supply packages. Otherwise, they > > could resort to use: > > 2.7.0-0%{?dist}.M > > So now they have to use 2.7.0-0.%{X}.%{alphatag}%{?dist} instead of > 2.7.0-%{X}%{?dist}, and make sure their 0.%{X}.%{alphatag} il higher or > equal than mine just as they'd have to make sure their %{X} would be > higher or equal to mine. > > News at 11, what's broken ? Your syntax is ambiguous and utterly error-prone. Ralf From nicolas.mailhot at laposte.net Sat Jun 17 10:24:34 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 17 Jun 2006 12:24:34 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150538225.16123.40.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> <1150537526.7377.3.camel@rousalka.dyndns.org> <1150538225.16123.40.camel@mccallum.corsepiu.local> Message-ID: <1150539874.7377.14.camel@rousalka.dyndns.org> Le samedi 17 juin 2006 ? 11:57 +0200, Ralf Corsepius a ?crit : > On Sat, 2006-06-17 at 11:45 +0200, Nicolas Mailhot wrote: > > Le samedi 17 juin 2006 ? 02:42 +0200, Ralf Corsepius a ?crit : > > > On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote: > > > > On Fri, 16 Jun 2006 17:54:09 +0200, Ralf Corsepius wrote: > > > > > > > > > Forgot to mention the case I consider to be the most broken version: > > > > > * N.M%{?dist} > > > > > with unclear meaning of M > > > > > > > > > > E.g. these packages have just been released for FE6: > > > > > dejavu-fonts-2.7.0-0.15.fc6 > > > > > > > > The old pre-release case, where the most-significant part of release is > > > > made 0 and hence makes it possible to ship a final 2.7.0-1.fc6 in the > > > > future without bumping Epoch. > > > IMO, an over-engineered miss-feature in the guidelines. > > > > > > It prevents 3rd party packagers to supply packages. Otherwise, they > > > could resort to use: > > > 2.7.0-0%{?dist}.M > > > > So now they have to use 2.7.0-0.%{X}.%{alphatag}%{?dist} instead of > > 2.7.0-%{X}%{?dist}, and make sure their 0.%{X}.%{alphatag} il higher or > > equal than mine just as they'd have to make sure their %{X} would be > > higher or equal to mine. > > > > News at 11, what's broken ? > > Your syntax is ambiguous and utterly error-prone. Meaning you don't like it but can't pull up any actual problem. That's how I translate your answer anyway, and it's not enough to make me drop common accepted practice and official FE naming guidelines. Have a nice week-end -- 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 bugs.michael at gmx.net Sat Jun 17 14:59:06 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 17 Jun 2006 16:59:06 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150504967.12910.180.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> Message-ID: <20060617165906.1d553293.bugs.michael@gmx.net> On Sat, 17 Jun 2006 02:42:47 +0200, Ralf Corsepius wrote: > On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote: > > On Fri, 16 Jun 2006 17:54:09 +0200, Ralf Corsepius wrote: > > > > > Forgot to mention the case I consider to be the most broken version: > > > * N.M%{?dist} > > > with unclear meaning of M > > > > > > E.g. these packages have just been released for FE6: > > > dejavu-fonts-2.7.0-0.15.fc6 > > > > The old pre-release case, where the most-significant part of release is > > made 0 and hence makes it possible to ship a final 2.7.0-1.fc6 in the > > future without bumping Epoch. > > IMO, an over-engineered miss-feature in the guidelines. > > It prevents 3rd party packagers to supply packages. That is certainly not true. > Otherwise, they could resort to use: > 2.7.0-0%{?dist}.M Why can't they just use the same versioning scheme? Why and when would they supply a package, which is in Core or Extras already, with an incompatible version than what either is in Core and Extras or will be in Core or Extras later? It is extremely inconvienient and tiresome for anyone, who works on packaging guidelines, to consider packaging scenarios for packagers who don't adhere to the same guidelines. > > > xscreensaver-5.00-7.1.fc6 > > > > This is bad. 7.1.fc6 is newer than 7.fc7. In general, '1' > 'f'. > > > > Q: Are N and M supposed to be ? > > > > Yes. _But_ it's only N{?dist} and 0.N{?dist} for pre-releases. > C.f. above. IMO, a defect of the guidelines and to be reconsider. > > Let's keep things simple, instead. Things would be simplified a lot if we didn't limit our own flexibilities in choosing package versions and if 3rd party packagers would not create conflicting packages. From tibbs at math.uh.edu Sat Jun 17 15:20:34 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 17 Jun 2006 10:20:34 -0500 Subject: [Fedora-packaging] Re: Namespace for cross-compilation tools? In-Reply-To: <1150529384.16123.23.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Sat, 17 Jun 2006 09:29:43 +0200") References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <44931932.2080906@knox.net.nz> <1150506868.12910.206.camel@mccallum.corsepiu.local> <1150515079.12910.217.camel@mccallum.corsepiu.local> <44939AD5.8080001@knox.net.nz> <1150529384.16123.23.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> I've proposed a set of packages, which has not made any progress RC> wrt. a review for almost 1/2 a year. I saw those old packages and thought some progress needed to be made. I'm sorry they sat for so long, I really am. But I saw an issue with the naming and came here to ask, as is the proper procedure. RC> Now, people start nitpicking/nagging on details, some of them RC> don't understand. And look at what I get. Yep, I don't understand enough to question Ralf's naming decisions. Or apparently any of his other decisions: RC> The next nitpicking I expect to happen is GCC using RC> $prefix/$target_alias/, which tangles a defect/leak of the FHS. Well, yes, if I were to be foolish enough to continue to attempt to review your packages, I would come back here with more questions if I had them. Which is what I understand that I'm supposed to do. So, Ralf, if you don't think anyone should question your packaging decisions, I really don't know what to tell you. Perhaps, "tough" is appropriate. If I see anything that's out of line with the current guidelines, anything that sets new precedent, any fancy specfile trick or rpm bug workaround that isn't commented, or even anything I don't understand (which I'll tell you now is quite a bit) then I'm going to question it. And that's a good thing. Why? Because that's how the process is supposed to work. Short of some committee somewhere passing a "Ralf's packages go right on through" rule, all of your packages are going to have to go through the review process. RC> You probably will be able to relate why I feel really pissed about RC> this. As far as I can see, the only thing you might have cause for being angry about is the fact that your packages sat there for six months. Which really is too bad, but this is a volunteer effort. And I will admit to looking at them several times in the past without acting on them, because being familiar with the tone of the messages I've seen from you in the past I knew I was going to be in for a rough time. But this time I thought to myself, "Hey, there's a packaging committee now. Both Ralf and I have been invited to join it, and spot must have confidence in our abilities to work together. So surely we can have a reasonable discussion about any issues I find." So here we are, and in all honesty I must say I'm a bit disappointed at the way things are working out. But I'm not in the least angry, and I an perfectly happy to keep working on your packages, and indeed to nitpick them to death if that's what it takes to get them into shape for Extras. - J< From bugs.michael at gmx.net Sat Jun 17 15:29:04 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 17 Jun 2006 17:29:04 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150505466.12910.190.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <20060617010345.8c442306.bugs.michael@gmx.net> <1150505466.12910.190.camel@mccallum.corsepiu.local> Message-ID: <20060617172904.45b8db5f.bugs.michael@gmx.net> On Sat, 17 Jun 2006 02:51:05 +0200, Ralf Corsepius wrote: > On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote: > > On Fri, 16 Jun 2006 10:02:25 -0500, Tom 'spot' Callaway wrote: > > > > > > Yes. There exist packagers who (In FE devel) > > > > * don't use %{?dist} at all > > > > * some use N%{?dist} and increment N with each iteration. > > > > > > These are correct... > > > > > > > * some use N%{?dist}.M and increment M with each build-iteration > > > > > > ...and these are not. More bugs to file! > > > > I disagree. It should be packager's freedom what to do in this > > least-significant position of the release field. > And I disagree, with this. > > Conversely: This kind of "freedom" is the cause for a lack of > simplicity, and the cause for the broken upstream path versioning errors > being reported. > With more restrictive conventions, these issues would not exist. > > > If this style of bumping release versions were not permitted, we would see > > more unneeded mass-rebuilds of a package for all dists only to keep the > > upgrade path sane when a new build for only an older dist is needed. > Why would that happen? Because packagers would bump the most-significant portion of the release field for _all_ dists and request builds for _all_ dists instead of only updating a single older dist release. > Make "N%{dist}.M" (w/ N,M ... int > 0) mandatory Above you said this scheme is a bug. Now I'm confused. I like and use N%{?dist}.M and the '0.' prefix for pre-releases. I also like the flexibility we get when we are permitted to move non-numerical bits out of %{version} and place them in %{release} instead. Our mission objectives: 1 - sane upgrade path in Core 2 - sane upgrade path in Extras 3 - sane upgrade path between Extras -> Core 4 - sane upgrade path between Core -> Extras Additionally, for entirely new packages, not in Core/Extras before, packagers may choose a suitable EVR which upgrades upstream packages. But once the package is in Core/Extras, there must not be any unexpected or confusing version changes, which bear the risk of creating a bad upgrade path. Note that the first two points are underestimated a lot, since preferably, for CD/ISO based upgrades, RPM version comparison for packages ought to be a strict FIRST_EVR(new_dist) > ALL_EVR(old_dist) for any pair of dists and all update packages for old_dist. In our scheme, this would be achieved by bumping the N in our N%{?dist}.M only with the release of a new distribution and M inbetween. N would then be newer than any N in any packge and an older dist. > and drop the pre/post-release stuff. Why drop the useful "post-release stuff" now, too? > I don't see how epoch bumps would ever be needed. E.g. when upstream's versioning scheme is incompatible with RPM's versioning scheme, particularly with pre- or post-release non-numerical pieces. From rc040203 at freenet.de Sat Jun 17 20:06:49 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 22:06:49 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <20060617165906.1d553293.bugs.michael@gmx.net> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> <20060617165906.1d553293.bugs.michael@gmx.net> Message-ID: <1150574810.16123.56.camel@mccallum.corsepiu.local> On Sat, 2006-06-17 at 16:59 +0200, Michael Schwendt wrote: > On Sat, 17 Jun 2006 02:42:47 +0200, Ralf Corsepius wrote: > > > On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote: > > > On Fri, 16 Jun 2006 17:54:09 +0200, Ralf Corsepius wrote: > > > > > > > Forgot to mention the case I consider to be the most broken version: > > > > * N.M%{?dist} > > > > with unclear meaning of M > > > > > > > > E.g. these packages have just been released for FE6: > > > > dejavu-fonts-2.7.0-0.15.fc6 > > > > > > The old pre-release case, where the most-significant part of release is > > > made 0 and hence makes it possible to ship a final 2.7.0-1.fc6 in the > > > future without bumping Epoch. > > > > IMO, an over-engineered miss-feature in the guidelines. > > > > It prevents 3rd party packagers to supply packages. > > That is certainly not true. > > > Otherwise, they could resort to use: > > 2.7.0-0%{?dist}.M > > Why can't they just use the same versioning scheme? > Why and when would they supply a package, which is in Core or Extras > already, with an incompatible version than what either is in Core and > Extras or will be in Core or Extras later E.g. because * legal restrictions prohibits Core or Extras to ship them * developers use repos to ship upstream snapshots for testing. * local demands require packages neither FC nor FE ships. * packages are stuck in FE review. etc. pp. > It is extremely inconvienient and tiresome for anyone, who works on > packaging guidelines, to consider packaging scenarios for packagers who > don't adhere to the same guidelines. 3rd parties would consider FE's guidelines, if they were simple and clear. Face it: So far they are not. I hereby formally ask YOU (MS) to write them up and give clear confirmative _directions_ of how FE 3rd party packagers shall chose NEVRs that are guaranteed not to conflict with FE nor FC. I clearly doubt you'll be able to do so. > > > > xscreensaver-5.00-7.1.fc6 > > > > > > This is bad. 7.1.fc6 is newer than 7.fc7. In general, '1' > 'f'. > > > > > > Q: Are N and M supposed to be ? > > > > > > Yes. _But_ it's only N{?dist} and 0.N{?dist} for pre-releases. > > C.f. above. IMO, a defect of the guidelines and to be reconsider. > > > > Let's keep things simple, instead. > > Things would be simplified a lot if we didn't limit our own flexibilities > in choosing package versions and if 3rd party packagers would not create > conflicting packages. How do you think are developers supposed to package packages? Ralf From rc040203 at freenet.de Sat Jun 17 20:31:32 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Jun 2006 22:31:32 +0200 Subject: [Fedora-packaging] Re: Namespace for cross-compilation tools? In-Reply-To: References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <44931932.2080906@knox.net.nz> <1150506868.12910.206.camel@mccallum.corsepiu.local> <1150515079.12910.217.camel@mccallum.corsepiu.local> <44939AD5.8080001@knox.net.nz> <1150529384.16123.23.camel@mccallum.corsepiu.local> Message-ID: <1150576292.16123.78.camel@mccallum.corsepiu.local> On Sat, 2006-06-17 at 10:20 -0500, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > RC> The next nitpicking I expect to happen is GCC using > RC> $prefix/$target_alias/, which tangles a defect/leak of the FHS. > > Well, yes, if I were to be foolish enough to continue to attempt to > review your packages, I would come back here with more questions if I > had them. Which is what I understand that I'm supposed to do. > > So, Ralf, if you don't think anyone should question your packaging > decisions, Questioning decison is one side of the medal, cluelessness is another one. The choice of package names is my decision, true, and is how we (rtems) ship them for many years. But the rest is not my decisions. It's how GCC cross-compilers work, ever since they exist. Cross-compilers are a bit more complex than native tools and impose demands the FHS and the FE guidelines don't cover. > I really don't know what to tell you. Perhaps, "tough" is > appropriate. "Though" is what I had expected and what I am willing to cope with, but ... cluelessness is hard to bare. > If I see anything that's out of line with the current > guidelines, anything that sets new precedent, any fancy specfile trick > or rpm bug workaround that isn't commented, or even anything I don't > understand (which I'll tell you now is quite a bit) then I'm going to > question it. > > And that's a good thing. Why? Because that's how the process is > supposed to work. Short of some committee somewhere passing a "Ralf's > packages go right on through" rule, Absolutely not. > all of your packages are going to > have to go through the review process. I am asking reviewers to *THINK*. Unfortunately, I feel some people prefer to take the Guidelines as God sent laws they try to stick to word by word. The Guidelines, the FHS and the LSB have been written by humans with limited horizons/knowledge, are full of inconsistencies and defects, which ought to be found and closed. > RC> You probably will be able to relate why I feel really pissed about > RC> this. > > As far as I can see, the only thing you might have cause for being > angry about is the fact that your packages sat there for six months. The fact you are missing: These package's history. > So here we are, and in all honesty I must say I'm a bit disappointed > at the way things are working out. Well, ... contribution to Fedora is disappointing and takes a very long breath ... Ralf From bugs.michael at gmx.net Sat Jun 17 22:26:39 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 18 Jun 2006 00:26:39 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150574810.16123.56.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> <20060617165906.1d553293.bugs.michael@gmx.net> <1150574810.16123.56.camel@mccallum.corsepiu.local> Message-ID: <20060618002639.2ae12bf6.bugs.michael@gmx.net> On Sat, 17 Jun 2006 22:06:49 +0200, Ralf Corsepius wrote: > > Why can't they just use the same versioning scheme? > > > Why and when would they supply a package, which is in Core or Extras > > already, with an incompatible version than what either is in Core and > > Extras or will be in Core or Extras later > > E.g. because > * legal restrictions prohibits Core or Extras to ship them > * developers use repos to ship upstream snapshots for testing. > * local demands require packages neither FC nor FE ships. > * packages are stuck in FE review. > etc. pp. You failed to answer why they would supply a package with "an incompatible version". The guidelines cannot fix that. > > It is extremely inconvienient and tiresome for anyone, who works on > > packaging guidelines, to consider packaging scenarios for packagers who > > don't adhere to the same guidelines. > 3rd parties would consider FE's guidelines, if they were simple and > clear. > > Face it: So far they are not. And won't ever be. Just take a look at the package naming guidelines and examples like "muse vs. emacs-muse vs. ...". The guidelines will never be bullet-proof in such a way that 3rd party package suppliers can do whatever they want without needing to track changes in FC+FE. Btw, "simple and clear" is so vague, it says nothing actually. > I hereby formally ask YOU (MS) to write them up and give clear > confirmative _directions_ of how FE 3rd party packagers shall chose > NEVRs that are guaranteed not to conflict with FE nor FC. > > I clearly doubt you'll be able to do so. With all due respect, this is silly, Ralf. It is trivial to supply packages which extend Core+Extras in a safe way _until_ the same packaged software is included in Core or Extras. While the 3rd party packager can make sure any chosen NEVR is compatible with existing packages in FC|FE, are Fedora Project package developers obliged to know about all packages which may be "out in the wild" at the time they add a package to FC|FE? I don't think so. But only then the fun starts, since you arrive in upgrade hell or with a conflict of some sort. FC|FE packages upgrade 3rd party packages or vice versa, packager picked a different release or snapshot, etc. And if the 3rd party packager continues supplying upgrades which replace stuff in FC|FE, who's to blame? Even if a 3rd party package bumped the Epoch in order to upgrade a FC|FE package _always_, it would continue being a conflict. And it is so easy to create conflicts despite adhering to the guidelines. The guidelines don't say which upstream version to put into package "libfoo", which other upstream release to put into package "libfoo20", and which release to put into "compat-foo". The guidelines won't fix that by becoming more "simple". The opposite won't be true either. The longer, the more detailed and more specific the guidelines get, the fewer packagers will be comfortable with them and every tiny detail. Even a trivial package would create a conflict if at the time it enters FC|FE it exists with a higher %{release} in an arbitrary 3rd party repository. > > > > > xscreensaver-5.00-7.1.fc6 > > > > > > > > This is bad. 7.1.fc6 is newer than 7.fc7. In general, '1' > 'f'. > > > > > > > > Q: Are N and M supposed to be ? > > > > > > > > Yes. _But_ it's only N{?dist} and 0.N{?dist} for pre-releases. > > > C.f. above. IMO, a defect of the guidelines and to be reconsider. > > > > > > Let's keep things simple, instead. > > > > Things would be simplified a lot if we didn't limit our own flexibilities > > in choosing package versions and if 3rd party packagers would not create > > conflicting packages. > > How do you think are developers supposed to package packages? Please rephrase. I don't understand the question. But let's try to add a comment. Maybe that explains it already: In my view, packagers need no stinking dist tag, and they only must ensure that their most recent package release is seen as an upgrade of every older package release. That is, when Joe User on up-to-date FC4+FE4 inserts the brand-new set of FC6+FE6 CDs, which he ordered at his popular online shop, all packages on the CDs are sufficiently "newer than" his up-to-date FC4 installation. From nicolas.mailhot at laposte.net Sun Jun 18 09:29:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 18 Jun 2006 11:29:46 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150574810.16123.56.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> <20060617165906.1d553293.bugs.michael@gmx.net> <1150574810.16123.56.camel@mccallum.corsepiu.local> Message-ID: <1150622986.4604.13.camel@rousalka.dyndns.org> Le samedi 17 juin 2006 ? 22:06 +0200, Ralf Corsepius a ?crit : > On Sat, 2006-06-17 at 16:59 +0200, Michael Schwendt wrote: > > Why and when would they supply a package, which is in Core or Extras > > already, with an incompatible version than what either is in Core and > > Extras or will be in Core or Extras later > E.g. because > * legal restrictions prohibits Core or Extras to ship them > * developers use repos to ship upstream snapshots for testing. The snapshot you're not happy about was/is shipped in devel, during at most one week, and is perfectly dogfoodable (not as good as the actual release will be, but not eating babies or anything like it). Please find another horse to beat. > * local demands require packages neither FC nor FE ships. > * packages are stuck in FE review. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From toshio at tiki-lounge.com Mon Jun 19 06:39:44 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 18 Jun 2006 23:39:44 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150154612.5199.282.camel@localhost.localdomain> References: <1150154612.5199.282.camel@localhost.localdomain> Message-ID: <1150699185.3885.56.camel@localhost> Here's a recap of the blocker issues as I see them presently standing: On Mon, 2006-06-12 at 18:23 -0500, Tom 'spot' Callaway wrote: > 1. Redefining libdir for mono packages: > If mono and its tools cannot find a library on a 64bit architecture when > it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken > on that architecture, and needs to be fixed. I think we're in agreement about this. But Paul Johnson (Nodoid) has run into some issues with this and making the packages noarch. A look at the lat approval: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177580 and the package in cvs shows that this is likely an overzealous configure.ac. Paul Howarth should ask upstream why they are using AC_CANONICAL_TARGET in their configure.ac. AFAICT there is no reason for it. Removing it from the spec and regenerating configure means that we do not have to play tricks with either %{_libdir} or %{_target_platform}. (Diff to lat.spec as attachment #1) > > 2. Putting DLLs in %{_datadir} vs %{_libdir}: > A) DLLs are mostly architecture independent. Testing of DLLImport appears to show that code that is not architecture independent has to be rewritten or it will fail at runtime on unsupported architectures. A simple recompile won't fix things. The simple test case that I used was a C library with a structure that contained an unsigned long type. In C, this can be a 32 bit or 64 bit value depending on the platform it is compiled on. In mono this structure is defined as either ulong or uint for 64bit or 32bit respectively. The mono code will fail to work correctly on the platform it is not coded for. Either the C library has to be coded to explicitly use a 32bit or a 64bit integer or the mono library will have to detect the number of bits at runtime and translate its values correctly before passing to C (I don't know how this is done but I've read that Mono's POSIX library does this.) I have no objection to DLLs being noarch due to this. Attachment #2 is a tarball of the code for my test case. Run make on an x86_64. The resulting files will run fine. Run make on an ix86. The resulting files will generate incorrect answers. B) Using Ahead-of-time compilation currently has to place the .so files in the same directory as the DLLs. Putting those into /usr/share is plainly wrong. We have two options: i) Explicitly do not support ahead of time compilation until mono can be enhanced to recognize an aot .so in a different directory [Is this in upstream's roadmap?] ii) Put DLLs in arch specific directories (somewhere under %{_libdir}). To test I used nant as my test program. This could probably be done with tomboy/banshee/etc as well. 1) cp -pr /usr/share/nant ~/nant 2) export MONO_PATH=$MONO_PATH:~/nant:~/nant/lib:~/nant/lib/mono:\ ~/nant/lib/mono/1.0:~nant/lib/mono/2.0:~/nant/lib/net/1.0:\ ~/nant/lib/net/1.1:~/nant/lib/net/2.0 3) cd ~/nant 4) sed 's^/usr/share/NAnt/bin^$HOME/nant^' < /usr/bin/nant > nant 5) mono --aot ./nant 6) strace ./nant &> aot-in-same-dir.log 7) strace /usr/bin/nant &> aot-in-monpath.log 8) Compare the two logs and notice that running our copy of nant that uses dlls from ~/nant finds the .dll.so files there. The system nant does not even though the .dll.so's are in MONO_PATH. > 3. Forcing local copies of DLL libraries instead of using system > installed DLLs. Everyone is against this. So far, we've only discovered one possible instance of this in banshee. We have a list of possible ways to check for this but it isn't foolproof. We would like the monoproject to rethink their position. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: lat.spec.diff Type: text/x-patch Size: 1463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test-mono.tar.gz Type: application/x-compressed-tar Size: 662 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon Jun 19 06:55:38 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Jun 2006 08:55:38 +0200 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150699185.3885.56.camel@localhost> References: <1150154612.5199.282.camel@localhost.localdomain> <1150699185.3885.56.camel@localhost> Message-ID: <1150700138.31371.0.camel@rousalka.dyndns.org> Le dimanche 18 juin 2006 ? 23:39 -0700, Toshio Kuratomi a ?crit : > Put DLLs > in arch specific directories (somewhere under %{_libdir}). This is what Java does -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From toshio at tiki-lounge.com Mon Jun 19 15:15:52 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 19 Jun 2006 08:15:52 -0700 Subject: [Fedora-packaging] Mono Packaging Issues In-Reply-To: <1150700138.31371.0.camel@rousalka.dyndns.org> References: <1150154612.5199.282.camel@localhost.localdomain> <1150699185.3885.56.camel@localhost> <1150700138.31371.0.camel@rousalka.dyndns.org> Message-ID: <1150730154.10353.13.camel@localhost> On Mon, 2006-06-19 at 08:55 +0200, Nicolas Mailhot wrote: > Le dimanche 18 juin 2006 ? 23:39 -0700, Toshio Kuratomi a ?crit : > > Put DLLs > > in arch specific directories (somewhere under %{_libdir}). > > This is what Java does > I think this is a little different from java (Note: You are a java packager and I'm not, so correct me if I'm wrong.) In java, the jars go into %{_javadir} which is defined as %{_datadir}/java. Most jars are compiled to native code which goes somewhere under %{_libdir}. Because mono is only checking for precompiled DLLs in the same directory as the DLL you can't separate the DLLs from the dll.so's as you can JARS from jar.so's. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Jun 20 04:08:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Jun 2006 06:08:51 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <20060618002639.2ae12bf6.bugs.michael@gmx.net> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> <20060617165906.1d553293.bugs.michael@gmx.net> <1150574810.16123.56.camel@mccallum.corsepiu.local> <20060618002639.2ae12bf6.bugs.michael@gmx.net> Message-ID: <1150776532.21231.13.camel@mccallum.corsepiu.local> On Sun, 2006-06-18 at 00:26 +0200, Michael Schwendt wrote: > On Sat, 17 Jun 2006 22:06:49 +0200, Ralf Corsepius wrote: > > > > Why can't they just use the same versioning scheme? > > > > > Why and when would they supply a package, which is in Core or Extras > > > already, with an incompatible version than what either is in Core and > > > Extras or will be in Core or Extras later > > > > E.g. because > > * legal restrictions prohibits Core or Extras to ship them > > * developers use repos to ship upstream snapshots for testing. > > * local demands require packages neither FC nor FE ships. > > * packages are stuck in FE review. > > etc. pp. > > You failed to answer why they would supply a package with "an incompatible > version". YOU were talking about "incompatible", I didn't. Conversely, I am talking about "compatible replacement packages" and "add-ons". > > > It is extremely inconvienient and tiresome for anyone, who works on > > > packaging guidelines, to consider packaging scenarios for packagers who > > > don't adhere to the same guidelines. > > 3rd parties would consider FE's guidelines, if they were simple and > > clear. > > > > Face it: So far they are not. > > And won't ever be. You can. It's only matter of conventions. > Just take a look at the package naming guidelines > and examples like "muse vs. emacs-muse vs. ...". The guidelines will > never be bullet-proof in such a way that 3rd party package suppliers > can do whatever they want without needing to track changes in FC+FE. True, but .. this is the "Name" in NEVR. This could be handled by examples on a case by case basis. > > I hereby formally ask YOU (MS) to write them up and give clear > > confirmative _directions_ of how FE 3rd party packagers shall chose > > NEVRs that are guaranteed not to conflict with FE nor FC. > > > > I clearly doubt you'll be able to do so. > > With all due respect, this is silly, Ralf. It is trivial to supply > packages which extend Core+Extras in a safe way _until_ the same packaged > software is included in Core or Extras. How? Explain, elaborate ... that's what I am asking. > While the 3rd party packager can make sure any chosen NEVR is compatible > with existing packages in FC|FE, are Fedora Project package developers > obliged to know about all packages which may be "out in the wild" at the > time they add a package to FC|FE? With a little good will, reflected into conventions, they could. > > > > > > xscreensaver-5.00-7.1.fc6 > > > > > > > > > > This is bad. 7.1.fc6 is newer than 7.fc7. In general, '1' > 'f'. > > > > > > > > > > Q: Are N and M supposed to be ? > > > > > > > > > > Yes. _But_ it's only N{?dist} and 0.N{?dist} for pre-releases. > > > > C.f. above. IMO, a defect of the guidelines and to be reconsider. > > > > > > > > Let's keep things simple, instead. > > > > > > Things would be simplified a lot if we didn't limit our own flexibilities > > > in choosing package versions and if 3rd party packagers would not create > > > conflicting packages. > > > > How do you think are developers supposed to package packages? > > Please rephrase. I don't understand the question. I wanted you to clearly describe in detail, how packagers (Core, Extra and 3rd party) are supposed to chose "Version-Release", which is guaranteed to be safe. > But let's try to add a comment. Maybe that explains it already: > > In my view, packagers need no stinking dist tag, My view is opposite: Not having a mandatory dist tag is a design flaw. > and they only must ensure > that their most recent package release is seen as an upgrade of every > older package release. That is, when Joe User on up-to-date FC4+FE4 > inserts the brand-new set of FC6+FE6 CDs, which he ordered at his popular > online shop, all packages on the CDs are sufficiently "newer than" his > up-to-date FC4 installation. If Release was chosen N%{dist}.M (N, M .. int) this would happen automatically and the user would not have to care about anything. Ralf From rc040203 at freenet.de Tue Jun 20 04:16:35 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Jun 2006 06:16:35 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150622986.4604.13.camel@rousalka.dyndns.org> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> <20060617165906.1d553293.bugs.michael@gmx.net> <1150574810.16123.56.camel@mccallum.corsepiu.local> <1150622986.4604.13.camel@rousalka.dyndns.org> Message-ID: <1150776995.21231.20.camel@mccallum.corsepiu.local> On Sun, 2006-06-18 at 11:29 +0200, Nicolas Mailhot wrote: > Le samedi 17 juin 2006 ? 22:06 +0200, Ralf Corsepius a ?crit : > > On Sat, 2006-06-17 at 16:59 +0200, Michael Schwendt wrote: > > > > Why and when would they supply a package, which is in Core or Extras > > > already, with an incompatible version than what either is in Core and > > > Extras or will be in Core or Extras later > > E.g. because > > * legal restrictions prohibits Core or Extras to ship them > > * developers use repos to ship upstream snapshots for testing. > > The snapshot you're not happy about was/is shipped in devel, during at > most one week, and is perfectly dogfoodable Well, have a look into kde's versions in Core: 3.5.3-0.2.fc5 # rpmver 3.5.3-0.2.fc5 3.5.2-0.2.1.fc5 3.5.3-0.2.fc5 is newer # rpmver 3.5.3-0.2.fc5 3.5.2-0.2.fc5.1 3.5.3-0.2.fc5 is newer Now tell me how to recompile a package from the same sources, but with small local modifications (e.g. for testing a patch addressing a bug). 3.5.3-0.3.fc5 would do, but that's not a solution to the problem, because it's the V-R being reserved for the next official update. Ralf From bugs.michael at gmx.net Tue Jun 20 12:46:14 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Jun 2006 14:46:14 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150776532.21231.13.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> <20060617165906.1d553293.bugs.michael@gmx.net> <1150574810.16123.56.camel@mccallum.corsepiu.local> <20060618002639.2ae12bf6.bugs.michael@gmx.net> <1150776532.21231.13.camel@mccallum.corsepiu.local> Message-ID: <20060620144614.0157d6c4.bugs.michael@gmx.net> On Tue, 20 Jun 2006 06:08:51 +0200, Ralf Corsepius wrote: > On Sun, 2006-06-18 at 00:26 +0200, Michael Schwendt wrote: > > On Sat, 17 Jun 2006 22:06:49 +0200, Ralf Corsepius wrote: > > > > > > Why can't they just use the same versioning scheme? > > > > > > > Why and when would they supply a package, which is in Core or Extras > > > > already, with an incompatible version than what either is in Core and > > > > Extras or will be in Core or Extras later > > > > > > E.g. because > > > * legal restrictions prohibits Core or Extras to ship them > > > * developers use repos to ship upstream snapshots for testing. > > > * local demands require packages neither FC nor FE ships. > > > * packages are stuck in FE review. > > > etc. pp. > > > > You failed to answer why they would supply a package with "an incompatible > > version". > YOU were talking about "incompatible", Because that's what many 3rd party packagers do. They provide packages which either are incompatible one way or the other or will be incompatible with future packages in FC+FE. > I didn't. Conversely, I am > talking about "compatible replacement packages" and "add-ons". Replacement packages are inherently incompatible. Not only do they add something to the package namespace, they also take away something. > > > > It is extremely inconvienient and tiresome for anyone, who works on > > > > packaging guidelines, to consider packaging scenarios for packagers who > > > > don't adhere to the same guidelines. > > > 3rd parties would consider FE's guidelines, if they were simple and > > > clear. > > > > > > Face it: So far they are not. > > > > And won't ever be. > You can. It's only matter of conventions. It's called Utopia. guidelines are too simple => too much room for different interpretations guidelines are too complex => too much familiarity needed, too much time needed to study each and every detail in order to get everything right in a predictable manner > > Just take a look at the package naming guidelines > > and examples like "muse vs. emacs-muse vs. ...". The guidelines will > > never be bullet-proof in such a way that 3rd party package suppliers > > can do whatever they want without needing to track changes in FC+FE. > > True, but .. this is the "Name" in NEVR. qed ;) > This could be handled by examples on a case by case basis. Then get 3rd party packagers to _ask_ the Fedora Packaging Committee prior to introducing new packages into the Fedora package universa. > > > I hereby formally ask YOU (MS) to write them up and give clear > > > confirmative _directions_ of how FE 3rd party packagers shall chose > > > NEVRs that are guaranteed not to conflict with FE nor FC. > > > > > > I clearly doubt you'll be able to do so. > > > > With all due respect, this is silly, Ralf. It is trivial to supply > > packages which extend Core+Extras in a safe way _until_ the same packaged > > software is included in Core or Extras. > > How? Explain, elaborate ... that's what I am asking. Do you ignore the "_until_" deliberately because you're in a mood to argue? Everyone can take a new libfoozooboo and a corresponding application, create rpms for it and offer it as an clean add-on to FC+FE without overwriting or replacing any packages. Where's the problem? The problems start when a Fedora contributor packages the same or a different version of this software for FC|FE. What problems? Too many to cover them in detail, not limited to: Different N in NEVR (some 3rd party packagers just love the SONAME major version in N game), too high EVR, too high VR, too high R, upgrade race back and forth between Fedora and 3rd party repo, files in sub-packages vs. files in main package, different feature set, broken libtool archives included or not, ... moan, gah! > > While the 3rd party packager can make sure any chosen NEVR is compatible > > with existing packages in FC|FE, are Fedora Project package developers > > obliged to know about all packages which may be "out in the wild" at the > > time they add a package to FC|FE? > > With a little good will, reflected into conventions, they could. The more often you claim this, the more likely it becomes that you will need to submit a proposal. Accept the offer to join the Fedora Packaging Committee and work on this. > I wanted you to clearly describe in detail, how packagers (Core, Extra > and 3rd party) are supposed to chose "Version-Release", which is > guaranteed to be safe. 1) Core and Extras packagers monitor eachother. That's a MUST for any package which moves from Core to Extras or vice versa. Else a rushed upgrade in Extras for an older dist might be newer than the package in a more recent release of Core (or vice versa). Has happened before, will happen again. 2) The packaging guidelines and versioning scheme are publicly available for everyone to take a look at and adhere to. 3) As a 3rd party packager, DO NOT set Epoch, not even if any contributed upstream package has Epoch > 0. 4) You need not choose a VR which increases the risk of being newer than a future package in FC|FE. Avoid the mess with non-numerical pieces in V. 5) 3rd party packagers NEED to decide whether to upgrade FC+FE always (Epoch can be used as well as a sufficiently high R, e.g. R=1000) or whether to supply pre-release types of packages, which are upgraded by FC|FE as soon as the package is included in FC|FE (keep the most-significant part of R = 0.0%{?dist}.X and increment only the least-significant part X). > > In my view, packagers need no stinking dist tag, > > My view is opposite: Not having a mandatory dist tag is a design flaw. Because of what? > > and they only must ensure > > that their most recent package release is seen as an upgrade of every > > older package release. That is, when Joe User on up-to-date FC4+FE4 > > inserts the brand-new set of FC6+FE6 CDs, which he ordered at his popular > > online shop, all packages on the CDs are sufficiently "newer than" his > > up-to-date FC4 installation. > > If Release was chosen N%{dist}.M (N, M .. int) this would happen > automatically and the user would not have to care about anything. No. Think twice. It fails when a new V of an update for an old dist becomes higher than V for a stock package of a new dist. In that case, only Epoch=dist would be the way out. FC4: foo-1.0-4.1 FC4 updates: 1.0-4.2, 1.0-4.3, ..., 1.2-4.1 (ooops! newer than stock FC5) FC5: foo-1.0-5.2 FC5 updates: 1.0-5.3, 1.0-5.4, ... 1.2-5.1 (!) You could also include %{?dist} and move it to the very left, creating fun for 3rd party packagers who don't use the same dist tags. Nothing new. Just fails due to V bumps, and due to E being used by some packages already for purposes other than E=dist. A "Distribution Epoch" in the RPM header would be the cure. ;) From bugs.michael at gmx.net Tue Jun 20 12:48:48 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Jun 2006 14:48:48 +0200 Subject: [Fedora-packaging] Re: [Bug 192912] Review Request: paps In-Reply-To: <1150776995.21231.20.camel@mccallum.corsepiu.local> References: <200606150653.k5F6rQUn016161@bugzilla.redhat.com> <1150439713.12910.65.camel@mccallum.corsepiu.local> <1150461864.22820.21.camel@localhost.localdomain> <1150463355.12910.116.camel@mccallum.corsepiu.local> <1150464338.32654.26.camel@ender> <1150465194.12910.126.camel@mccallum.corsepiu.local> <1150466147.22820.65.camel@localhost.localdomain> <1150469373.12910.142.camel@mccallum.corsepiu.local> <1150470146.22820.70.camel@localhost.localdomain> <1150473250.12910.162.camel@mccallum.corsepiu.local> <20060617010356.9f256a88.bugs.michael@gmx.net> <1150504967.12910.180.camel@mccallum.corsepiu.local> <20060617165906.1d553293.bugs.michael@gmx.net> <1150574810.16123.56.camel@mccallum.corsepiu.local> <1150622986.4604.13.camel@rousalka.dyndns.org> <1150776995.21231.20.camel@mccallum.corsepiu.local> Message-ID: <20060620144848.3644ae49.bugs.michael@gmx.net> On Tue, 20 Jun 2006 06:16:35 +0200, Ralf Corsepius wrote: > On Sun, 2006-06-18 at 11:29 +0200, Nicolas Mailhot wrote: > > Le samedi 17 juin 2006 ? 22:06 +0200, Ralf Corsepius a ?crit : > > > On Sat, 2006-06-17 at 16:59 +0200, Michael Schwendt wrote: > > > > > > Why and when would they supply a package, which is in Core or Extras > > > > already, with an incompatible version than what either is in Core and > > > > Extras or will be in Core or Extras later > > > E.g. because > > > * legal restrictions prohibits Core or Extras to ship them > > > * developers use repos to ship upstream snapshots for testing. > > > > The snapshot you're not happy about was/is shipped in devel, during at > > most one week, and is perfectly dogfoodable > > Well, have a look into kde's versions in Core: > 3.5.3-0.2.fc5 > > # rpmver 3.5.3-0.2.fc5 3.5.2-0.2.1.fc5 > 3.5.3-0.2.fc5 is newer Typo? 3.5.2 vs. 3.5.3 > # rpmver 3.5.3-0.2.fc5 3.5.2-0.2.fc5.1 > 3.5.3-0.2.fc5 is newer Same here. 3.5.3-0.2.fc5.1 is the way to go. > Now tell me how to recompile a package from the same sources, but with > small local modifications (e.g. for testing a patch addressing a bug). > > 3.5.3-0.3.fc5 would do, but that's not a solution to the problem, > because it's the V-R being reserved for the next official update. > > Ralf > > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- Michael Schwendt Fedora Core release 5 (Bordeaux) - Linux 2.6.16-1.2133_FC5 loadavg: 1.05 1.02 1.00 From toshio at tiki-lounge.com Tue Jun 20 19:19:06 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 20 Jun 2006 12:19:06 -0700 Subject: [Fedora-packaging] libexecdir, rpmlint, and Packaging Guidelines Message-ID: <1150831146.3365.36.camel@localhost> I would like to have clarification of whether using libexec is in accordance with the Fedora Guidelines or if packages using it should be changed. The usage of libexecdir for binary programs (not libraries) which are not intended to be invoked by users, just other programs (gnome panel applets are an example) is currently part of Fedora Core, the *BSDs, and the GNU Coding Standards. The FHS had libexecdir in a draft at one point but apparently dropped it after a poll (The FHS mailing list archives are currently inaccessible so I can't verify this) Debian has been vehement in its following the letter of the FHS so they set libexecdir to /usr/lib/pkgname through configure. If we decide libexec is not allowed we should consider doing the same with our %configure macro. There have been several email threads related to libexecdir vs the FHS on the fedora lists. The last one I recall is here: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/25433/ The thread brings up an issue which similar discussions on Debian mailing lists fail to mention (because Debian is not multilib): On multilib, you want one version of a helper program that matches the wordsize of the main program, not one for 32 bits in /usr/lib and another for 64 bits in /usr/lib64. Thus /usr/libexec to match /usr/bin. There have been several people who have said they intended to bring the libexec lack to the attention of the FHS but with their mailing list inaccessible I'm unable to check whether any discussion reached the FHS. -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 Tue Jun 20 19:42:26 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 20 Jun 2006 14:42:26 -0500 Subject: [Fedora-packaging] libexecdir, rpmlint, and Packaging Guidelines In-Reply-To: <1150831146.3365.36.camel@localhost> (Toshio Kuratomi's message of "Tue, 20 Jun 2006 12:19:06 -0700") References: <1150831146.3365.36.camel@localhost> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> I would like to have clarification of whether using libexec is in TK> accordance with the Fedora Guidelines or if packages using it TK> should be changed. I've asked previously on IRC and was told that it was OK. Let me see if I still have the logs. Oh, it was you who answered me. So this isn't terribly useful, but since I dug it up.... [Tue May 16 2006] [15:24:08] So it should either go in /usr/share or /usr/libexec [Tue May 16 2006] [15:24:28] We don't use /usr/libexec, do we? I thought it was heavily discouraged. [Tue May 16 2006] [15:24:43] Of course there's piles of stuff in it. [Tue May 16 2006] [15:24:47] tibbs: We do in fedora. [Tue May 16 2006] [15:24:59] tibbs: It's other distros where it's heavily discouraged. [Tue May 16 2006] [15:25:38] rpmlint does complain about libexec however. [Tue May 16 2006] [15:25:40] /usr/libexec should be fine for binaries and stuff not directly called by the user. according to FHS at least. - J< From toshio at tiki-lounge.com Tue Jun 20 20:03:57 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 20 Jun 2006 13:03:57 -0700 Subject: [Fedora-packaging] libexecdir, rpmlint, and Packaging Guidelines In-Reply-To: References: <1150831146.3365.36.camel@localhost> Message-ID: <1150833837.3365.45.camel@localhost> On Tue, 2006-06-20 at 14:42 -0500, Jason L Tibbitts III wrote: > >>>>> "TK" == Toshio Kuratomi writes: > > TK> I would like to have clarification of whether using libexec is in > TK> accordance with the Fedora Guidelines or if packages using it > TK> should be changed. > > I've asked previously on IRC and was told that it was OK. Let me see > if I still have the logs. Oh, it was you who answered me. So this > isn't terribly useful, but since I dug it up.... > Yes. I've been working under the impression that libexec is fine because the Core packagers have expressed good reasons for it to exist... but rpmlint complains about it. Ville's position (correct IMO) is that rpmlint should follow FHS unless there's a specific exception in the Guidelines so it seemed time to formalize whether it's allowed or not. > [Tue May 16 2006] [15:25:38] > rpmlint does complain about libexec however. > > [Tue May 16 2006] [15:25:40] > /usr/libexec should be fine for binaries and stuff not directly > called by the user. according to FHS at least. Hmm.. Is Andreas on this list? I don't see where the FHS allows for this. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Tue Jun 20 20:09:57 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Jun 2006 16:09:57 -0400 Subject: [Fedora-packaging] libexecdir, rpmlint, and Packaging Guidelines In-Reply-To: <1150833837.3365.45.camel@localhost> References: <1150831146.3365.36.camel@localhost> <1150833837.3365.45.camel@localhost> Message-ID: <1150834197.18766.25.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-06-20 at 13:03 -0700, Toshio Kuratomi wrote: > Yes. I've been working under the impression that libexec is fine > because the Core packagers have expressed good reasons for it to > exist... but rpmlint complains about it. Ville's position (correct IMO) > is that rpmlint should follow FHS unless there's a specific exception in > the Guidelines so it seemed time to formalize whether it's allowed or > not. I certainly feel that this is a worthy exception in the Guidelines. The use of libexec has good reason is is not going to change. rpmlint should take note of this (: -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue Jun 20 23:06:07 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 21 Jun 2006 01:06:07 +0200 Subject: [Fedora-packaging] Re: libexecdir, rpmlint, and Packaging Guidelines In-Reply-To: <1150831146.3365.36.camel@localhost> References: <1150831146.3365.36.camel@localhost> Message-ID: <20060620230607.GA32122@neu.nirvana> On Tue, Jun 20, 2006 at 12:19:06PM -0700, Toshio Kuratomi wrote: > I would like to have clarification of whether using libexec is in > accordance with the Fedora Guidelines or if packages using it should be > changed. FWIW libexec is briefly mentioned within RHEL documentation about FHS. It could be considered an API description of RHEL and since we'd like RHEL to remain closely related to Fedora Core, it would make any change of current libexec practices even harder. IMHO the best thing would be to get someone on the FHS list and promote the resurrection of libexec. > The usage of libexecdir for binary programs (not libraries) which are > not intended to be invoked by users, just other programs (gnome panel > applets are an example) is currently part of Fedora Core, the *BSDs, and > the GNU Coding Standards. The FHS had libexecdir in a draft at one > point but apparently dropped it after a poll (The FHS mailing list > archives are currently inaccessible so I can't verify this) Debian has > been vehement in its following the letter of the FHS so they set > libexecdir to /usr/lib/pkgname through configure. If we decide libexec > is not allowed we should consider doing the same with our %configure > macro. > > There have been several email threads related to libexecdir vs the FHS > on the fedora lists. The last one I recall is here: > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/25433/ > > The thread brings up an issue which similar discussions on Debian > mailing lists fail to mention (because Debian is not multilib): On > multilib, you want one version of a helper program that matches the > wordsize of the main program, not one for 32 bits in /usr/lib and > another for 64 bits in /usr/lib64. Thus /usr/libexec to match /usr/bin. > > There have been several people who have said they intended to bring the > libexec lack to the attention of the FHS but with their mailing list > inaccessible I'm unable to check whether any discussion reached the FHS. > > -Toshio -- 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 21 02:51:53 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 Jun 2006 04:51:53 +0200 Subject: [Fedora-packaging] libexecdir, rpmlint, and Packaging Guidelines In-Reply-To: <1150831146.3365.36.camel@localhost> References: <1150831146.3365.36.camel@localhost> Message-ID: <1150858314.29303.137.camel@mccallum.corsepiu.local> On Tue, 2006-06-20 at 12:19 -0700, Toshio Kuratomi wrote: > I would like to have clarification of whether using libexec is in > accordance with the Fedora Guidelines or if packages using it should be > changed. > > The usage of libexecdir for binary programs (not libraries) which are > not intended to be invoked by users, just other programs (gnome panel > applets are an example) Another example is GCC > is currently part of Fedora Core, the *BSDs, and > the GNU Coding Standards. > The FHS had libexecdir in a draft at one > point but apparently dropped it after a poll (The FHS mailing list > archives are currently inaccessible so I can't verify this) Debian has > been vehement in its following the letter of the FHS so they set > libexecdir to /usr/lib/pkgname through configure. This won't work for GCC GCC is using using: 1) /usr/lib/gcc/$target and 2) /usr/libexec/gcc/$target 1) contains target libraries/files 2) contains internal host-executables Setting libexecdir=$libdir would screw up things badly, because it would mix up host-executables and target-files. Now one could argue that 1) actually should be /usr/share/gcc/$target and 2) should be /usr/lib/gcc/$target ... I am inclined to agree, but changing this would be a major effort. > If we decide libexec > is not allowed we should consider doing the same with our %configure > macro. I am opposed to both. > There have been several email threads related to libexecdir vs the FHS > on the fedora lists. The last one I recall is here: > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/25433/ > > The thread brings up an issue which similar discussions on Debian > mailing lists fail to mention (because Debian is not multilib): On > multilib, you want one version of a helper program that matches the > wordsize of the main program, not one for 32 bits in /usr/lib and > another for 64 bits in /usr/lib64. Thus /usr/libexec to match /usr/bin. Exactly. The /usr/lib in 1) above needs to be $(prefix)/lib (=/usr/lib) not % _libdir. > There have been several people who have said they intended to bring the > libexec lack to the attention of the FHS but with their mailing list > inaccessible I'm unable to check whether any discussion reached the FHS. ... Ralf From paul at all-the-johnsons.co.uk Wed Jun 21 07:16:33 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 21 Jun 2006 08:16:33 +0100 Subject: [Fedora-packaging] Mono conversations Message-ID: <1150874193.22485.10.camel@T7.Linux> Hi, After the release of monodoc-1.1.13-12, there was some discussion on the FE list about the packaging of it, and in particular the AC_CANON bits that had been suggested. Due to this, it was suggested to move monodoc back to review - I managed to persuade the original reviewer not to do this as the suggestions made had been from IRC discussion and packaging discussions. The discussion thread can be found here https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00835.html Would anyone care to comment on the discussion? I've not altered monodoc yet and haven't played with the other 2 in the AC_CANON triple due to a requirement to sleep! While we're on the subject, could someone else please report the noarch rpm bug? I kept getting it closed as not a bug. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 Wed Jun 21 12:31:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 Jun 2006 07:31:49 -0500 Subject: [Fedora-packaging] -devel rpms with pkgconfig files should 'Requires: pkgconfig' Message-ID: <44993C35.6000408@math.unl.edu> Currently on http://fedoraproject.org/wiki/Packaging/ReviewGuidelines it includes: - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. I'd suggest amending this to say (something like) - MUST: Files used by pkgconfig (.pc files) must be in a -devel package, and the -devel package include 'Requires: pkgconfig' We've got quite a few such packages, and lots of things will break when FE switches to the minimal buildroot that no longer includes pkgconfig. -- Rex From jkeating at redhat.com Wed Jun 21 13:16:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Jun 2006 09:16:28 -0400 Subject: [Fedora-packaging] -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <44993C35.6000408@math.unl.edu> References: <44993C35.6000408@math.unl.edu> Message-ID: <1150895788.2398.5.camel@ender> On Wed, 2006-06-21 at 07:31 -0500, Rex Dieter wrote: > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > it includes: > - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. > > I'd suggest amending this to say (something like) > - MUST: Files used by pkgconfig (.pc files) must be in a -devel package, > and the -devel package include 'Requires: pkgconfig' > > We've got quite a few such packages, and lots of things will break when > FE switches to the minimal buildroot that no longer includes pkgconfig. I'm not so sure I agree with this. The -devel packages can be used w/out pkgconfig and many are. Forcing pkgconfig on other packages may not be the best case. I feel that if you are building a package, and THAT package needs to make use of pkg-config to find the right things, then that package should BuildRequires: pkgconfig. -- Jesse Keating Release Engineer: Fedora -------------- 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 Wed Jun 21 13:22:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 Jun 2006 08:22:26 -0500 Subject: [Fedora-packaging] -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <1150895788.2398.5.camel@ender> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> Message-ID: <44994812.5020207@math.unl.edu> Jesse Keating wrote: > On Wed, 2006-06-21 at 07:31 -0500, Rex Dieter wrote: >> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines >> it includes: >> - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. >> >> I'd suggest amending this to say (something like) >> - MUST: Files used by pkgconfig (.pc files) must be in a -devel package, >> and the -devel package include 'Requires: pkgconfig' >> >> We've got quite a few such packages, and lots of things will break when >> FE switches to the minimal buildroot that no longer includes pkgconfig. > > I'm not so sure I agree with this. The -devel packages can be used > w/out pkgconfig and many are. Most -devel packages with .pc files (that I'm aware of) can *not* be used w/out pkgconfig. > Forcing pkgconfig on other packages may not be the best case. pkgconfig is small and pulls in no additional dependencies. I see no downside. -- Rex From rdieter at math.unl.edu Wed Jun 21 13:28:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 Jun 2006 08:28:08 -0500 Subject: [Fedora-packaging] -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <44994812.5020207@math.unl.edu> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> Message-ID: <44994968.4040005@math.unl.edu> Rex Dieter wrote: > Jesse Keating wrote: >> On Wed, 2006-06-21 at 07:31 -0500, Rex Dieter wrote: >>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines >>> it includes: >>> - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. >>> >>> I'd suggest amending this to say (something like) >>> - MUST: Files used by pkgconfig (.pc files) must be in a -devel >>> package, and the -devel package include 'Requires: pkgconfig' >>> >>> We've got quite a few such packages, and lots of things will break >>> when FE switches to the minimal buildroot that no longer includes >>> pkgconfig. >> >> I'm not so sure I agree with this. The -devel packages can be used >> w/out pkgconfig and many are. > > Most -devel packages with .pc files (that I'm aware of) can *not* be > used w/out pkgconfig. Let me rephrase, apps that BR: -devel packages that support pkg-config (most) often (need to) use pkg-config to detect the presense of the -devel package. -- Rex From rdieter at math.unl.edu Wed Jun 21 13:45:43 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 Jun 2006 08:45:43 -0500 Subject: [Fedora-packaging] -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <44994968.4040005@math.unl.edu> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> Message-ID: <44994D87.6000804@math.unl.edu> Rex Dieter wrote: > Rex Dieter wrote: >> Jesse Keating wrote: >>> On Wed, 2006-06-21 at 07:31 -0500, Rex Dieter wrote: >>>> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines >>>> it includes: >>>> - MUST: Files used by pkgconfig (.pc files) must be in a -devel >>>> package. >>>> >>>> I'd suggest amending this to say (something like) >>>> - MUST: Files used by pkgconfig (.pc files) must be in a -devel >>>> package, and the -devel package include 'Requires: pkgconfig' >>>> >>>> We've got quite a few such packages, and lots of things will break >>>> when FE switches to the minimal buildroot that no longer includes >>>> pkgconfig. >>> >>> I'm not so sure I agree with this. The -devel packages can be used >>> w/out pkgconfig and many are. >> >> Most -devel packages with .pc files (that I'm aware of) can *not* be >> used w/out pkgconfig. > > Let me rephrase, apps that BR: -devel packages that support pkg-config > (most) often (need to) use pkg-config to detect the presense of the > -devel package. In particular, every app that uses auto* tools, and uses the PKG_CHECK_MODULES macro in ./configure. I can vouge that this includes *every* kde application I know. Please don't force app packagers to have to figure out if their ./configure script(s) use this macro or not, I'd much rather things "just work". -- Rex From jkeating at redhat.com Wed Jun 21 14:57:07 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Jun 2006 10:57:07 -0400 Subject: [Fedora-packaging] -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <44994D87.6000804@math.unl.edu> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> Message-ID: <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> On Wed, 2006-06-21 at 08:45 -0500, Rex Dieter wrote: > Please don't force app packagers to > have to figure out if their ./configure script(s) use this macro or not, > I'd much rather things "just work". I do believe this was similar to the same argument that led to buildroots being full installs. Don't make app packages figure out what package names they need in the build root, instead make it "just work". -- Jesse Keating Release Engineer: Fedora -------------- 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 Wed Jun 21 16:02:39 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 Jun 2006 11:02:39 -0500 Subject: [Fedora-packaging] Re: -devel rpms with pkgconfig files should 'Requires: pkgconfig' References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> Message-ID: Jesse Keating wrote: > On Wed, 2006-06-21 at 08:45 -0500, Rex Dieter wrote: >> Please don't force app packagers to >> have to figure out if their ./configure script(s) use this macro or not, >> I'd much rather things "just work". > > I do believe this was similar to the same argument that led to > buildroots being full installs. Don't make app packages figure out what > package names they need in the build root, instead make it "just work". Bear in mind, however, that the difference between a full install (many GB's) and pkgconfig (< 100K) is monumental. -- Rex From jkeating at redhat.com Wed Jun 21 16:55:30 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Jun 2006 12:55:30 -0400 Subject: [Fedora-packaging] Re: -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> Message-ID: <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> On Wed, 2006-06-21 at 11:02 -0500, Rex Dieter wrote: > > Bear in mind, however, that the difference between a full install (many > GB's) and pkgconfig (< 100K) is monumental. True, I'm addressing mentality. We've got two differing opinions on this, would anybody else like to chime in? -- Jesse Keating Release Engineer: Fedora -------------- 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 paul at city-fan.org Wed Jun 21 17:27:25 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 21 Jun 2006 18:27:25 +0100 Subject: [Fedora-packaging] Re: -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> Message-ID: <4499817D.9020600@city-fan.org> Jesse Keating wrote: > On Wed, 2006-06-21 at 11:02 -0500, Rex Dieter wrote: >> Bear in mind, however, that the difference between a full install (many >> GB's) and pkgconfig (< 100K) is monumental. > > True, I'm addressing mentality. > > We've got two differing opinions on this, would anybody else like to > chime in? I think that if the usual method of using a -devel package is by using its .pc file with pkgconfig, then pkgconfig should be a dependency of that package. If the .pc file is provided as a convenience but most users of a particular -devel package don't use it, then don't add the dep. Paul. From toshio at tiki-lounge.com Wed Jun 21 19:37:18 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 21 Jun 2006 12:37:18 -0700 Subject: [Fedora-packaging] Re: -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> Message-ID: <1150918638.3227.23.camel@localhost> On Wed, 2006-06-21 at 12:55 -0400, Jesse Keating wrote: > On Wed, 2006-06-21 at 11:02 -0500, Rex Dieter wrote: > > > > Bear in mind, however, that the difference between a full install (many > > GB's) and pkgconfig (< 100K) is monumental. > > True, I'm addressing mentality. > > We've got two differing opinions on this, would anybody else like to > chime in? Purity would place pkgconfig in a BuildRequire for the package that uses it rather than a Require in the -devel package providing the .pc. However, if I have -devel packages installed it's either because I'm building someone else's software from scratch or because I'm writing some software of my own. In the former case, it's likely that upstream is using pkgconfig, so having it automatically install keeps me from wondering why the configure script fails. In the latter case, unless I'm doing a quick one off I probably want to use pkgconfig to portably find information to compile and link with the library. So I think a Require: line in the package providing the .pc is better for the end-user than a BuildRequire: in the consuming package. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Wed Jun 21 19:48:03 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 21 Jun 2006 22:48:03 +0300 Subject: [Fedora-packaging] Re: -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <4499817D.9020600@city-fan.org> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> <4499817D.9020600@city-fan.org> Message-ID: <1150919285.7016.63.camel@localhost.localdomain> On Wed, 2006-06-21 at 18:27 +0100, Paul Howarth wrote: > Jesse Keating wrote: > > > > We've got two differing opinions on this, would anybody else like to > > chime in? > > I think that if the usual method of using a -devel package is by using > its .pc file with pkgconfig, then pkgconfig should be a dependency of > that package. If the .pc file is provided as a convenience but most > users of a particular -devel package don't use it, then don't add the dep. That sounds nice, but I think it's too subjective to be an effective practical rule that would really achieve much at all. Note that no matter if the *.pc file is actually every used by anything, there's always the issue of installing stuff into unowned dirs if the dependency is not there (%{_libdir}/pkgconfig in this case), which is an explicit MUST no-no in the current review guidelines. This assumes that only pkgconfig owns the dir; owning it in all packages would feel somewhat silly to me. My +1 to always adding the dependency in packages that install *.pc files. From michael at knox.net.nz Wed Jun 21 19:51:00 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 22 Jun 2006 07:51:00 +1200 Subject: [Fedora-packaging] Re: -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <1150919285.7016.63.camel@localhost.localdomain> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> <4499817D.9020600@city-fan.org> <1150919285.7016.63.camel@localhost.localdomain> Message-ID: <4499A324.6030703@knox.net.nz> Ville Skytt? wrote: > On Wed, 2006-06-21 at 18:27 +0100, Paul Howarth wrote: > >>Jesse Keating wrote: >> >>>We've got two differing opinions on this, would anybody else like to >>>chime in? >> >>I think that if the usual method of using a -devel package is by using >>its .pc file with pkgconfig, then pkgconfig should be a dependency of >>that package. If the .pc file is provided as a convenience but most >>users of a particular -devel package don't use it, then don't add the dep. > > > That sounds nice, but I think it's too subjective to be an effective > practical rule that would really achieve much at all. > > Note that no matter if the *.pc file is actually every used by anything, > there's always the issue of installing stuff into unowned dirs if the > dependency is not there (%{_libdir}/pkgconfig in this case), which is an > explicit MUST no-no in the current review guidelines. This assumes that > only pkgconfig owns the dir; owning it in all packages would feel > somewhat silly to me. > > My +1 to always adding the dependency in packages that install *.pc > files. > I will add a +1 one to Ville's comment. Seems the most reasonable. Michael From jkeating at redhat.com Wed Jun 21 19:58:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Jun 2006 15:58:18 -0400 Subject: [Fedora-packaging] Re: -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <1150919285.7016.63.camel@localhost.localdomain> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> <4499817D.9020600@city-fan.org> <1150919285.7016.63.camel@localhost.localdomain> Message-ID: <1150919898.9651.0.camel@dhcp83-49.boston.redhat.com> On Wed, 2006-06-21 at 22:48 +0300, Ville Skytt? wrote: > Note that no matter if the *.pc file is actually every used by anything, > there's always the issue of installing stuff into unowned dirs if the > dependency is not there (%{_libdir}/pkgconfig in this case), AH, there is that. I suppose then it would make sense that if you're installing .pc files to Requires: pkgconfig. Lets move this up the ladder to get ratified. Spot? -- Jesse Keating Release Engineer: Fedora -------------- 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 bugs.michael at gmx.net Wed Jun 21 21:45:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 21 Jun 2006 23:45:20 +0200 Subject: [Fedora-packaging] Re: -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060621234520.0c562219.bugs.michael@gmx.net> On Wed, 21 Jun 2006 12:55:30 -0400, Jesse Keating wrote: > On Wed, 2006-06-21 at 11:02 -0500, Rex Dieter wrote: > > > > Bear in mind, however, that the difference between a full install (many > > GB's) and pkgconfig (< 100K) is monumental. > > True, I'm addressing mentality. > > We've got two differing opinions on this, would anybody else like to > chime in? I'm all for increasing the number of -devel packages which "Requires: pkgconfig". If the .pc file suggests that the -devel package cannot be used conveniently without querying pkg-config, "Requires: pkgconfig" ought to be added. This is very likely the case when headers are installed in non-standard locations (e.g. paths or libs including version information!) or if the .pc file adds flags and dependencies. Without running pkg-config, some configure scripts fail to find installed headers and libraries and fall back to using an included copy of a library or switching off a feature. Apart from that, any package which stores a .pc file in $PKG_CONFIG_PATH should not create unowned directories and hence should "Requires: pkgconfig" anyway. From michael at knox.net.nz Thu Jun 22 03:24:04 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 22 Jun 2006 15:24:04 +1200 Subject: [Fedora-packaging] release tag question. Message-ID: <449A0D54.8070609@knox.net.nz> Hi.. Just looking at the cvsup package, as I need to use it at work. Anywho.. Just curious the rationale for the release tag. The actual version of the package is 16.1h, but its packaged as 16.1 and the "h" is pushed out into the release tag. Like: cvsup-16.1-9h Why? Would this not work: cvsup-16.1h-9 My first guess is that version comparisons would be messed up if the h was in the version tag, but then would it not mess up the release comparison also? Michael From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 22 11:20:34 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 22 Jun 2006 13:20:34 +0200 Subject: [Fedora-packaging] Re: -devel rpms with pkgconfig files should 'Requires: pkgconfig' In-Reply-To: <1150919285.7016.63.camel@localhost.localdomain> (Ville Skytt's message of "Wed, 21 Jun 2006 22:48:03 +0300") References: <44993C35.6000408@math.unl.edu> <1150895788.2398.5.camel@ender> <44994812.5020207@math.unl.edu> <44994968.4040005@math.unl.edu> <44994D87.6000804@math.unl.edu> <1150901827.7049.24.camel@dhcp83-49.boston.redhat.com> <1150908930.7049.44.camel@dhcp83-49.boston.redhat.com> <4499817D.9020600@city-fan.org> <1150919285.7016.63.camel@localhost.localdomain> Message-ID: <87k679mo71.fsf@fc5.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: > Note that no matter if the *.pc file is actually every used by anything, > there's always the issue of installing stuff into unowned dirs if the > dependency is not there (%{_libdir}/pkgconfig in this case), which is an > explicit MUST no-no in the current review guidelines. Can be solved by a 'pkgconfig-filesystem' package providing only this directory. Similar issue exists for /usr/share/aclocal & friends which is more problematic because the owning package brings in a huge and often unneeded perl dependency. Perhaps it's time to think about a 'filesystem-development' package providing filesystem structure for development packages. Enrico From bugs.michael at gmx.net Thu Jun 22 11:22:45 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Jun 2006 13:22:45 +0200 Subject: [Fedora-packaging] release tag question. In-Reply-To: <449A0D54.8070609@knox.net.nz> References: <449A0D54.8070609@knox.net.nz> Message-ID: <20060622132245.093fd355.bugs.michael@gmx.net> On Thu, 22 Jun 2006 15:24:04 +1200, Michael J. Knox wrote: > Hi.. > > Just looking at the cvsup package, as I need to use it at work. Anywho.. > > Just curious the rationale for the release tag. The actual version of > the package is 16.1h, but its packaged as 16.1 and the "h" is pushed out > into the release tag. Like: > > cvsup-16.1-9h A bit wierd to not separate '9' and 'h' with a dot, but: > Why? It's the same old rationale. To avoid comparing numerical bits with non-numerical bits, as all digits are higher than all letters. It's _not_ needed everytime there is a non-numerical piece in a version. But you cannot predict whether it will be needed some day when upstream changes versioning in a way that is incompatible with RPM version comparison. Just like 1.0a (alpha pre-release) is newer than 1.0 (final release) and 2.0 (final) release is older than 2.0a (post-release fix) and 3.0rc4 (release candidate) is newer than 3.0c (post-release fix), and so on. [There are other examples where RPM version comparison does not work with upstream versioning schemes. The most infamous example is 2.11 being a newer upstream release than 2.104 and the opposite for RPM.] > Would this not work: > > cvsup-16.1h-9 16.12 would be newer than 16.1x, 16.12 would be newer than 16.2c, too. Who knows what will come after 16.1h? > My first guess is that version comparisons would be messed up if the h > was in the version tag, but then would it not mess up the release > comparison also? Not if you move the non-numerical bit to the least-significant place (= the very right). From michael at knox.net.nz Thu Jun 22 19:35:01 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 23 Jun 2006 07:35:01 +1200 Subject: [Fedora-packaging] release tag question. In-Reply-To: <20060622132245.093fd355.bugs.michael@gmx.net> References: <449A0D54.8070609@knox.net.nz> <20060622132245.093fd355.bugs.michael@gmx.net> Message-ID: <449AF0E5.8010900@knox.net.nz> Michael Schwendt wrote: > On Thu, 22 Jun 2006 15:24:04 +1200, Michael J. Knox wrote: > > >>Hi.. >> >>Just looking at the cvsup package, as I need to use it at work. Anywho.. >> >>Just curious the rationale for the release tag. The actual version of >>the package is 16.1h, but its packaged as 16.1 and the "h" is pushed out >>into the release tag. Like: >> >>cvsup-16.1-9h > > > A bit wierd to not separate '9' and 'h' with a dot, but: > > >>Why? > > > It's the same old rationale. To avoid comparing numerical bits with > non-numerical bits, as all digits are higher than all letters. It's _not_ > needed everytime there is a non-numerical piece in a version. But you > cannot predict whether it will be needed some day when upstream changes > versioning in a way that is incompatible with RPM version comparison. > > Just like 1.0a (alpha pre-release) is newer than 1.0 (final release) > and 2.0 (final) release is older than 2.0a (post-release fix) and > 3.0rc4 (release candidate) is newer than 3.0c (post-release fix), > and so on. > > [There are other examples where RPM version comparison does not work with > upstream versioning schemes. The most infamous example is 2.11 being a > newer upstream release than 2.104 and the opposite for RPM.] > > >>Would this not work: >> >>cvsup-16.1h-9 > > > 16.12 would be newer than 16.1x, 16.12 would be newer than 16.2c, too. > Who knows what will come after 16.1h? > > >>My first guess is that version comparisons would be messed up if the h >>was in the version tag, but then would it not mess up the release >>comparison also? > > > Not if you move the non-numerical bit to the least-significant > place (= the very right). right, that makes sense. Thanks for clearing that up :) Michael From andreas at bawue.net Wed Jun 28 16:19:40 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Wed, 28 Jun 2006 18:19:40 +0200 (CEST) Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1150476123.3164.23.camel@localhost> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> Message-ID: kindling the issue, but I'm building an arm buildchain myself right now. On Fri, 16 Jun 2006, Toshio Kuratomi wrote: > I can see three choices: > > 1) Ignore the enduser confusion and go with Ralf's naming: > i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > 2) Namespace the whole thing: > cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > 3) Play games with the '-' to avoid the "it's an rpm separator" > association: > i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > FWIW, I think #2 has the most precedent. What about reshuffling the components a bit? binutils-i386-arm-%{version}-%{release}.%{dist}.%{target}.rpm? regards, andreas From rc040203 at freenet.de Wed Jun 28 16:53:17 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 28 Jun 2006 18:53:17 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> Message-ID: <1151513597.22587.21.camel@mccallum.corsepiu.local> On Wed, 2006-06-28 at 18:19 +0200, Andreas Thienemann wrote: > kindling the issue, but I'm building an arm buildchain myself right now. > > On Fri, 16 Jun 2006, Toshio Kuratomi wrote: > > > I can see three choices: > > > > 1) Ignore the enduser confusion and go with Ralf's naming: > > i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > > > 2) Namespace the whole thing: > > cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > > > 3) Play games with the '-' to avoid the "it's an rpm separator" > > association: > > i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm > > > > FWIW, I think #2 has the most precedent. > > What about reshuffling the components a bit? > > binutils-i386-arm-%{version}-%{release}.%{dist}.%{target}.rpm? Confusing, because a) in repos, other packages from this toolchain will not be next to each other, i.e. hardly browsable. b) How would you want to call other add on package for your toolchain? libc-i386-arm? libncurses-i386-arm? c) The fact your toolchain is running on i386's already is part of the rpm's NVR-$arch.rpm => the i386 is redundant and superfluos. d) "arm" is an architecture and is not sufficient to describe a toolchain's target. A toolchain's target consists of more. In case of "bare metal toolchain" (No OS, no libc), this could be arm-elf or arm-bare-elf or even arm-coff. Ralf From lists at timj.co.uk Wed Jun 28 22:03:34 2006 From: lists at timj.co.uk (Tim Jackson) Date: Wed, 28 Jun 2006 23:03:34 +0100 Subject: [Fedora-packaging] License tag in packages Message-ID: <44A2FCB6.6090101@timj.co.uk> Hi, There seems to be some disagreement about the use of "License" in packages. Over in : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423 we are getting into a bit of discussion which is not specific to that package. Basically, the question is: License: Foo License or License: Foo License vX.Y I'm in favour of the latter. Here's why: - legally, "Foo License v1" is wholly and entirely unrelated to "Foo License v2", unless there is a GPL-style "you may use any future version" clause. - despite the fact that License is for informational purposes and is not binding, we shouldn't confuse users. Importantly, we may imply that a package is licensed in a way that it's not which, whilst it may not have any legal consequences, is needlessly confusing. Licensing is already a mysterious enough area as far as most users are concerned without further confusing the issue. - Because of the above, I am essentially saying that we should treat "Foo License v1" and "Foo License v2" in the same way as "Foo License" and "Bar License", i.e. as entirely separate licenses. - we should respect the authors if they specify a specific license version. To address some obvious objections: Q: the License tag is not legally binding anyway A: true, but we are using it, so we should use it accurately. If "Foo License" doesn't accurately describe the license of a package then we might as well "cat /dev/urandom" to it since we're not enlightening users - they'll have to go and read the docs in either case Q: including specific version number has potential for bitrot A: in the sense that the maintainer has to keep an eye on it, true, but that's true in any case since packages can and do change licenses over time. Q: rpmlint moans A: rpmlint needs to be fixed, not the package Q: we're going to have to change loads of existing packages A: I'm not suggesting that; there's clearly no pressing need to change existing packages but for new ones we should have a clear policy Regardless of the above, I think some consistency and a policy is required, including across Core and Extras. For example, the Core php package recently switched *to* a versioned license field. So it seems silly for me to be being asked to take a version *out* of a package in Extras. Frankly I don't really care what the outcome is and I think it's largely an academic argument but I think someone with some authority (FESco) should make a call on it and document the policy and reasoning. Tim From lists at timj.co.uk Wed Jun 28 22:13:45 2006 From: lists at timj.co.uk (Tim Jackson) Date: Wed, 28 Jun 2006 23:13:45 +0100 Subject: [Fedora-packaging] Including License doc in packages Message-ID: <44A2FF19.2000209@timj.co.uk> There seems to be some confusion about including the license file in a package. I have been told two more-or-less contradictory things in two very similar packages. Unfortunately I can't find the wiki citation about this right now, but... php-pear-DB (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176733): "You do not have to bring in the license from an external source." php-pear-PEAR-Command-Packaging (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423): "SHOULD FIX: Include actual license in %doc" OK, so they're not actually contradictory. But we really ought to have some consistency here. If the license file isn't distributed with the package, we should have a clear policy: either we pull it in from an external source (maybe if that's "reasonably" possible, i.e. it's distributed on a public URL as a standalone file), or we don't. Otherwise we just lengthen package reviews and cause the precious time of packagers to be wasted with repeated pointless discussions and re-spins of packages. I really don't care what the policy is - I don't mind whether or not I have to pull external license files into my packages, I just think there should be an unambiguous policy so that I don't have to have this debate every time I do a package. Plus we have at least some consistency for users. Tim From tibbs at math.uh.edu Wed Jun 28 22:32:18 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 28 Jun 2006 17:32:18 -0500 Subject: [Fedora-packaging] Including License doc in packages In-Reply-To: <44A2FF19.2000209@timj.co.uk> (Tim Jackson's message of "Wed, 28 Jun 2006 23:13:45 +0100") References: <44A2FF19.2000209@timj.co.uk> Message-ID: >>>>> "TJ" == Tim Jackson writes: TJ> If the license file isn't distributed with the package, we should TJ> have a clear policy: either we pull it in from an external source TJ> (maybe if that's "reasonably" possible, i.e. it's distributed on a TJ> public URL as a standalone file), or we don't. Hundreds of Perl modules do not include the license text. Most of those are under the same terms as Perl (GPL or Artistic). It is trivial to generate them via perldoc and include them in the package, but this is essentially never done because of the sheer redundancy having the same text in hundreds of modules. When doing reviews, the only time I will request that license text be added to the package when it isn't in the tarball is if the license is not one of the commonly seen licenses or if the license itself is variable. So if you're adding clauses to BSD or you're using the historical permission and disclaimer (which is a multiple-choice thing) or if your package says "These files are under the RandomCrapWare license" then I'll want to see it. At some point it has to come down to common sense. Unfortunately I suspect that excessive formalization will lead to us having a list of licenses which are acceptable to not include if they aren't in the tarball. - J< From chris.stone at gmail.com Thu Jun 29 01:03:35 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 28 Jun 2006 18:03:35 -0700 Subject: [Fedora-packaging] Re: License tag in packages Message-ID: This has been brought up in discussions before: https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html Let's please not get into what the License Tag should hold. I really do not want to have packages that look like this: License: (GPL v2.0 or GPL v2.5) and ((MPL <= 1 or MPL =3) and (...)) and so on and so on... I think it should be clear to people that the Header fields are not meant to be used for this type of thing. A License tag should be something like: License: GPL or Artistic And actual license files should be placed in %doc. If we are to make any kind of standard on this, this is what it should be. Complicating the header tags is only going to complicate a lot of other things and confuse new packagers. The bottom line is that Header tags SHOULD not be used to determine the license. We want to encourage people to read the ACTUAL license itself, not our header tags. All licenses header tags should be as generalized as possible with just "GPL" for this very purpose. We do not want new packagers creating new header tags with all kinds of add ons.. License: GPL (except for clause 4 paragraph 2) and Artistic (with this added on....) etc... Once we go down the road of getting specific on the License tags then we will be adding all kinds of crap to the tag. Please let's not go there. From andreas at bawue.net Thu Jun 29 01:26:47 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 29 Jun 2006 03:26:47 +0200 (CEST) Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1151513597.22587.21.camel@mccallum.corsepiu.local> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <1151513597.22587.21.camel@mccallum.corsepiu.local> Message-ID: On Wed, 28 Jun 2006, Ralf Corsepius wrote: > > binutils-i386-arm-%{version}-%{release}.%{dist}.%{target}.rpm? > Confusing, because > > a) in repos, other packages from this toolchain will not be next to each > other, i.e. hardly browsable. Correct. But the binutils will be together with the host binutils and other cross compiler binutils. That can be considered nice as well. > b) How would you want to call other add on package for your toolchain? > libc-i386-arm? libncurses-i386-arm? glibc-i386-arm-elf probably. But one could also go with prepending cross- to make the distinction clearer. > c) The fact your toolchain is running on i386's already is part of the > rpm's NVR-$arch.rpm => the i386 is redundant and superfluos. I thought about leaving it out, but considered it clearer to just name it without having to force the user to shift his eyes to the right and look for the arch tag. > d) "arm" is an architecture and is not sufficient to describe a > toolchain's target. A toolchain's target consists of more. > In case of "bare metal toolchain" (No OS, no libc), this could be > arm-elf or arm-bare-elf or even arm-coff. You're right about that. I meant arm-elf, as this is what I was building, but simply forgot about the -elf part. regards, andreas From Axel.Thimm at ATrpms.net Thu Jun 29 05:29:56 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Jun 2006 07:29:56 +0200 Subject: [Fedora-packaging] Re: soname change policy proposal In-Reply-To: <44A0E14B.9010200@hhs.nl> References: <44A0E14B.9010200@hhs.nl> Message-ID: <20060629052956.GA27753@neu.nirvana> Hi, On Tue, Jun 27, 2006 at 09:42:03AM +0200, Hans de Goede wrote: > I've been thinking about this for a while and I think its time for a > brain dump, so here is a first shot at a soname change policy: I agree with Ville to prepend this with the (soft) requirement to try to remain ABI compatible within a distribution. > 1) When a package update would cause an soname change then a compat > package with the old libraries must be provided for all release repos, > that is for all repos except devel. > 1a) This compat package must be successfully build before a build of > the update causing the change may be requested. > 1b) If an update causing a soname change will only be build for devel > a compat package is not mandatory. In this case however other packagers > must be warned, with the warning containing a way for them to get the > new version. After the warning one must wait 7 days minimum before the > new version may be build. I had a similar suggestion some time back on this list, where I tried to persuade to use compat-like packages from the beginning, so that there is no need to rebuild new old-packages and rereview them, and also no need to sync compat vs new packages, coordinate rebuilds of all dependent packages and the like. It is also both backward and forward compatible: Simply subpackage the library components in libfoo packages like Debian/Mandriva/ATrpms are doing. The libfoos are already your compat packages, when a new bump happens libfoo simply appears in the repo next to the to be outphased libfoo. Applications can be rebuilt against the new foo at their own pace. No review of the compat-becoming libfoo is neccessary, since it hasn't changed, not only in theory, but it is still the same well-known binary with the same rpm metadata. No subtle rpm meta-obsoletes due to Provides: of some common resource (see Rex' comment). The only drawback: Your system doesn't cater for old and unused libfoos. But that's fixable by tagging the packages. For example ATrpms uses Provides: shared-library-package, so all such compat packages can be found with a simple rpm -q --whatprovides shared-library-package, for example: # rpm -q --whatprovides shared-library-package libsrs_alt1-1.0-2_rc1.rhfc5.at libbeecrypt6-4.1.2-9.2_11.rhfc5.at libgcrypt11-1.2.2-11.rhfc5.at libspf2_2-1.2.5-4.rhfc5.at libgcrypt11-1.2.2-11.rhfc5.at libdirect-0.9_24-0.9.24-8.rhfc5.at libfusion-0.9_24-0.9.24-8.rhfc5.at Therefore one could easily implement a "package garbage collector". The poor man's implementation would look like rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' --whatprovides shared-library-package | xargs -l1 rpm -e 2> /dev/null [As a side-effect you get multi-repo combinations working better, since repos are using different libfoo. This isn't an argument for Fedora Core/Extras, but it was the motivation for ATrpms to use that method. Still given the size of Fedora Extras having larger time windows for libfoo transitions of dependent packages is a good thing and comparable to the not-synced upgrading of libfoo in different repos, e.g. in Fedora Core/Extras semantics: no need for alarms at fedora-maintainers etc.] This scheme works very nice. The question I still have is whether to only apply it to a very selected set of packages known from the past to aggressively bump sonames, or whether it makes sense to have this as a general guideline to avoid ever getting into such a trap again. I guess in order to find out how well this scheme works the first model could be tried out on the problematic packages and depending on success/failure it could be extended to further packages. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 29 06:26:31 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 29 Jun 2006 08:26:31 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: (Andreas Thienemann's message of "Wed, 28 Jun 2006 18:19:40 +0200 (CEST)") References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> Message-ID: <87bqsc4gvc.fsf@kosh.bigo.ensc.de> andreas at bawue.net (Andreas Thienemann) writes: > What about reshuffling the components a bit? > > binutils-i386-arm-%{version}-%{release}.%{dist}.%{target}.rpm? With this naming, you will run into problems when you use subpackages and you have to use '-n' everytime. E.g. | Name: glibc-%crossarch | ... | %package devel will result into 'glibc-%crossarch-devel' else. Enrico From paul at city-fan.org Thu Jun 29 07:43:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 29 Jun 2006 08:43:50 +0100 Subject: [Fedora-packaging] Including License doc in packages In-Reply-To: <44A2FF19.2000209@timj.co.uk> References: <44A2FF19.2000209@timj.co.uk> Message-ID: <1151567030.7470.121.camel@laurel.intra.city-fan.org> On Wed, 2006-06-28 at 23:13 +0100, Tim Jackson wrote: > There seems to be some confusion about including the license file in a > package. I have been told two more-or-less contradictory things in two > very similar packages. Unfortunately I can't find the wiki citation > about this right now, but... > > > php-pear-DB (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176733): > > "You do not have to bring in the license from an external source." > > > php-pear-PEAR-Command-Packaging > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423): > > "SHOULD FIX: Include actual license in %doc" > > > OK, so they're not actually contradictory. But we really ought to have > some consistency here. If the license file isn't distributed with the > package, we should have a clear policy: either we pull it in from an > external source (maybe if that's "reasonably" possible, i.e. it's > distributed on a public URL as a standalone file), or we don't. > Otherwise we just lengthen package reviews and cause the precious time > of packagers to be wasted with repeated pointless discussions and > re-spins of packages. > > I really don't care what the policy is - I don't mind whether or not I > have to pull external license files into my packages, I just think there > should be an unambiguous policy so that I don't have to have this debate > every time I do a package. Plus we have at least some consistency for users. The policy is very clear IMHO: http://www.fedoraproject.org/wiki/Packaging/ReviewGuidelines 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. Paul. From paul at city-fan.org Thu Jun 29 07:49:45 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 29 Jun 2006 08:49:45 +0100 Subject: [Fedora-packaging] Including License doc in packages In-Reply-To: <1151567030.7470.121.camel@laurel.intra.city-fan.org> References: <44A2FF19.2000209@timj.co.uk> <1151567030.7470.121.camel@laurel.intra.city-fan.org> Message-ID: <1151567385.7470.124.camel@laurel.intra.city-fan.org> On Thu, 2006-06-29 at 08:43 +0100, Paul Howarth wrote: > On Wed, 2006-06-28 at 23:13 +0100, Tim Jackson wrote: > > There seems to be some confusion about including the license file in a > > package. I have been told two more-or-less contradictory things in two > > very similar packages. Unfortunately I can't find the wiki citation > > about this right now, but... > > > > > > php-pear-DB (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176733): > > > > "You do not have to bring in the license from an external source." > > > > > > php-pear-PEAR-Command-Packaging > > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423): > > > > "SHOULD FIX: Include actual license in %doc" > > > > > > OK, so they're not actually contradictory. But we really ought to have > > some consistency here. If the license file isn't distributed with the > > package, we should have a clear policy: either we pull it in from an > > external source (maybe if that's "reasonably" possible, i.e. it's > > distributed on a public URL as a standalone file), or we don't. > > Otherwise we just lengthen package reviews and cause the precious time > > of packagers to be wasted with repeated pointless discussions and > > re-spins of packages. > > > > I really don't care what the policy is - I don't mind whether or not I > > have to pull external license files into my packages, I just think there > > should be an unambiguous policy so that I don't have to have this debate > > every time I do a package. Plus we have at least some consistency for users. > > The policy is very clear IMHO: > > http://www.fedoraproject.org/wiki/Packaging/ReviewGuidelines > > 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. Forgot to add: there's also this: SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. So upstream should be requested to add the license text in their distribution, but the package need not contain it until upstream does this. In the special case of the package maintainer being the same as upstream, I think there is merit is pushing a bit harder for this. Paul. From lists at timj.co.uk Thu Jun 29 08:23:25 2006 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 29 Jun 2006 09:23:25 +0100 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: References: Message-ID: <44A38DFD.3030000@timj.co.uk> Christopher Stone wrote: > This has been brought up in discussions before: > https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html Thanks for the link, although there was no obvious conclusion there. The most interesting thing was the survey of existing licenses, which illustrates the current inconsistent and confused usage - which is my key point here. > Let's please not get into what the License Tag should hold. I don't particularly want to discuss this any more than you do, but I do think there needs to be conclusion & consensus. As before, I'll respect whatever policy is agreed and documented, but (as the fact this has come up at least twice in three months shows) ignoring it just means it will keep coming up and inconsistency will continue. > I really do not want to have packages that look like this: > License: (GPL v2.0 or GPL v2.5) and ((MPL <= 1 or MPL =3) and (...)) Me neither, but that's an extreme example and I don't think many packages have such complex licensing. And don't forget that in such a case you could always say "Complex; see documentation". > Complicating the header tags is only going to [...] confuse new > packagers. Telling new packagers that they can't use a License string for Extras package "foo-bar" which is the same as the identically-licensed Core package "foo" is arguably even more confusing. > The bottom line is that Header tags SHOULD not be used to determine the > license. Is it not redundant then? > We want to encourage people to read the ACTUAL license itself, not our > header tags. Then perhaps the License field should always be omitted, or populated with "See documentation". > All licenses header tags should be as generalized as possible with > just "GPL" for this very purpose. Whilst I do genuinely follow your train of thought, and I actually wish the situation was that simple, you've not addressed: a) the fact that this is misleading b) the very shaky legal basis of arbitrarily renaming licenses (someone in the thread you linked to pointed out that it may not be binding, but a packager misleading users could arguably have some liability) c) the fact that what you're saying is inconsistent with what at least some Core packagers are doing Tim From rc040203 at freenet.de Thu Jun 29 08:36:34 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 29 Jun 2006 10:36:34 +0200 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: <44A38DFD.3030000@timj.co.uk> References: <44A38DFD.3030000@timj.co.uk> Message-ID: <1151570195.18025.8.camel@mccallum.corsepiu.local> On Thu, 2006-06-29 at 09:23 +0100, Tim Jackson wrote: > Christopher Stone wrote: > > > This has been brought up in discussions before: > > https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html > > The bottom line is that Header tags SHOULD not be used to determine the > > license. > > Is it not redundant then? IMO, the License:-tag should be considered to be a short informative abbreviated description for the actual licensing, and not to be considered a legally binding description. > > We want to encourage people to read the ACTUAL license itself, not our > > header tags. Things in practice are much more complicated. Developers wanting to use a package for development will have to dive into the source code in any case. For normal Fedora users, the License-tag, a "LICENSE" file and the source files are equally uninteresting. Ralf From chris.stone at gmail.com Thu Jun 29 08:38:14 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 29 Jun 2006 01:38:14 -0700 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: <44A38DFD.3030000@timj.co.uk> References: <44A38DFD.3030000@timj.co.uk> Message-ID: On 6/29/06, Tim Jackson wrote: > Christopher Stone wrote: > > > This has been brought up in discussions before: > > https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html > > Thanks for the link, although there was no obvious conclusion there. The > most interesting thing was the survey of existing licenses, which > illustrates the current inconsistent and confused usage - which is my > key point here. It is not inconsistant: 734 GPL 1 GPL version 2 or newer The one package that uses "GPL version 2 or newer" should be fixed to just say "GPL" to conform with all 734 other packages. This was pretty well established in the thread. > > We want to encourage people to read the ACTUAL license itself, not our > > header tags. > > Then perhaps the License field should always be omitted, or populated > with "See documentation". Yes, or how about "Fedora friendly" with a link showing valid Fedora licenses. But I don't think it's is going too far to provide a minimal amount of information such as GPL or BSD. > > All licenses header tags should be as generalized as possible with > > just "GPL" for this very purpose. > > Whilst I do genuinely follow your train of thought, and I actually wish > the situation was that simple, you've not addressed: > > a) the fact that this is misleading No, it's misleading to let users think they can actually determine a software package's license agreement from the RPM's header tag. > b) the very shaky legal basis of arbitrarily renaming licenses (someone > in the thread you linked to pointed out that it may not be binding, but > a packager misleading users could arguably have some liability) If it is legally binding, then we are legally bound to include the entire text of the License in the header tag. This is why the header tag should not be used to indicate anything more than the most general license "concept". > c) the fact that what you're saying is inconsistent with what at least > some Core packagers are doing I agree, let's make a standard and stick to it. But please try to see the logic in the arguments I have presented. It is simply a tag and should not be taken for anything more than that. From ville.skytta at iki.fi Thu Jun 29 11:57:40 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 29 Jun 2006 14:57:40 +0300 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <87bqsc4gvc.fsf@kosh.bigo.ensc.de> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <87bqsc4gvc.fsf@kosh.bigo.ensc.de> Message-ID: <1151582260.6570.120.camel@localhost.localdomain> On Thu, 2006-06-29 at 08:26 +0200, Enrico Scholz wrote: > With this naming, you will run into problems when you use subpackages > and you have to use '-n' everytime. Not throwing in an opinion towards any of the suggestions, but what's the actual problem with using -n to set subpackage names whenever necessary? From ville.skytta at iki.fi Thu Jun 29 12:08:13 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 29 Jun 2006 15:08:13 +0300 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: <44A38DFD.3030000@timj.co.uk> References: <44A38DFD.3030000@timj.co.uk> Message-ID: <1151582893.6570.130.camel@localhost.localdomain> On Thu, 2006-06-29 at 09:23 +0100, Tim Jackson wrote: > Christopher Stone wrote: > > > The bottom line is that Header tags SHOULD not be used to determine the > > license. > > Is it not redundant then? Redundant or not, the License tag is mandated by rpmbuild. As long as it stays that way, IMO including a reasonable approximation in it is the best way to go. Users and distributors should dive into the actual licensing/copyright information anyway to determine if they find it acceptable for their particular use cases. From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 29 12:10:48 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 29 Jun 2006 14:10:48 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1151582260.6570.120.camel@localhost.localdomain> (Ville Skytt's message of "Thu, 29 Jun 2006 14:57:40 +0300") References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <87bqsc4gvc.fsf@kosh.bigo.ensc.de> <1151582260.6570.120.camel@localhost.localdomain> Message-ID: <87slloduwn.fsf@fc5.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> [... - or - ...] >> With this naming, you will run into problems when you use subpackages >> and you have to use '-n' everytime. > > Not throwing in an opinion towards any of the suggestions, but what's > the actual problem with using -n to set subpackage names whenever > necessary? It will be necessary *evertime*. And the '-n' will not influence the '%package' statement only but common expressions like | Requires: %name-lib = %version-%release Enrico From lists at timj.co.uk Thu Jun 29 12:12:17 2006 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 29 Jun 2006 13:12:17 +0100 Subject: [Fedora-packaging] Including License doc in packages In-Reply-To: <1151567385.7470.124.camel@laurel.intra.city-fan.org> References: <44A2FF19.2000209@timj.co.uk> <1151567030.7470.121.camel@laurel.intra.city-fan.org> <1151567385.7470.124.camel@laurel.intra.city-fan.org> Message-ID: <44A3C3A1.6070300@timj.co.uk> Paul Howarth wrote: > SHOULD: If the source package does not include license text(s) as > a separate file from upstream, the packager SHOULD query > upstream to include it. > > So upstream should be requested to add the license text in their > distribution, but the package need not contain it until upstream does > this. Indeed, and getting license files in upstream packages is certainly a Good Thing in the general case. However, this ignores the case where (rightly or wrongly) it is not normally done upstream. (e.g. PEAR), probably because for tiny modules like PEAR modules where they are often installed in relatively large numbers, you would end up with a large number of duplicated license fields. > In the special case of the package maintainer being the same as > upstream, I think there is merit is pushing a bit harder for this. I agree. In this particular case, I have no problem in including the license text in the package upstream, but at the same time I believe it's not conventionally done, so by the same consistency logic I probably shouldn't make one PEAR module be special, *just because* I happen to be maintaining a Fedora package for it. (I'm not saying there isn't necessarily a general argument for including license files in every module, just that that doesn't appear to be the convention at the moment, so even if I solve this particular issue by including it, there are millions of other modules out there that don't). Tim From paul at city-fan.org Thu Jun 29 12:31:14 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 29 Jun 2006 13:31:14 +0100 Subject: [Fedora-packaging] Including License doc in packages In-Reply-To: <44A3C3A1.6070300@timj.co.uk> References: <44A2FF19.2000209@timj.co.uk> <1151567030.7470.121.camel@laurel.intra.city-fan.org> <1151567385.7470.124.camel@laurel.intra.city-fan.org> <44A3C3A1.6070300@timj.co.uk> Message-ID: <1151584275.7470.194.camel@laurel.intra.city-fan.org> On Thu, 2006-06-29 at 13:12 +0100, Tim Jackson wrote: > Paul Howarth wrote: > > > SHOULD: If the source package does not include license text(s) as > > a separate file from upstream, the packager SHOULD query > > upstream to include it. > > > > So upstream should be requested to add the license text in their > > distribution, but the package need not contain it until upstream does > > this. > > Indeed, and getting license files in upstream packages is certainly a > Good Thing in the general case. However, this ignores the case where > (rightly or wrongly) it is not normally done upstream. (e.g. PEAR), > probably because for tiny modules like PEAR modules where they are often > installed in relatively large numbers, you would end up with a large > number of duplicated license fields. > > > In the special case of the package maintainer being the same as > > upstream, I think there is merit is pushing a bit harder for this. > > I agree. In this particular case, I have no problem in including the > license text in the package upstream, but at the same time I believe > it's not conventionally done, so by the same consistency logic I > probably shouldn't make one PEAR module be special, *just because* I > happen to be maintaining a Fedora package for it. (I'm not saying there > isn't necessarily a general argument for including license files in > every module, just that that doesn't appear to be the convention at the > moment, so even if I solve this particular issue by including it, there > are millions of other modules out there that don't). It's very common for perl modules not to include the license text too, but in the cases where the upstream has included it, the Extras packages also include it as %doc. This does tend to result in a very number of copies of, for instance, the GPL, but the space taken up by these is still very, very small as a proportion of the size of the distribution, and anyone that's really struggling for space always has the option of installing packages using rpm's --excludedocs option. Paul. From ville.skytta at iki.fi Thu Jun 29 12:32:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 29 Jun 2006 15:32:19 +0300 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <87slloduwn.fsf@fc5.bigo.ensc.de> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <87bqsc4gvc.fsf@kosh.bigo.ensc.de> <1151582260.6570.120.camel@localhost.localdomain> <87slloduwn.fsf@fc5.bigo.ensc.de> Message-ID: <1151584339.6570.134.camel@localhost.localdomain> On Thu, 2006-06-29 at 14:10 +0200, Enrico Scholz wrote: > ville.skytta at iki.fi (Ville Skytt?) writes: > > Not throwing in an opinion towards any of the suggestions, but what's > > the actual problem with using -n to set subpackage names whenever > > necessary? > > It will be necessary *evertime*. And the '-n' will not influence the > '%package' statement only but common expressions like [...] Sure, but where's the *problem*? From smooge at gmail.com Thu Jun 29 14:25:48 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 29 Jun 2006 08:25:48 -0600 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: <1151570195.18025.8.camel@mccallum.corsepiu.local> References: <44A38DFD.3030000@timj.co.uk> <1151570195.18025.8.camel@mccallum.corsepiu.local> Message-ID: <80d7e4090606290725j1f4db02fp59285110a3303337@mail.gmail.com> On 6/29/06, Ralf Corsepius wrote: > On Thu, 2006-06-29 at 09:23 +0100, Tim Jackson wrote: > > Christopher Stone wrote: > > > > > This has been brought up in discussions before: > > > https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html > > > > The bottom line is that Header tags SHOULD not be used to determine the > > > license. > > > > Is it not redundant then? > > IMO, the License:-tag should be considered to be a short informative > abbreviated description for the actual licensing, and not to be > considered a legally binding description. > After trying various variations of strings.. I would prefer that this is the definition of the License tags. I would prefer that we have a standardized list of them in order to make searching/sorting easier. The main problem right now I am having is with Core packages... where there are many variations on GPL, and combo licenses or just the very useful Distributable tag which does not tell me is it Free, Libre, Open, or Closed. -- Stephen J Smoogen. CSIRT/Linux System Administrator From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 29 15:06:12 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 29 Jun 2006 17:06:12 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1151584339.6570.134.camel@localhost.localdomain> (Ville Skytt's message of "Thu, 29 Jun 2006 15:32:19 +0300") References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <87bqsc4gvc.fsf@kosh.bigo.ensc.de> <1151582260.6570.120.camel@localhost.localdomain> <87slloduwn.fsf@fc5.bigo.ensc.de> <1151584339.6570.134.camel@localhost.localdomain> Message-ID: <87odwcdmsb.fsf@fc5.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> > Not throwing in an opinion towards any of the suggestions, but >> > what's the actual problem with using -n to set subpackage names >> > whenever necessary? >> >> It will be necessary *evertime*. And the '-n' will not influence the >> '%package' statement only but common expressions like [...] > > Sure, but where's the *problem*? You have to use the full packagename everytime which clutters up the spec file. Enrico From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 29 15:08:56 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 29 Jun 2006 17:08:56 +0200 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <1151584339.6570.134.camel@localhost.localdomain> (Ville Skytt's message of "Thu, 29 Jun 2006 15:32:19 +0300") References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <87bqsc4gvc.fsf@kosh.bigo.ensc.de> <1151582260.6570.120.camel@localhost.localdomain> <87slloduwn.fsf@fc5.bigo.ensc.de> <1151584339.6570.134.camel@localhost.localdomain> Message-ID: <87k670dmnr.fsf@fc5.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> > Not throwing in an opinion towards any of the suggestions, but >> > what's the actual problem with using -n to set subpackage names >> > whenever necessary? >> >> It will be necessary *evertime*. And the '-n' will not influence the >> '%package' statement only but common expressions like [...] > > Sure, but where's the *problem*? and: -debuginfo packages will be named incorrectly. Enrico From ville.skytta at iki.fi Thu Jun 29 16:01:43 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 29 Jun 2006 19:01:43 +0300 Subject: [Fedora-packaging] Namespace for cross-compilation tools? In-Reply-To: <87odwcdmsb.fsf@fc5.bigo.ensc.de> References: <1150430367.12910.12.camel@mccallum.corsepiu.local> <1150433368.12910.31.camel@mccallum.corsepiu.local> <44923BD8.8050807@knox.net.nz> <1150439176.12910.61.camel@mccallum.corsepiu.local> <44926017.20308@knox.net.nz> <1150476123.3164.23.camel@localhost> <87bqsc4gvc.fsf@kosh.bigo.ensc.de> <1151582260.6570.120.camel@localhost.localdomain> <87slloduwn.fsf@fc5.bigo.ensc.de> <1151584339.6570.134.camel@localhost.localdomain> <87odwcdmsb.fsf@fc5.bigo.ensc.de> Message-ID: <1151596903.6570.161.camel@localhost.localdomain> On Thu, 2006-06-29 at 17:06 +0200, Enrico Scholz wrote: > ville.skytta at iki.fi (Ville Skytt?) writes: > > >> It will be necessary *evertime*. And the '-n' will not influence the > >> '%package' statement only but common expressions like [...] > > > > Sure, but where's the *problem*? > > You have to use the full packagename everytime which clutters up the > spec file. Doesn't qualify as a real problem IMO. > and: -debuginfo packages will be named incorrectly. That's derived from the "main" (source) package name no matter if -n is used inside the specfile or not. Again, I see no problem there, and do think that "incorrectly" is an overstatement. Anyway, I'll stop handwaving about implementation details now, and let others concentrate on the original issues. From tibbs at math.uh.edu Thu Jun 29 19:00:20 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 29 Jun 2006 14:00:20 -0500 Subject: [Fedora-packaging] Open issues with the PHP guidelines Message-ID: Here are some open issues I see with the PHP guidelines. I don't pretend that this is exhaustive: 1) The php(ABI) symbol. The current PHP package (in FC5) provides php-api = 20041225; is that sufficient? 2) Somethig equivalent to perl(:MODULE_COMPAT_version). The base PHP package eventually provides a whole bunch of these indicating what releases a module could have been written against and still work. So php v6 can drop compatibility for anything before v4.2 and the package can drop the corresponding :MODULE_COMPAT symbols. 3) It seems there are plenty of extensions which are neither PEAR nor PECL. We need to figure out conventions for those. 4) Scriptlets for registering PEAR packages. 5) There is some functionality in php-pear which only made it in as of some specific version, I think 1.4.9, which needs to be there in order for something work work. I don't know the exact details, but we need to document them. (As a bonus, it seems that package has a nonzero epoch as well.) 6) We need to work up specfile templates for all three situations if appropriate and get them into fedora-rpmdevtools. - J< From chris.stone at gmail.com Thu Jun 29 20:40:47 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 29 Jun 2006 13:40:47 -0700 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: References: Message-ID: On 6/29/06, Jason L Tibbitts III wrote: > 6) We need to work up specfile templates for all three situations if > appropriate and get them into fedora-rpmdevtools. I have put up what I think is a good template for pear modules here: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec Comments welcome. From ville.skytta at iki.fi Thu Jun 29 21:02:28 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 30 Jun 2006 00:02:28 +0300 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: References: Message-ID: <1151614948.6570.207.camel@localhost.localdomain> On Thu, 2006-06-29 at 13:40 -0700, Christopher Stone wrote: > On 6/29/06, Jason L Tibbitts III wrote: > > 6) We need to work up specfile templates for all three situations if > > appropriate and get them into fedora-rpmdevtools. > > I have put up what I think is a good template for pear modules here: > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec > > Comments welcome. Cosmetics: matching the existing style of other templates in rpmdevtools would be desirable (rm instead of %{__rm}, $RPM_BUILD_ROOT instead of %{buildroot}, indentation width at the top). %build section missing, see eg. https://bugzilla.redhat.com/192422 why that may not be a good idea. The template is noarch, so the debuginfo problem isn't a problem here, but adding an empty %build section might avoid some nasty surprises in the future. By the way, are all pear module packages noarch? Do those %defines at the top work in mock/plague setups where pear is not installed at the time the build begins? I think someone reported a problem with the similar approach taken in the python spec template in configurations where python is not in the initial set of packages (which could be a bug, but pear not being there is not). One possible fix would be to not do those defines, but to generate a filelist in %install and use that in %files, and drop the %defines altogether. It would be nice to have rpmlint bugs reported instead of cluttering specfiles with comments and workarounds like the one in %post. I'll see if I can do something about it. It's good to see the Foo_Bar/Foo-Bar placeholders in this phase, but they'll probably be emptied and auto-replaced by newrpmspec if/when the template enters rpmdevtools. From chris.stone at gmail.com Thu Jun 29 21:11:43 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 29 Jun 2006 14:11:43 -0700 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: <1151614948.6570.207.camel@localhost.localdomain> References: <1151614948.6570.207.camel@localhost.localdomain> Message-ID: On 6/29/06, Ville Skytt? wrote: > On Thu, 2006-06-29 at 13:40 -0700, Christopher Stone wrote: > > On 6/29/06, Jason L Tibbitts III wrote: > > > 6) We need to work up specfile templates for all three situations if > > > appropriate and get them into fedora-rpmdevtools. > > > > I have put up what I think is a good template for pear modules here: > > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec > > > > Comments welcome. > > Cosmetics: matching the existing style of other templates in rpmdevtools > would be desirable (rm instead of %{__rm}, $RPM_BUILD_ROOT instead of > %{buildroot}, indentation width at the top). I think the other templates should change to match mine. My style is by far the cleanest and easiest on the eyes. Why do we have a %{__rm} macro if it should not be used? We should be consistent and use %{buildroot} so that we use the same type of macros everywhere in the spec. Indentation changed to line up Requires(postun): > %build section missing, see eg. https://bugzilla.redhat.com/192422 why > that may not be a good idea. The template is noarch, so the debuginfo > problem isn't a problem here, but adding an empty %build section might > avoid some nasty surprises in the future. By the way, are all pear > module packages noarch? This is not an issue. All pear packages are noarch and therefore no %build or debuginfo packages need to be built. > Do those %defines at the top work in mock/plague setups where pear is > not installed at the time the build begins? I think someone reported a > problem with the similar approach taken in the python spec template in > configurations where python is not in the initial set of packages (which > could be a bug, but pear not being there is not). One possible fix > would be to not do those defines, but to generate a filelist in %install > and use that in %files, and drop the %defines altogether. The %defines seem to work for me under mock, I'm not sure this is an issue. > It would be nice to have rpmlint bugs reported instead of cluttering > specfiles with comments and workarounds like the one in %post. I'll see > if I can do something about it. Cool, thx > > It's good to see the Foo_Bar/Foo-Bar placeholders in this phase, but > they'll probably be emptied and auto-replaced by newrpmspec if/when the > template enters rpmdevtools. Yes, the only caveat is that a package like Foo_Bar really stores it's files in a Foo/Bar/ directory, not a Foo_Bar/ directory as the current spec file indicates. I also added a Provides: php-Foo-Bar = %{version}-%{release} to meet the current (Draft) php guidelines, not sure I like this idea though From chris.stone at gmail.com Thu Jun 29 21:25:28 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 29 Jun 2006 14:25:28 -0700 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: <1151614948.6570.207.camel@localhost.localdomain> References: <1151614948.6570.207.camel@localhost.localdomain> Message-ID: On 6/29/06, Ville Skytt? wrote: > Do those %defines at the top work in mock/plague setups where pear is > not installed at the time the build begins? I think someone reported a > problem with the similar approach taken in the python spec template in > configurations where python is not in the initial set of packages (which > could be a bug, but pear not being there is not). One possible fix > would be to not do those defines, but to generate a filelist in %install > and use that in %files, and drop the %defines altogether. I tried changing the macros to just: %define peardir %(pear config-get php_dir 2> /dev/null) And this still worked under mock. From lists at timj.co.uk Thu Jun 29 22:37:36 2006 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 29 Jun 2006 23:37:36 +0100 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: References: <44A38DFD.3030000@timj.co.uk> Message-ID: <44A45630.3040608@timj.co.uk> Christopher Stone wrote: [current usage of License] > It is not inconsistant: > 734 GPL > 1 GPL version 2 or newer plus 1 GPL version 2 or later. 1 GPL version 2 or later 1 GPLv2 OK, there's certainly a majority. > The one package that uses "GPL version 2 or newer" should be fixed to > just say "GPL" to conform with all 734 other packages. > This was pretty well established in the thread. There were also some convincing arguments the other way, that I don't think were repudiated. >> Then perhaps the License field should always be omitted, or populated >> with "See documentation". > Yes, or how about "Fedora friendly" with a link showing valid Fedora > licenses. But I don't think it's is going too far to provide a > minimal amount of information such as GPL or BSD. OK, so what we're talking about really is treating "License" like "License group" or something. Fair enough. >> b) the very shaky legal basis of arbitrarily renaming licenses (someone >> in the thread you linked to pointed out that it may not be binding, but >> a packager misleading users could arguably have some liability) > > If it is legally binding, then we are legally bound to include the > entire text of the License in the header tag. There is a difference between "legally binding" and "misleading in a legal sense". Hypothetically, I may not have a duty to tell you the license of a file at all, but if I assertively tell you it is "XXX" and you go ahead and distribute it under "XXX v2" when actually its license is "XXX v3" which has different terms that you breach, then at the least I have misled you and caused you to do bad stuff that you might not otherwise have done (notwithstanding the fact that you should have checked the details), regardless of whether or not this in any way makes me liable to you. (It probably doesn't, but I don't want to encourage people to do stuff with free software which goes against the author's wishes and, for example, GPLv3 is shaping up to have notable differences to GPLv2 in at least some ways) >> c) the fact that what you're saying is inconsistent with what at least >> some Core packagers are doing > > I agree, let's make a standard and stick to it. That's all I'm getting at really :) > But please try to see the logic in the arguments I have presented. > It is simply a tag and should not be taken for anything more than that. I do, honest I do. And I for one treat it exactly like that when I'm deciding how to use a bit of software: I wouldn't dream of relying on the License: tag; I would always go and check the actual source docs/source code etc. But I also don't want to mislead people who might, without any ill intent, not be so diligent. All I'm looking for I suppose is a reasonable, reasoned and "approved" (in some meaningful sense) wiki page (not archived list thread) that is linked from PackagingGuidelines and which I (and everyone else) can look at each time I do a package and know what to put in the License field. Whether or not it corresponds to my personal preferences is not really important; I'll follow it if it's generally agreed (and preferably given the nod by FESco). The fact that this issue has come up several times means that a *conclusive* resolution is definitely needed. Tim From chris.stone at gmail.com Thu Jun 29 22:47:43 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 29 Jun 2006 15:47:43 -0700 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: <44A45630.3040608@timj.co.uk> References: <44A38DFD.3030000@timj.co.uk> <44A45630.3040608@timj.co.uk> Message-ID: I missed this week's FESCo meeting so I don't know if it was brought up, but there should be a FESCo descision on "best practices" when the packager is in doubt. Personally I want as little liability on me as a packager as possible. I would like to be legally forced to use a license specified by rpmlint only in my agreement with packaging for redhat, and therefore any liability I would have as a packager regarding the license tag would be transferred over to redhat. There should also be legal text somewhere indicating that the license tag should only be considered as an indicater to the type of the license and has no legal binding whatsoever. I'm just covering my ass here, I don't like discussions about packagers being sued over what is in the License tag of the RPM ;-) From tibbs at math.uh.edu Thu Jun 29 23:08:06 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 29 Jun 2006 18:08:06 -0500 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: (Christopher Stone's message of "Thu, 29 Jun 2006 15:47:43 -0700") References: <44A38DFD.3030000@timj.co.uk> <44A45630.3040608@timj.co.uk> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> I missed this week's FESCo meeting so I don't know if it was CS> brought up, but there should be a FESCo descision on "best CS> practices" when the packager is in doubt. Actually this is no longer in the FESCo bailiwick. The packaging committee is now deciding these things for both Core and Extras, and you're essentially reaching the committee by posting here. So let me see if I can correctly summarize the open questions: 1) How accurately does the license need to be described in the License: tag? a) Is it sufficient to specify a license that is "close" to the actual license? b) Are tags like "BSDish" and "GPL-like" acceptable? (rpmlint doesn't warn when it sees them.) c) Is it necessary to specify the version of a particular license? If so, what is the proper way to do this? 2) When does the license text need to be included in the package? Current behavior is "include if in the upstream tarball, otherwise don't include". a) Is this sufficient? b) If not, what situations would require the license when it's not in the tarball? CS> Personally I want as little liability on me as a packager as CS> possible. Note that this would essentially require no interpretation of the license whatever. - J< From tibbs at math.uh.edu Thu Jun 29 23:12:08 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 29 Jun 2006 18:12:08 -0500 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: <1151614948.6570.207.camel@localhost.localdomain> (Ville Skytt's message of "Fri, 30 Jun 2006 00:02:28 +0300") References: <1151614948.6570.207.camel@localhost.localdomain> Message-ID: >>>>> "VS" == Ville Skytt writes: VS> Do those %defines at the top work in mock/plague setups where pear VS> is not installed at the time the build begins? Note that what's required here is that the spec maintains correct syntax when those pear calls fail, as they will when the spec is first "run" to extract its dependencies. In this case, they will evaluate to something reasonable. and should be fine. - J< From chris.stone at gmail.com Thu Jun 29 23:18:26 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 29 Jun 2006 16:18:26 -0700 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: References: <44A38DFD.3030000@timj.co.uk> <44A45630.3040608@timj.co.uk> Message-ID: On 6/29/06, Jason L Tibbitts III wrote: > >>>>> "CS" == Christopher Stone writes: > CS> Personally I want as little liability on me as a packager as > CS> possible. > > Note that this would essentially require no interpretation of the > license whatever. If indeed there is some liability issues on the packager on the License field, I think then it should be discussed about placing a weblink in the License field and have some type of standard such as: License: Fedora Approved (GPL) http://fedoraproject.org/wiki/.. The wiki page would then explain the different class of licenses acceptable by Fedora and note that the (GPL) indicates a class of licenses associated with GPL, etc. Or even omitting the (GPL) part. This would be ideal, but probably on a more realistic standpoint the status quo will remain, that is the License field is up to the packager and should just remain a should item on reviews. However, I think there should be a consensus on what should be considered "best practice" if the packager is in doubt. From chris.stone at gmail.com Thu Jun 29 23:53:16 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 29 Jun 2006 16:53:16 -0700 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: References: <44A38DFD.3030000@timj.co.uk> <44A45630.3040608@timj.co.uk> Message-ID: On 6/29/06, Jason L Tibbitts III wrote: > >>>>> "CS" == Christopher Stone writes: > So let me see if I can correctly summarize the open questions: Here are my questions: 1) Is there truely any liability on the packager for what is contained in the license tag? 2) What is the actual purpose of the license tag? A definition should be in place on what this actually is. 3) Clarification on if there is any legal binding to the license tag. 4) Should rpmlint be enhanced to allow version numbers on license tags? From lists at timj.co.uk Fri Jun 30 10:32:47 2006 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 30 Jun 2006 11:32:47 +0100 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: References: Message-ID: <44A4FDCF.5020104@timj.co.uk> Jason L Tibbitts III wrote: > Here are some open issues I see with the PHP guidelines. First of all, thanks for your work on this. As you and others may (or may not) have spotted from various activity in FE/RH Bugzilla/PEAR [1], I've spent a lot of time on PHP/RPM-related issues in the last few months and getting some concrete guidelines in place is great. I'm glad there is a bit of momentum behind this and I'm not the only one trying to make this stuff easier :) (Background: I do a lot of PHP web application deployment and development, and package management/dependency resolution has always been a bugbear of mine; complete non-portability, complex setup and random problems due to missing deps are a regular feature of trying to deploy apps when all I want to do is "yum install [package]" and have a minimum of configuration necessary) Note that my goal with the PEAR_Command_Packaging package in particular (forked, with the blessing and help of the PEAR maintainer, from PEAR core 'makerpm' command which it now obsoletes) has always been to make it so that "pear make-rpm-spec Foo_Bar.tgz" on Fedora will produce a spec compliant with FE guidelines. I'm not there yet, but getting closer. The php-pear-DB package that I submitted and which is in Extras was mostly a proof-of-concept to help establish what is a "good" spec file for a PEAR package. > 1) The php(ABI) symbol. The current PHP package (in FC5) provides > php-api = 20041225; is that sufficient? Should be, I think although arguably "php" should provide php(ABI) or php-abi and "php-devel" should provide php(API) or php-api. The poor naming originated from my original suggestion over in bug #183227 I'm afraid :/ > 2) Somethig equivalent to perl(:MODULE_COMPAT_version). The base PHP > package eventually provides a whole bunch of these indicating what > releases a module could have been written against and still work. > So php v6 can drop compatibility for anything before v4.2 and the > package can drop the corresponding :MODULE_COMPAT symbols. Sounds reasonable. I'm not familiar with how it's done in Perl; can we copy it? > 3) It seems there are plenty of extensions which are neither PEAR nor > PECL. We need to figure out conventions for those. We already have some in FE like php-shout. Personally I'm not uncomfortable with that convention, the only caveat being that there's no immediate way of distinguishing what's a "core" extension and what's a third party one. > 4) Scriptlets for registering PEAR packages. Several different variations that I've used over time, and ideas from others have meant that personally I've settled on (for PEAR >=1.4.7) the following fragments, as featured in Chris S's spec template: %post pear install --nodeps --soft --force --register-only \ %{xmldir}/Foo_Bar.xml >/dev/null ||: %postun if [ "$1" -eq "0" ]; then pear uninstall --nodeps --ignore-errors --register-only \ Foo_Bar >/dev/null ||: fi Indeed, these (minus the ||: which I will add) are used by default by PEAR_Command_Packaging both upstream and in my proposed FE package. > 5) There is some functionality in php-pear which only made it in as of > some specific version, I think 1.4.9, which needs to be there in > order for something work work. Maybe this: http://pear.php.net/bugs/7093 Also I fixed some stuff related to --packagingroot in 1.4.7: http://cvs.php.net/viewvc.cgi/pear-core/PEAR/Command/Install.php?view=log#rev1.113 http://pear.php.net/bugs/6480 there are also http://pear.php.net/bugs/6673 http://pear.php.net/bugs/6674 I would consider 1.4.7 as a minimum base version for future RPM-related stuff. Since 1.4.8 is broken, 1.4.9 is arguably the base. Tim [1] a non-exhaustive list includes: RH #194852 - php Provides and Obsoletes mod_php RH #173980 - pear makerpm docs problem RH #183227 - PHP API needs encoding as a Provide ( php-api php(API) ) RH #173806 - php-pear does not have Provides: RH #175074 - php-pear provides php-pear(PEAR_PEAR) not php-pear(PEAR) RH #173808 - php-pear has too much bundled in it RH #173810 - php-pear should be built separately from main php rpm RH #173814 - pear makerpm does not generate deps on other PEAR packages RH #194583 - php should Provide php-posix RH #187891 - php package should provide mod_php, php-apache, php-apache2 or similar RH #173802 - template.spec naming convs RH #173804 - php core rpm does not have Provides RH #176725 - miscellaneous "pear makerpm" problems PEAR #6373 - pear makerpm generates RPMs that cannot be uninstalled PEAR #6375 - "pear makerpm" misc. improvements (rpm-depname, rpm-release options) PEAR #6377 - "pear makerpm" post/postun improvements to cope with non-RPM installs PEAR #6378 - "pear makerpm" generates packages that conflict due to depdb/.channels PEAR #6480 - pear install --installroot option fails for pecl packages PEAR #5959 - post/postun prob PEAR #6047 - doc problem PEAR #6963 - Duplicate Requires deps generated in some cases PEAR #6971 - Create deps on php-[ext] PEAR #7118 - Remove "doc hack" from template spec file PEAR package PEAR_Command_Packaging - http://pear.php.net/package/PEAR_Command_Packaging Fedora Extras RH #176658 - php-pear-DB package RH #185423 - php-pear-PEAR-Command-Packaging package RH #196281 - php-manual-en package From lists at timj.co.uk Fri Jun 30 10:40:42 2006 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 30 Jun 2006 11:40:42 +0100 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: References: Message-ID: <44A4FFAA.6020101@timj.co.uk> Christopher Stone wrote: > I have put up what I think is a good template for pear modules here: > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec Great, thanks for the work on this. You seem to have simplified/improved some aspects of what I'd come up with so far as a "best" spec as used in a slightly less generic form in: http://www.timj.co.uk/linux/specs/php-pear-PEAR-Command-Packaging.spec I haven't had a chance to try it yet but will do so with PEAR_Command_Packaging soon. Immediate (minor) points from a visual scan: a) Requires: php - is this necessary? Surely a dep on php-pear(PEAR) is sufficient, since that will itself pull PHP in? b) Provides: php-Foo-Bar - what's the reasoning behind this? c) You've removed all the pearrc cruft - if this really works (which it looks like it should) then GREAT! I inherited that from previous work by other people and have never really thought about it but logically since we have a BR of php-pear, then the PEAR defaults should be appropriate for our distro and there's no need to construct a temporary pearrc. d) I think "%{__cp} -p package.xml" should be replaced with "%{__install} -m 644 ...", just as a good practice thing Tim From lists at timj.co.uk Fri Jun 30 10:49:36 2006 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 30 Jun 2006 11:49:36 +0100 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: References: Message-ID: <44A501C0.5080404@timj.co.uk> Jason L Tibbitts III wrote: > 6) We need to work up specfile templates for all three situations if > appropriate and get them into fedora-rpmdevtools. General point extending what I mentioned earlier: whilst I certainly wouldn't want for a minute to try to force it on anyone, would it be worth considering simply mandating "pear make-rpm-spec [package]" as the "official" way of generating a template spec? The main reasons are: a) it seems a bit of duplication to have this in fedora-rpmdevtools when I'm working on it separately anyway, and the entire point why I took on PEAR_Command_Packaging was ultimately so that I could auto-generate specs for Fedora/RHEL. Upstream is of course done in a distro-neutral way, but my proposed FE package patches it (which is now simple thanks to the upstream changes I've made) to match Fedora conventions. b) "pear make-rpm-spec" can incorporate additional time-saving logic that a static template with simple substitutions can't; some existing features include: - prefilling %description - generating stuff relating to docs dependent on whether or not the package actually includes docs (many don't) Of course, there could be a hook in fedora-rpmdevtools which called out to "pear make-rpm-spec" if the above was liked but it was considered preferable to have all the template specs at least superficially generate-able from fedora-rpmdevtools. I must stress that I'm not trying to "own" spec-template-generation for PEAR packages here, merely save duplication and hopefully see the existing work I've done in this area be useful. I'd warmly welcome any offers to co-maintain PEAR_Command_Packaging, the corresponding FE package, or both. Tim P.S. It doesn't really work atm, but my intention is also to make "pear make-rpm-spec" work for PECL packages too. From lists at timj.co.uk Fri Jun 30 10:50:44 2006 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 30 Jun 2006 11:50:44 +0100 Subject: [Fedora-packaging] Re: License tag in packages In-Reply-To: References: <44A38DFD.3030000@timj.co.uk> <44A45630.3040608@timj.co.uk> Message-ID: <44A50204.2070401@timj.co.uk> Jason L Tibbitts III wrote: >>>>>> "CS" == Christopher Stone writes: > > CS> I missed this week's FESCo meeting so I don't know if it was > CS> brought up, but there should be a FESCo descision on "best > CS> practices" when the packager is in doubt. > > Actually this is no longer in the FESCo bailiwick. The packaging > committee is now deciding these things for both Core and Extras, and > you're essentially reaching the committee by posting here. OK, thanks for the interest. I think your summary of issues was good there, plus I agree with the additions Chris S made. Tim From ville.skytta at iki.fi Fri Jun 30 11:21:49 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 30 Jun 2006 14:21:49 +0300 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: <44A501C0.5080404@timj.co.uk> References: <44A501C0.5080404@timj.co.uk> Message-ID: <1151666510.6570.259.camel@localhost.localdomain> On Fri, 2006-06-30 at 11:49 +0100, Tim Jackson wrote: > Of course, there could be a hook in fedora-rpmdevtools which called out > to "pear make-rpm-spec" if the above was liked but it was considered > preferable to have all the template specs at least superficially > generate-able from fedora-rpmdevtools. I don't personally care where the spec templates come from, but I'd like all of them be generateable by fedora-newrpmspec. Its pre-filling capabilities are pretty limited kludges at the moment, and sounds like your stuff is capable of much more already, so as long as the result meets the guidelines, I'd be glad to apply patches that add such a hook. >From the hook POV, it would be easiest if "pear make-rpm-spec" would take the package name in a command line option, and would be capable of emitting the generated template to stdout, perhaps conditionally based on existence of some other command line option. Maybe it already works that way? I wouldn't like a dependency on pear in rpmdevtools, so on pear execution failures (eg. when not installed), newrpmspec should probably just fall back to the generic template. From lists at timj.co.uk Fri Jun 30 11:49:52 2006 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 30 Jun 2006 12:49:52 +0100 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: <1151666510.6570.259.camel@localhost.localdomain> References: <44A501C0.5080404@timj.co.uk> <1151666510.6570.259.camel@localhost.localdomain> Message-ID: <44A50FE0.6050909@timj.co.uk> Ville Skytt? wrote: > I don't personally care where the spec templates come from, but I'd like > all of them be generateable by fedora-newrpmspec. Its pre-filling > capabilities are pretty limited kludges at the moment, and sounds like > your stuff is capable of much more already, so as long as the result > meets the guidelines, I'd be glad to apply patches that add such a hook. OK, great. I think you'd have a hard time replicating the *potential* pre-filling capabilities of PEAR_Command_Packaging, since it's intimately tied into PEAR and knows how to analyse the package's XML file, work out deps etc. In fact what I didn't mention before is that it does of course also auto-generate the Requires:, which is a major bonus. As soon as we're all settled on a template spec, high on my priority list will be making php-pear-PEAR_Command_Packaging generate specs that comply with that template format, including upstream changes if required (although hopefully the development has reached a sufficiently advanced stage now that upstream changes should be minimal or zero; most can simply be achieved by patching/replacing the template.spec provided by php-pear-PEAR-Command-Packaging in %{peardir}/data/PEAR_Command_Packaging/template.spec) >>From the hook POV, it would be easiest if "pear make-rpm-spec" would > take the package name in a command line option, and would be capable of > emitting the generated template to stdout, perhaps conditionally based > on existence of some other command line option. Maybe it already works > that way? Nearly. Currently it takes the *filename* of a package tarball and outputs the resulting template to stdout. Bear in mind that to do all the clever stuff it does, it needs to have a copy of the actual package tarball, not just the package name. But then if you're about to build an RPM, you're going to need this anyway... If there was enough demand I could build in a hook to go off to pear.php.net and download the package tarball given a package name, but unless there's a compelling reason this is probably adding unnecessary complexity when a "wget" prior to calling make-rpm-spec will do the trick. > I wouldn't like a dependency on pear in rpmdevtools, so on pear > execution failures (eg. when not installed), newrpmspec should probably > just fall back to the generic template. Fair enough; I'd had the exact same thought. In that case, there should probably also be a) an informational message telling you that this is happening b) a way to get newrpmspec to use the generic template *in any case*, so that if (for some weird reason) you don't want to download the actual PEAR package and just get a template spec based on the package *name* alone, you can. Tim From rc040203 at freenet.de Fri Jun 30 12:31:29 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 30 Jun 2006 14:31:29 +0200 Subject: [Fedora-packaging] Re: rpms/haddock/devel haddock.spec,1.2,1.3 In-Reply-To: <200606300311.k5U3BTYw016261@cvs-int.fedora.redhat.com> References: <200606300311.k5U3BTYw016261@cvs-int.fedora.redhat.com> Message-ID: <1151670690.15566.76.camel@mccallum.corsepiu.local> On Thu, 2006-06-29 at 20:11 -0700, Jens Petersen wrote: > Author: petersen > > Update of /cvs/extras/rpms/haddock/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16242 > > Modified Files: > haddock.spec > Log Message: > - set selinux unconfined_execmem_exec_t context to allow running under > targeted policy (#195821) > > > > Index: haddock.spec > =================================================================== > RCS file: /cvs/extras/rpms/haddock/devel/haddock.spec,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- haddock.spec 29 Jun 2006 12:23:45 -0000 1.2 > +++ haddock.spec 30 Jun 2006 03:11:26 -0000 1.3 > @@ -10,6 +10,8 @@ > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > BuildRequires: ghc libxslt docbook-style-xsl > +# need chcon > +PreReq: coreutils > > %description > Haddock is a tool for automatically generating hyperlinked documentation from > @@ -53,6 +55,11 @@ > %clean > rm -rf ${RPM_BUILD_ROOT} > > + > +%post > +/usr/bin/chcon -t unconfined_execmem_exec_t %{_libexecdir}/haddock.bin >/dev/null 2>&1 || : I think, we should implement a policy to make * Requires(pre|post) mandatory instead of PreReq * To make file deps on tools being used in %pre|post scripts mandatory. Ralf From rdieter at math.unl.edu Fri Jun 30 12:42:54 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 30 Jun 2006 07:42:54 -0500 Subject: [Fedora-packaging] Re: rpms/haddock/devel haddock.spec,1.2,1.3 In-Reply-To: <1151670690.15566.76.camel@mccallum.corsepiu.local> References: <200606300311.k5U3BTYw016261@cvs-int.fedora.redhat.com> <1151670690.15566.76.camel@mccallum.corsepiu.local> Message-ID: <44A51C4E.609@math.unl.edu> Ralf Corsepius wrote: > I think, we should implement a policy to make > > * Requires(pre|post) > mandatory instead of PreReq I'd say recommended or strongly encouraged. There are still a few valid uses for PreReq. I use Prereq: foo occasionally as short-hand for Requires: foo Requires(pre): foo Requires(post): foo > * To make file deps on tools being used in %pre|post scripts mandatory. +1 -- Rex From ville.skytta at iki.fi Fri Jun 30 12:58:19 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 30 Jun 2006 15:58:19 +0300 Subject: [Fedora-packaging] Re: rpms/haddock/devel haddock.spec,1.2,1.3 In-Reply-To: <1151670690.15566.76.camel@mccallum.corsepiu.local> References: <200606300311.k5U3BTYw016261@cvs-int.fedora.redhat.com> <1151670690.15566.76.camel@mccallum.corsepiu.local> Message-ID: <1151672299.6570.291.camel@localhost.localdomain> On Fri, 2006-06-30 at 14:31 +0200, Ralf Corsepius wrote: > I think, we should implement a policy to make > > * Requires(pre|post) > mandatory instead of PreReq -1 for that wording, they are not the same thing. http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED On the other hand, +1 if you mean just that relying on PreReq to cover scriptlet dependencies is a no-no. > * To make file deps on tools being used in %pre|post scripts mandatory. +1 when the tools are really required. An example when they are not is eg. the GTK+ icon cache entry at http://fedoraproject.org/wiki/ScriptletSnippets From rc040203 at freenet.de Fri Jun 30 13:06:41 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 30 Jun 2006 15:06:41 +0200 Subject: [Fedora-packaging] Re: rpms/haddock/devel haddock.spec,1.2,1.3 In-Reply-To: <1151672299.6570.291.camel@localhost.localdomain> References: <200606300311.k5U3BTYw016261@cvs-int.fedora.redhat.com> <1151670690.15566.76.camel@mccallum.corsepiu.local> <1151672299.6570.291.camel@localhost.localdomain> Message-ID: <1151672802.15566.95.camel@mccallum.corsepiu.local> On Fri, 2006-06-30 at 15:58 +0300, Ville Skytt? wrote: > On Fri, 2006-06-30 at 14:31 +0200, Ralf Corsepius wrote: > > > I think, we should implement a policy to make > > > > * Requires(pre|post) > > mandatory instead of PreReq > > -1 for that wording, they are not the same thing. > http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED > > On the other hand, +1 if you mean just that relying on PreReq to cover > scriptlet dependencies is a no-no. Originially, I was referring to PreReq in the context of Jens' spec file: He is running /usr/bin/chcon in a %post scriptlet. I.e. he actually wants Requires(post) and doesn't want PreReq. And ... given the difference between older "PreReq" and newer "PreReq" (==Require), described in the link above, I am even stronger in favor of "disallowing PreReq", to avoid problems related to the behavioral changes. > > > * To make file deps on tools being used in %pre|post scripts mandatory. > > +1 when the tools are really required. An example when they are not is > eg. the GTK+ icon cache entry at > http://fedoraproject.org/wiki/ScriptletSnippets C.f. Jens spec file: He is using /usr/bin/chcon in a %post scriptlet and "PreReq: coreutils". This will break should /usr/bin/chcon be moved or removed. Ralf From jorton at redhat.com Fri Jun 30 09:52:30 2006 From: jorton at redhat.com (Joe Orton) Date: Fri, 30 Jun 2006 10:52:30 +0100 Subject: [Fedora-packaging] PHP packaging policy notes Message-ID: <20060630095230.GA19767@redhat.com> cc'ing Tim since we had lots of discussion about much of this stuff already and I'm not sure if he's on fedora-packaging (I didn't even know that list existed...) I was planning to add a "php-abi = " definition for C ABI versioning rather than php(ABI). Versioning language features in PHP a la MODULE_COMPAT_* is just not going to be feasible; the language is not well-defined enough nor stable enough for us to try and enforce versioning; plus stuff like "zend.ze1_compatibility_mode" means the exposed language is dependent on config options anyway. I don't see why it's necessary for a PEAR package to require php-pear(PEAR); that is somewhat equivalent to an RPM having "Requires: rpm"; it should be sufficient and correct for PEAR packages to simply "Requires: php-pear" AFAICS. Why should a PEAR package for foo provide php-foo? Not sure that's a good idea. On "Other Packages": an application written in PHP or such like should not have a php- prefix at all. A Smarty package should be called "smarty" (following the "upper-case is evil" rule of packaging). joe From ville.skytta at iki.fi Fri Jun 30 13:21:04 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 30 Jun 2006 16:21:04 +0300 Subject: [Fedora-packaging] Open issues with the PHP guidelines In-Reply-To: <44A50FE0.6050909@timj.co.uk> References: <44A501C0.5080404@timj.co.uk> <1151666510.6570.259.camel@localhost.localdomain> <44A50FE0.6050909@timj.co.uk> Message-ID: <1151673664.6570.310.camel@localhost.localdomain> On Fri, 2006-06-30 at 12:49 +0100, Tim Jackson wrote: > Ville Skytt? wrote: > > OK, great. I think you'd have a hard time replicating the *potential* > pre-filling capabilities of PEAR_Command_Packaging, since it's > intimately tied into PEAR and knows how to analyse the package's XML > file, work out deps etc. Yeah, I thought so :) > >>From the hook POV, it would be easiest if "pear make-rpm-spec" would > > take the package name in a command line option, and would be capable of > > emitting the generated template to stdout, perhaps conditionally based > > on existence of some other command line option. Maybe it already works > > that way? > > Nearly. Currently it takes the *filename* of a package tarball and > outputs the resulting template to stdout. Bear in mind that to do all > the clever stuff it does, it needs to have a copy of the actual package > tarball, not just the package name. Hm, that could be somewhat problematic. newrpmspec takes the package name, so it would need to know how to transform that into a tarball filename including the full path to it, and including the possible version number in the tarball filename. newrpmspec's interface is not set in stone, but I'd prefer if one could continue to do for example "fedora-newrpmspec php-pear-Foo_Bar.spec" (and "emacs php-pear-Foo_Bar.spec") and everything would Just Work. Ideas? > > I wouldn't like a dependency on pear in rpmdevtools, so on pear > > execution failures (eg. when not installed), newrpmspec should probably > > just fall back to the generic template. > > Fair enough; I'd had the exact same thought. In that case, there should > probably also be > > a) an informational message telling you that this is happening That would be trivial to add. > b) a way to get newrpmspec to use the generic template *in any case*, so > that if (for some weird reason) you don't want to download the actual > PEAR package and just get a template spec based on the package *name* > alone, you can. Already doable with the -t option to fedora-newrpmspec, see --help for details. From tcallawa at redhat.com Fri Jun 30 13:37:24 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 30 Jun 2006 08:37:24 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <20060630095230.GA19767@redhat.com> References: <20060630095230.GA19767@redhat.com> Message-ID: <1151674644.7108.15.camel@localhost.localdomain> On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote: > On "Other Packages": an application written in PHP or such like should > not have a php- prefix at all. A Smarty package should be called > "smarty" (following the "upper-case is evil" rule of packaging). Indeed, this is correct. The php-* (and php-pecl/pear) namespace are reserved for items that add new functionality/modules to PHP, not for applications written in PHP. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From paul at city-fan.org Fri Jun 30 13:53:56 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 30 Jun 2006 14:53:56 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1151674644.7108.15.camel@localhost.localdomain> References: <20060630095230.GA19767@redhat.com> <1151674644.7108.15.camel@localhost.localdomain> Message-ID: <44A52CF4.9000002@city-fan.org> Tom 'spot' Callaway wrote: > On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote: > >> On "Other Packages": an application written in PHP or such like should >> not have a php- prefix at all. A Smarty package should be called >> "smarty" (following the "upper-case is evil" rule of packaging). > > Indeed, this is correct. The php-* (and php-pecl/pear) namespace are > reserved for items that add new functionality/modules to PHP, not for > applications written in PHP. Smarty is not an application in itself; it's a library of PHP code used in other applications. As such it adds functionality to PHP... Paul. From tcallawa at redhat.com Fri Jun 30 14:21:29 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 30 Jun 2006 09:21:29 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <44A52CF4.9000002@city-fan.org> References: <20060630095230.GA19767@redhat.com> <1151674644.7108.15.camel@localhost.localdomain> <44A52CF4.9000002@city-fan.org> Message-ID: <1151677289.7108.18.camel@localhost.localdomain> On Fri, 2006-06-30 at 14:53 +0100, Paul Howarth wrote: > Tom 'spot' Callaway wrote: > > On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote: > > > >> On "Other Packages": an application written in PHP or such like should > >> not have a php- prefix at all. A Smarty package should be called > >> "smarty" (following the "upper-case is evil" rule of packaging). > > > > Indeed, this is correct. The php-* (and php-pecl/pear) namespace are > > reserved for items that add new functionality/modules to PHP, not for > > applications written in PHP. > > Smarty is not an application in itself; it's a library of PHP code used > in other applications. As such it adds functionality to PHP... Then (in the case of smarty), it does need to be in the php namespace. I think if its not a pecl/pear, but it adds functionality to PHP, then it should be php-%{name}. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From paul at city-fan.org Fri Jun 30 14:32:08 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 30 Jun 2006 15:32:08 +0100 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <1151677289.7108.18.camel@localhost.localdomain> References: <20060630095230.GA19767@redhat.com> <1151674644.7108.15.camel@localhost.localdomain> <44A52CF4.9000002@city-fan.org> <1151677289.7108.18.camel@localhost.localdomain> Message-ID: <44A535E8.1080608@city-fan.org> Tom 'spot' Callaway wrote: > On Fri, 2006-06-30 at 14:53 +0100, Paul Howarth wrote: >> Tom 'spot' Callaway wrote: >>> On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote: >>> >>>> On "Other Packages": an application written in PHP or such like should >>>> not have a php- prefix at all. A Smarty package should be called >>>> "smarty" (following the "upper-case is evil" rule of packaging). >>> Indeed, this is correct. The php-* (and php-pecl/pear) namespace are >>> reserved for items that add new functionality/modules to PHP, not for >>> applications written in PHP. >> Smarty is not an application in itself; it's a library of PHP code used >> in other applications. As such it adds functionality to PHP... > > Then (in the case of smarty), it does need to be in the php namespace. I > think if its not a pecl/pear, but it adds functionality to PHP, then it > should be php-%{name}. Which is good, since it's already in Extras as php-Smarty Paul. From toshio at tiki-lounge.com Fri Jun 30 16:31:09 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 30 Jun 2006 09:31:09 -0700 Subject: [Fedora-packaging] Re: rpms/haddock/devel haddock.spec,1.2,1.3 In-Reply-To: <1151672299.6570.291.camel@localhost.localdomain> References: <200606300311.k5U3BTYw016261@cvs-int.fedora.redhat.com> <1151670690.15566.76.camel@mccallum.corsepiu.local> <1151672299.6570.291.camel@localhost.localdomain> Message-ID: <1151685070.2718.13.camel@localhost> On Fri, 2006-06-30 at 15:58 +0300, Ville Skytt? wrote: > On Fri, 2006-06-30 at 14:31 +0200, Ralf Corsepius wrote: > > > I think, we should implement a policy to make > > > > * Requires(pre|post) > > mandatory instead of PreReq > > -1 for that wording, they are not the same thing. > http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED > > On the other hand, +1 if you mean just that relying on PreReq to cover > scriptlet dependencies is a no-no. > +1 Maybe wording like: The use of PreReq to install a package prior to installing this one has been deprecated within rpm. Inside of spec files the Prereq tag should be replaced with a plain Requires line or the [http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED context marked Requires] that expresses when the requirement needs to be met. > > * To make file deps on tools being used in %pre|post scripts mandatory. > > +1 when the tools are really required. An example when they are not is > eg. the GTK+ icon cache entry at > http://fedoraproject.org/wiki/ScriptletSnippets > What is the reason to use file dependencies? Clarity when comparing Requires to scriptlets? To protect against programs moving to a different package? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Fri Jun 30 20:28:30 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 30 Jun 2006 13:28:30 -0700 Subject: [Fedora-packaging] New Mono Page for new guidelines Message-ID: <1151699310.2718.53.camel@localhost> I've reworked the Mono page to reflect the new Guidelines we confirmed yesterday. If people want to take a look, it's here: http://fedoraproject.org/wiki/PackagingDrafts/Mono Changes are color coded: Red removes, green adds, blue is a justification for people who didn't attend the meeting and will be removed from the final copy. (I probably should have done this before the meeting rather than after, sorry.) If no one objects, I'll replace the current Packaging/Mono page this weekend. This is also an example of how the PackagingDrafts area could be used to work on new or revised Drafts. DavidLutterkort's RubyGems is another: http://fedoraproject.org/wiki/PackagingDrafts/RubyGems -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Fri Jun 30 21:36:25 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 30 Jun 2006 14:36:25 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: <44A535E8.1080608@city-fan.org> References: <20060630095230.GA19767@redhat.com> <1151674644.7108.15.camel@localhost.localdomain> <44A52CF4.9000002@city-fan.org> <1151677289.7108.18.camel@localhost.localdomain> <44A535E8.1080608@city-fan.org> Message-ID: As it is now, the php-pecl spec files have a group of Development/Language and the php-pear spec file use a group of Development/Libraries Shouldn't this be reversed? Afterall, the pecl packages are packaged with a .so file and the pear packages are all .php files. So I am a little confused on what the groups should be. From chris.stone at gmail.com Fri Jun 30 21:48:37 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 30 Jun 2006 14:48:37 -0700 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1151674644.7108.15.camel@localhost.localdomain> <44A52CF4.9000002@city-fan.org> <1151677289.7108.18.camel@localhost.localdomain> <44A535E8.1080608@city-fan.org> Message-ID: There are going to be many pear packages which share a directory such as Auth/ or Image/ or Net/ etc. The simple rule of thumb in this case is that if there is no clear heirarchy of directory ownership, then all packages must own that directory. This should be added to the PHP packaging guidelines since this goes against the Fedora Extras guidelines which state that the package must not own files or directories owned by other packages. From tcallawa at redhat.com Fri Jun 30 22:41:20 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 30 Jun 2006 17:41:20 -0500 Subject: [Fedora-packaging] PHP packaging policy notes In-Reply-To: References: <20060630095230.GA19767@redhat.com> <1151674644.7108.15.camel@localhost.localdomain> <44A52CF4.9000002@city-fan.org> <1151677289.7108.18.camel@localhost.localdomain> <44A535E8.1080608@city-fan.org> Message-ID: <1151707280.7108.69.camel@localhost.localdomain> On Fri, 2006-06-30 at 14:48 -0700, Christopher Stone wrote: > There are going to be many pear packages which share a directory such > as Auth/ or Image/ or Net/ etc. > > The simple rule of thumb in this case is that if there is no clear > heirarchy of directory ownership, then all packages must own that > directory. > > This should be added to the PHP packaging guidelines since this goes > against the Fedora Extras guidelines which state that the package must > not own files or directories owned by other packages. Instead of adding it to the PHP packaging guideline, the directory ownership rule should be clarified in the main guideline. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!