packaging April 2008

packaging@lists.fedoraproject.org

29 participants
17 discussions

desktop file validation
by Christopher Aillon 05 May '08

05 May '08

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-d559ee7363418a5840c…

5 5

Copyrighted specfiles.
by Jason L Tibbitts III 29 Apr '08

29 Apr '08

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<

1 0

Etiquette for contacting a package maintainer?
by Timothy Selivanow 24 Apr '08

24 Apr '08

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 ).

6 12

FPC Members: Possible times
by Tom Callaway 22 Apr '08

22 Apr '08

FPC Members, Please go through this chart and mark the times which are preferred for you: http://fedoraproject.org/wiki/Packaging/NewMeetingTime If a time is good for you (and no other group is using it, add your username to that field, like this): spot++ ~spot

1 0

Static Library Policy Draft Changes
by Tom Callaway 22 Apr '08

22 Apr '08

As promised, here is my new proposed draft for handling static libs: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy I know that it won't make everyone happy (it doesn't just leave static bits in -devel), but we really do want to track who is building against static libraries. ~spot

11 30

New Fedora Packaging Committee Members
by Tom Callaway 22 Apr '08

22 Apr '08

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

1 0

Packaging/SysVInitScript reload() bug
by Ville Skyttä 18 Apr '08

18 Apr '08

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.

1 0

32- and 64-bit softwares living together
by Sérgio Durigan Júnior 17 Apr '08

17 Apr '08

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

4 6

Lua
by Jason L Tibbitts III 17 Apr '08

17 Apr '08

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<

6 9

GCJ Clarification (was Re: More Java guidelines questions)
by Toshio Kuratomi 16 Apr '08

16 Apr '08

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging April 2008