desktop file validation
by Christopher Aillon
I got recently called out for using desktop-file-validate instead of
desktop-file-install when the upstream .desktop file is correct, doesn't
need to be changed, and make install already places it in the correct
location.
Since the purpose of this guideline is to validate, I propose to amend
the section of the packaging guidelines on desktop-file-install usage[1]
as follows:
* Rename the sub-heading from "desktop-file-install" to ".desktop file
installation and validation"
* Change the first sentence to:
<<
It is not simply enough to just include the .desktop file in the
package, one MUST run desktop-file-install OR desktop-file-validate in
%install (and have BuildRequires: desktop-file-utils), to help ensure
.desktop file safety and spec-compliance. desktop-file-install MUST be
used if the package does not install the file or there are changes
desired to the .desktop file (such as add/removing categories, etc).
desktop-file-validate MAY be used instead if the .desktop file's
content/location does not need modification. Here are some examples of
usage:
>>
* Add the following example:
<<
desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
>>
Thoughts?
[1]
http://fedoraproject.org/wiki/Packaging/Guidelines#head-d559ee7363418a584...
15 years, 1 month
Copyrighted specfiles.
by Jason L Tibbitts III
I have a specfile that begins with:
# Copyright 2006-2008 Double Precision, Inc.
# See COPYING for distribution information.
It looks like the specfile is carried in the tarball and the
maintainer just copies it out for the Fedora package. But this means
that when you unpack the srpm, you get a spec that refers to a file
which does not exist.
Is it too much to ask that if for some reason you're going to
copyright the specfile you at least indicate the license in the
specfile?
- J<
15 years, 1 month
Etiquette for contacting a package maintainer?
by Timothy Selivanow
What is the proper etiquette for contacting a current package
maintainer? I'm working on a package that uses a current package as a
dependency, and I have some questions that need to be asked...
--Tim
___________________________________________________________
/ Not only is UNIX dead, it's starting to smell really bad. \
\ -- Rob Pike /
-----------------------------------------------------------
\
\ \
\ /\
( )
.( o ).
15 years, 1 month
New Fedora Packaging Committee Members
by Tom Callaway
The Fedora Packaging Committee is proud to announce its newest members:
Xavier Lamien and Denis Leroy
We would also like to thank Ville Skyttä, who is retiring from the
committee.
~spot
15 years, 1 month
Packaging/SysVInitScript reload() bug
by Ville Skyttä
The init script template in Packaging/SysVInitScript makes the reload action
invoke restart if the service is running. This is a bug wrt. LSB, there the
reload action is specified as:
"cause the configuration of the service to be reloaded without actually
stopping and restarting the service"
I'd suggest changing the default reload() in the template to something like
(this is how it is in the current rpmdevtools init script template):
reload() {
# If config can be reloaded without restarting, implement it here,
# remove the "exit", and add "reload" to the usage message below.
action $"Service $prog does not support the reload action: " /bin/false
exit 3
}
...and removing "reload" from the default usage message.
15 years, 1 month
32- and 64-bit softwares living together
by Sérgio Durigan Júnior
Hello folks,
I would like to know if there are any efforts to make both 32- and
64-bit versions of the same package "live" together in a system. I've
been finding some packages that unfortunately break when you install
both versions from the RPM (one example is Perl). Basically, what
usually happens is:
- The executable files for both 32- and 64-bit versions have the same
names (e.g., "perl", "python")
- The libraries for both versions are installed under /usr/lib
- Some other arch-dependent (therefore, bitness-dependent) files are
installed at the same place for both versions
Those 3 situations make the last installed version to override things
from the previous one.
So, do you intend to solve this problem in future versions of Fedora?
Thanks in advance,
--
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil
15 years, 1 month
Lua
by Jason L Tibbitts III
I see a few Lua packages have appeared in the review queue today.
I checked out the specs and they all seem very clean. There are a few
issues (/usr/lib/lua seems to be unowned in rawhide, although
/usr/lib/lua/5.1 is owned by the lua package), the luasql packages
leave /usr/lib/lua/5.1/luasql unowned, etc.) but these seem to be
minor packaging issues.
So, we need to decide whether we want to just go ahead with these
packages, or whether we want to do the "wait for guidelines" game
again. Is anyone interesting in writing some guidleines? It seems
like they'd be pretty tiny. Hans, the main Lua package seems to be
yours; are you interested in putting something together?
- J<
15 years, 1 month
GCJ Clarification (was Re: More Java guidelines questions)
by Toshio Kuratomi
Andrew Haley wrote:
> Toshio Kuratomi wrote:
>> Andrew Haley wrote:
>>> Amazing -- I never even imagined that such a thing as an annotation-only
>>> package might exist! The guidelines are intended to allow reasonable
>>> people to interpret them sensibly. In this case, AOT-compiling wouldn't
>>> hurt but wouldn't be of much benefit, so I don't think it matters.
>>>
>> Andrew, if you could propose some wording changes to the Guidelines for
>> this it would be most appreciated.
>
> OK.
>
> "In some rare cases Java packages might not contain any executable code
> whatsoever, so AOT-compiling for gcj would not be required. An example
> of such a package would be one that contained only annotations."
>
This seems like a clarification rather than a change. If this breaks
anyone's expectations and they wants to vote on it speak now and we can
take this up at the FPC Meeting otherwise I'll just add it to the top of:
http://fedoraproject.org/wiki/Packaging/GCJGuidelines
-Toshio
15 years, 1 month
