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.
I'm packaging cmake
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184467> 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
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
