From rdieter at math.unl.edu Fri Mar 3 15:47:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Mar 2006 09:47:47 -0600 Subject: [Fedora-packaging] --vendor fedora, rationale/motivation? Message-ID: Per http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines: The vendor prefix (desktop-file-install --vendor=...) must be set to fedora". I don't understand the rationale/motivation behind requiring '--vendor fedora' I can, however, see that desktop-file-install's current implementation(*) of prepending %{vendor}- to the .desktop file name has some problems/issues: 1. .desktop filename now varies from upstream 2. --vendor may change when/if Extras bits are pulled into Core and/or RHEL. 3. *In particular*: when users start employing menu editors, since most(all?) of them base their customizations on the .desktop file name. -- Rex (*) If desktop-file-install's implementation instead followed something like kde's practice of using a vendor directory (e.g. /usr/share/applications/kde), then (1) and (3) would no longer be an issue. From rdieter at math.unl.edu Fri Mar 3 17:31:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Mar 2006 11:31:09 -0600 Subject: [Fedora-packaging] --vendor fedora, rationale/motivation? In-Reply-To: References: Message-ID: <44087D5D.9050804@math.unl.edu> Rex Dieter wrote: > 3. *In particular*: when users start employing menu editors, since > most(all?) of them base their customizations on the .desktop file name. I stopped in mid-thought, sorry. The point of this is that menu editing will be troublesome/buggy when/if .desktop filenames change. -- Rex From caillon at redhat.com Sat Mar 4 07:08:58 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 04 Mar 2006 02:08:58 -0500 Subject: [Fedora-packaging] --vendor fedora, rationale/motivation? In-Reply-To: References: Message-ID: <44093D0A.7000904@redhat.com> On 03/03/2006 10:47 AM, Rex Dieter wrote: > Per > http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines: > The vendor prefix (desktop-file-install --vendor=...) must be set to > fedora". > > I don't understand the rationale/motivation behind requiring '--vendor > fedora' It should match the vendor of the .desktop file. If you are distributing a GNOME desktop file, it should be --vendor gnome. If there is no .desktop file and you write one, then it should be --vendor fedora. The wiki should be updated to reflect this. From ville.skytta at iki.fi Sat Mar 4 09:21:23 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 04 Mar 2006 11:21:23 +0200 Subject: [Fedora-packaging] --vendor fedora, rationale/motivation? In-Reply-To: <44093D0A.7000904@redhat.com> References: <44093D0A.7000904@redhat.com> Message-ID: <1141464083.10477.148.camel@bobcat.mine.nu> On Sat, 2006-03-04 at 02:08 -0500, Christopher Aillon wrote: Some food for thought below. > If you are > distributing a GNOME desktop file, it should be --vendor gnome. What is "a GNOME desktop file"? A .desktop file included with an app that is distributed from gnome.org? A .desktop file for an app distributed from somewhere else but uses GNOME libraries? Something else? If I can identify an upstream vendor prefix with sufficient confidence but make heavy modifications to the .desktop file they ship, should I preserve the upstream vendor prefix or change it? If the upstream vendor changes, for example in the case of an app previously distributed by an "independent" vendor gets rolled into GNOME proper, should the vendor identifier of the .desktop file I ship change too? > If > there is no .desktop file and you write one, then it should be --vendor > fedora. After the .desktop file I wrote and included in package version X gets included in the X+1 upstream version and I update the package to that, do I leave the desktop vendor prefix as is to "fedora" or sync it with the upstream vendor name? > The wiki should be updated to reflect this. I don't think it's quite that clear cut. GNOME and self-written .desktop files are from the easier end of cases even though as shown, they're not entirely trivial either, but there's lots of cases where upstream ships a .desktop file and inventing a sane vendor string would be harder. Quite frankly, I think the "always use fedora" approach is a sufficiently low-problem one. Or maybe make it "if upstream doesn't clearly indicate their vendor identifier (eg. through a desktop-file-install invocation in their Makefiles), use fedora, and whatever you choose, make sure the vendor prefix won't change between package revisions". See also the last two paragraphs of the "Merging" chapter at http://standards.freedesktop.org/menu-spec/menu-spec-latest.html#merge-algorithm From jamatos at fc.up.pt Tue Mar 7 11:12:16 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Tue, 7 Mar 2006 11:12:16 +0000 Subject: [Fedora-packaging] License landscape (and question of best pratice) Message-ID: <200603071112.17010.jamatos@fc.up.pt> Hi, I have packed several R modules. R modules have a description file with a license field. Lots of those modules have as license: GPL version 2 or later. Should this be placed in the spec file as GPL or allow the fully license as described in the DESCRIPTION file? While searching for tags used in the License field for Extras I got this result: $ grep -h ^License: */devel/*.spec | sed -e 's|License:||' | sed -e 's|^\s*||' | sed -e 's|\s*$||' | sort | uniq -c | sort -nr 734 GPL 215 GPL or Artistic 152 LGPL 106 BSD 40 MIT 28 Distributable 22 Artistic 11 BSD-like 11 Artistic or GPL 10 Public Domain 8 LaTeX Project Public License 6 CPL 5 PHP 5 GPL/LGPL 5 BSD-ish 4 GPL/BSD 4 Freely distributable 4 Apache Software License 3 W3C Software License 3 SIL Open Font License 3 Redistributable, with restrictions 3 Python Software Foundation License 3 OSGPL 3 Freeware 2 QPL 2 PSF 2 NetHack General Public License 2 GPL, LGPL 2 CNRI 2 BSD-style 1 ZPL 1 zlib/libpng 1 wxWidgets Library Licence 1 W3C (see: http://www.w3.org/Consortium/Legal/copyright-software.html) 1 VOSTROM Public License 1 University of Washington Free-Fork License 1 The PHP License 1 Redistributable 1 QPL/LGPL 1 Python License (CNRI Python License) 1 Public Domain, BSD, Python License, GPL - see COPYING.txt 1 PSF or ZPL 1 PSFL/ZPL 1 Other 1 NetCDF 1 Neotonic ClearSilver Software License 1 MPL/LGPL 1 MPL/GPL/LGPL 1 MPL 1 MIT/X Consortium License 1 MIT/X11 1 MIT-style 1 MIT, GPL, LGPL 1 MIT and GPL 1 MIT/Academic 1 LGPL with exceptions 1 LGPL/W3C 1 LGPL/MPL 1 LGPL/MIT 1 LGPL, GPL, Historical Permission Notice and Disclaimer 1 LGPL/GPL 1 LGPL for library, GPL for utilities 1 LGPL/BSD 1 LGPL (binaries GPL) 1 Kannel 1 JasPer License Version 2.0 1 Intel Open Source License 1 IBM Public License 1 GPL version 2 or newer 1 GPL version 2 or later. 1 GPL version 2 or later 1 GPLv2 1 GPL, MIT/X11 for X11 bits 1 GPL & MIT 1 GPL and modified LGPL 1 GPL and Free Art License 1 GNU Free Documentation License 1 Giftware 1 Freely distributable (BSD-like) 1 Free 1 Erlang Public License 1 Distributable (Unknown) 1 BSD w/ advertising 1 BSD style 1 BSD/PSF -- see COPYING 1 BSD/MIT 1 BSD like 1 BSDish 1 BSD, GPL 1 BSD and LGPL 1 BitTorrent Open Source License 1 ASL-derived 1 Artistic/LGPL 1 Apacheish 1 Aladdin Free Public License, Ghostgum Software Pty Ltd 1 3DFX GLIDE Source Code General Public License -- Jos? Ab?lio From rc040203 at freenet.de Tue Mar 7 11:49:05 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 07 Mar 2006 12:49:05 +0100 Subject: [Fedora-packaging] License landscape (and question of best pratice) In-Reply-To: <200603071112.17010.jamatos@fc.up.pt> References: <200603071112.17010.jamatos@fc.up.pt> Message-ID: <1141732145.5228.195.camel@mccallum.corsepiu.local> On Tue, 2006-03-07 at 11:12 +0000, Jose' Matos wrote: > Hi, > I have packed several R modules. R modules have a description file with a > license field. > Lots of those modules have as license: GPL version 2 or later. > > Should this be placed in the spec file as GPL IMO: This. > or allow the fully license as > described in the DESCRIPTION file? Do you mean the %description tag? I am opposed to this. "License: GPL" should be considered enough to provide an informative overview over a package's licensing. > While searching for tags used in the License field for Extras I got this > result: > 1 GPL version 2 or newer > 1 GPL version 2 or later. > 1 GPL version 2 or later > 1 GPLv2 IMO, all these above are superfluous and should be changed into "GPL", because current "GPL" always implies "GPLv2 or later/newer". Ralf From jamatos at fc.up.pt Tue Mar 7 12:02:48 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Tue, 7 Mar 2006 12:02:48 +0000 Subject: [Fedora-packaging] License landscape (and question of best pratice) In-Reply-To: <1141732145.5228.195.camel@mccallum.corsepiu.local> References: <200603071112.17010.jamatos@fc.up.pt> <1141732145.5228.195.camel@mccallum.corsepiu.local> Message-ID: <200603071202.48376.jamatos@fc.up.pt> On Tuesday 07 March 2006 11:49, Ralf Corsepius wrote: > > ?or allow the fully license as > > described in the DESCRIPTION file? > > Do you mean the %description tag? I am opposed to this. Nope. DESCRIPTION is the the counterpart of the spec file in R modules, where all the information that R uses to build the module is placed. So the setence above should be read as: ... or allow the full license as described by author in the R module. -- Jos? Ab?lio From tcallawa at redhat.com Tue Mar 7 14:46:21 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 07 Mar 2006 08:46:21 -0600 Subject: [Fedora-packaging] License landscape (and question of best pratice) In-Reply-To: <200603071202.48376.jamatos@fc.up.pt> References: <200603071112.17010.jamatos@fc.up.pt> <1141732145.5228.195.camel@mccallum.corsepiu.local> <200603071202.48376.jamatos@fc.up.pt> Message-ID: <1141742781.8902.114.camel@localhost.localdomain> On Tue, 2006-03-07 at 12:02 +0000, Jose' Matos wrote: > On Tuesday 07 March 2006 11:49, Ralf Corsepius wrote: > > > or allow the fully license as > > > described in the DESCRIPTION file? > > > > Do you mean the %description tag? I am opposed to this. > > Nope. DESCRIPTION is the the counterpart of the spec file in R modules, > where all the information that R uses to build the module is placed. > > So the setence above should be read as: > > ... or allow the full license as described by author in the R module. I'd say, include DESCRIPTION as %doc, and keep License: as simple as possible. ~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 jamatos at fc.up.pt Tue Mar 7 15:26:44 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Tue, 7 Mar 2006 15:26:44 +0000 Subject: [Fedora-packaging] License landscape (and question of best pratice) In-Reply-To: <1141742781.8902.114.camel@localhost.localdomain> References: <200603071112.17010.jamatos@fc.up.pt> <200603071202.48376.jamatos@fc.up.pt> <1141742781.8902.114.camel@localhost.localdomain> Message-ID: <200603071526.44768.jamatos@fc.up.pt> On Tuesday 07 March 2006 14:46, Tom 'spot' Callaway wrote: > I'd say, include DESCRIPTION as %doc, and keep License: as simple as > possible. But then we are duplicating that file, since R BUILD command also installs it. On the other hand that is a very _descriptive_ file. ;-) I noticed before that you do the same in your R packages. So we could adopt this as the standard practice for R packages. Does this looks like a deal? ;) Thank your for the input. :-) > ~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! -- Jos? Ab?lio From tcallawa at redhat.com Tue Mar 7 15:40:50 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 07 Mar 2006 09:40:50 -0600 Subject: [Fedora-packaging] License landscape (and question of best pratice) In-Reply-To: <200603071526.44768.jamatos@fc.up.pt> References: <200603071112.17010.jamatos@fc.up.pt> <200603071202.48376.jamatos@fc.up.pt> <1141742781.8902.114.camel@localhost.localdomain> <200603071526.44768.jamatos@fc.up.pt> Message-ID: <1141746050.8902.117.camel@localhost.localdomain> On Tue, 2006-03-07 at 15:26 +0000, Jose' Matos wrote: > On Tuesday 07 March 2006 14:46, Tom 'spot' Callaway wrote: > > I'd say, include DESCRIPTION as %doc, and keep License: as simple as > > possible. > > But then we are duplicating that file, since R BUILD command also installs > it. > > On the other hand that is a very _descriptive_ file. ;-) > > I noticed before that you do the same in your R packages. So we could adopt > this as the standard practice for R packages. Does this looks like a deal? ;) Sounds like a good idea. :) ~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 fedora at iagorubio.com Wed Mar 8 10:09:56 2006 From: fedora at iagorubio.com (Iago Rubio) Date: Wed, 08 Mar 2006 11:09:56 +0100 Subject: [Fedora-packaging] License landscape (and question of best pratice) In-Reply-To: <1141732145.5228.195.camel@mccallum.corsepiu.local> References: <200603071112.17010.jamatos@fc.up.pt> <1141732145.5228.195.camel@mccallum.corsepiu.local> Message-ID: <1141812598.28019.27.camel@speedy.iagorubio.net> On Tue, 2006-03-07 at 12:49 +0100, Ralf Corsepius wrote: > On Tue, 2006-03-07 at 11:12 +0000, Jose' Matos wrote: > > While searching for tags used in the License field for Extras I got this > > result: > > > 1 GPL version 2 or newer > > 1 GPL version 2 or later. > > 1 GPL version 2 or later > > 1 GPLv2 > IMO, all these above are superfluous and should be changed into "GPL", > because current "GPL" always implies "GPLv2 or later/newer". Not all authors agree with this. [quote from="http://lkml.org/lkml/2006/1/25/273"] The Linux kernel has always been under the GPL v2. Nothing else has ever been valid. The "version 2 of the License, or (at your option) any later version" language in the GPL copying file is not - and has never been - part of the actual License itself. It's part of the _explanatory_ text that talks about how to apply the license to your program, and it says that _if_ you want to accept any later versions of the GPL, you can state so in your source code. [/quote] So at least the GPLv2 one - being it the Linux kernel - should remain GPLv2. -- Iago Rubio From rc040203 at freenet.de Wed Mar 8 16:24:47 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 08 Mar 2006 17:24:47 +0100 Subject: [Fedora-packaging] License landscape (and question of best pratice) In-Reply-To: <1141812598.28019.27.camel@speedy.iagorubio.net> References: <200603071112.17010.jamatos@fc.up.pt> <1141732145.5228.195.camel@mccallum.corsepiu.local> <1141812598.28019.27.camel@speedy.iagorubio.net> Message-ID: <1141835087.15614.13.camel@mccallum.corsepiu.local> On Wed, 2006-03-08 at 11:09 +0100, Iago Rubio wrote: > On Tue, 2006-03-07 at 12:49 +0100, Ralf Corsepius wrote: > > On Tue, 2006-03-07 at 11:12 +0000, Jose' Matos wrote: > > > While searching for tags used in the License field for Extras I got this > > > result: > > > > > 1 GPL version 2 or newer > > > 1 GPL version 2 or later. > > > 1 GPL version 2 or later > > > 1 GPLv2 > > IMO, all these above are superfluous and should be changed into "GPL", > > because current "GPL" always implies "GPLv2 or later/newer". > > Not all authors agree with this. > > [quote from="http://lkml.org/lkml/2006/1/25/273"] Not quite. The GPL and must not be modified: GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Note the last sentence. I.e. any package claiming to be GPL'ed must be licensed with "this GPL" (rsp. predecessors or successors) or it doesn't qualify as GPLed. > The Linux kernel has always been under the GPL v2. Nothing else has > ever been valid. > > The "version 2 of the License, or (at your option) any later version" > language in the GPL copying file is not - and has never been - part of the > actual License itself. It's part of the _explanatory_ text that talks > about how to apply the license to your program, and it says that _if_ you > want to accept any later versions of the GPL, you can state so in your > source code. > > [/quote] > > > So at least the GPLv2 one - being it the Linux kernel - should remain > GPLv2. I don't understand what you want to say here. Are you trying to say, that we should emphasize there different versions of the GPL in an rpm's "license:" tag? I don't see much sense in this, because 1. An rpm's "license:" tag is informative, and by no means can be considered legally binding. The legally binding text is that contained in the detached license text and that contained in individual source files. 2. At present, practically all "GPL'ed" packages are "GPLv2", because GPLv1 is dead for 15 years and GPLv3 has not been released yet. I.e. as I see it, a license:-tag "GPL" is identical to "GPLv2". Ralf From fedora at iagorubio.com Thu Mar 9 17:16:39 2006 From: fedora at iagorubio.com (Iago Rubio) Date: Thu, 09 Mar 2006 18:16:39 +0100 Subject: [Fedora-packaging] License landscape (and question of best pratice) In-Reply-To: <1141835087.15614.13.camel@mccallum.corsepiu.local> References: <200603071112.17010.jamatos@fc.up.pt> <1141732145.5228.195.camel@mccallum.corsepiu.local> <1141812598.28019.27.camel@speedy.iagorubio.net> <1141835087.15614.13.camel@mccallum.corsepiu.local> Message-ID: <1141924599.4354.84.camel@speedy.iagorubio.net> On Wed, 2006-03-08 at 17:24 +0100, Ralf Corsepius wrote: > On Wed, 2006-03-08 at 11:09 +0100, Iago Rubio wrote: > > On Tue, 2006-03-07 at 12:49 +0100, Ralf Corsepius wrote: > > > On Tue, 2006-03-07 at 11:12 +0000, Jose' Matos wrote: > > > > While searching for tags used in the License field for Extras I got this > > > > result: > > > > > > > 1 GPL version 2 or newer > > > > 1 GPL version 2 or later. > > > > 1 GPL version 2 or later > > > > 1 GPLv2 > > > IMO, all these above are superfluous and should be changed into "GPL", > > > because current "GPL" always implies "GPLv2 or later/newer". > > > > Not all authors agree with this. > > > > [quote from="http://lkml.org/lkml/2006/1/25/273"] > > Not quite. > > The GPL and must not be modified: I don't see your point here. This does not means that GPL "always implies GPLv2 or later/newer". If you think that the GPL license makes mandatory the use of the "any later version" clause - unless modified - then you're wrong. Just read point nine(*) on the GPL. > > GNU GENERAL PUBLIC LICENSE > Version 2, June 1991 > > Copyright (C) 1989, 1991 Free Software Foundation, Inc. > 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > > Note the last sentence. > > I.e. any package claiming to be GPL'ed must be licensed with "this > GPL" (rsp. predecessors or successors) or it doesn't qualify as GPLed. Unfortunately I don't know what you mean with "rsp." here. What's clear is most packages are licensed with this GPL and "any later version", some are licensed with a specific version of the GPL. If the GPL tag always implies GPLv2 or later/newer - as you said - then it should exist a different tag to identify packages that don't allow newer or/nor later versions. > > The Linux kernel has always been under the GPL v2. Nothing else has > > ever been valid. > > > > The "version 2 of the License, or (at your option) any later version" > > language in the GPL copying file is not - and has never been - part of the > > actual License itself. It's part of the _explanatory_ text that talks > > about how to apply the license to your program, and it says that _if_ you > > want to accept any later versions of the GPL, you can state so in your > > source code. > > > > [/quote] > > > > > > So at least the GPLv2 one - being it the Linux kernel - should remain > > GPLv2. > > I don't understand what you want to say here. > > Are you trying to say, that we should emphasize there different versions > of the GPL in an rpm's "license:" tag? No I'm not. I've never said that. I'm just trying to say that GPL does not automatically implies newer versions, so I see no gain on limiting packages released with specific versions of the license, to the "GPL" tag. To be more clear: I don't think there's a gain on changing the kernel's license tag from GPLv2 - or "GPL version 2" - to "GPL", when it's known that this package is release *only* under version 2 of the GPL license. > I don't see much sense in this, because > > 1. An rpm's "license:" tag is informative, and by no means can be > considered legally binding. The legally binding text is that contained > in the detached license text and that contained in individual source > files. Even while it's true - changing the license tag won't change the package's license - you can be liable for errors caused by a bogus license tag, so it has its legal caveats as well. As example: someone distributing a GPLed rpm package under BSD is sued, but he proves on court that the package when queried identifies itself as BSD licensed. For sure the judge will want to speak with the packager > 2. At present, practically all "GPL'ed" packages are "GPLv2", because > GPLv1 is dead for 15 years and GPLv3 has not been released yet. As I said, most GPL packages are "version 2 and any later", others are "only version 2". It does not means the same now, and won't mean the same when GPL version 3 get released. > I.e. as I see it, a license:-tag "GPL" is identical to "GPLv2". I think GPL means "GPL v2 or any later/newer" or "any GPL" - and you seemed to agree with this some lines above - and GPLv2 means "only version 2 of the GPL license". May be the wording is not right and it should read "GPL version 2" for clarity. Said that, I think this discussion is moot. The license tag should be something to study in a package per package basis, and in the case of the package tagged as "GPLv2", it will be less informative to change this tag to "GPL" than let it unchanged. ------- (*) At http://www.gnu.org/copyleft/gpl.html point nine it's stated: "Each version is given a distinguishing version number." And then two special cases: 1) If the package states the version which applies to it and "any later version" - quoted in the original - you can use the current or any newer version of the GPL. 2) If the package states no version, you can use any version. So not all GPL packages *must* be released with the "any later version" clause, it just states they *can* be released with this clause. The only other reference to the "any later version" clause on the license terms, is in the example on "How to Apply These Terms to Your New Programs", which is written below the "END OF TERMS AND CONDITIONS". So reading the GPL it's clear that: 1) You can specify a version of the GPL on your program. 2) You can specify no version, so any version of the GPL could be applied. 3) You can specify a version number, with the phrase "and any later version" if you want to give the freedom to license your program with any later version of the GPL. -- Iago Rubio From rdieter at math.unl.edu Fri Mar 24 13:02:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 24 Mar 2006 07:02:36 -0600 Subject: [Fedora-packaging] core dev's have a ways to go Message-ID: Just some frustration venting mostly, but Core dev's have a ways to go before "their" packages will ever come close to Extras quality, especially when they ignore good/valid suggestions and the very helpful stuff on http://fedoraproject.org/wiki/Packaging/Guidelines Case in point: openobex: http://bugzilla.redhat.com/bugzilla/186457 (*) marked INVALID rpm: http://bugzilla.redhat.com/bugzilla/145978 marked WONTFIX (rpm-devel's Requires: have been broken for a *very* long time) Nice, huh? Hopefully, the same won't happen to the other openobex packaging bugs/suggestions I reported yesterday: http://bugzilla.redhat.com/bugzilla/186458 http://bugzilla.redhat.com/bugzilla/186460 http://bugzilla.redhat.com/bugzilla/186463 (*) OK, I feel better now. (*) which can cause kdebluetooth (see bug #186452) to fail to build (especially outside of mock) on fc5. -- Rex From jkeating at j2solutions.net Fri Mar 24 22:58:05 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 24 Mar 2006 14:58:05 -0800 Subject: [Fedora-packaging] core dev's have a ways to go In-Reply-To: References: Message-ID: <1143241086.23491.126.camel@yoda.loki.me> On Fri, 2006-03-24 at 07:02 -0600, Rex Dieter wrote: > Just some frustration venting mostly, but Core dev's have a ways to go > before "their" packages will ever come close to Extras quality, > especially when they ignore good/valid suggestions and the very helpful > stuff on http://fedoraproject.org/wiki/Packaging/Guidelines So we're moving to something internally that is built around mock, which should have a huge hand in cleaning up a lot of bad packages, wrt BuildReqs and such. We're also talking about pushing forward w/ a packaging guideline that models (or IS) the Extras guidelines. We're working to improve this situation. -- 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: 191 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Mon Mar 27 18:46:06 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 27 Mar 2006 11:46:06 -0700 Subject: [Fedora-packaging] Please help with vim/emacs files Message-ID: <442832EE.9020903@cora.nwra.com> I'm packaging cmake and I'd like to ship the emacs .el file and vim .vim files. Currently, I have: %package emacs Summary: Emacs support for cmake Group: Development/Tools Requires: %{name} = %{version}-%{release} Requires: %{_datadir}/emacs/site-lisp %description emacs %{summary}. %package vim Summary: Vim support for cmake Group: Development/Tools Requires: %{name} = %{version}-%{release} Requires: %{_datadir}/vim/vim64/syntax, %{_datadir}/vim/vim64/indent %description vim %{summary}. %files emacs %defattr(-,root,root,-) %{_datadir}/emacs/site-lisp/cmake-mode.el %files vim %defattr(-,root,root,-) %{_datadir}/vim/vim64/syntax/cmake.vim %{_datadir}/vim/vim64/indent/cmake.vim Which I believe is the pedantically correct way to do it, but cumbersome as folks need to know to install the -emacs or -vim package as desired. I do want to avoid requiring emacs and vim in the main package though. Some suggestions have been: - Another simplistic approach is to 1. install the files to /usr/share/emacs/site-lisp 2. include these in the main pkg (ie, no subpkg) 3. Add no additional/special Requires wrt emacs. It's simple and it works (when emacs is installed, or any other package that "owns" /usr/share/emacs/site-lisp). At worst, when emacs is not installed, you have files installed into an unowned dir. IMO, the benefits of this approach (mostly it's simplicity) outweigh the disadvantage of installing files into a potentially unowned dir (site-lisp). - Another possibility is to own "/usr/share/emacs". Several other packages do this. The second is discouraged in the Fedora Extras Packaging Guidelines except for a "good reason". I like the first, but don't know what the issues with unowned directories are. The packaging guidelines don't seem to address this directly. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com