packaging January 2010

packaging@lists.fedoraproject.org

36 participants
19 discussions

Suggested updated Java guidelines
by Alexander Boström 16 Mar '10

16 Mar '10

Hi, I submitted a review for java-gnome and working on that made me think the Java guidelines needs work, so here's a suggested update: https://fedoraproject.org/wiki/User:Abo/JavaPackagingDraftUpdate === Changes === Removed some occurances of a Unicode control character that didn't seem to belong there. Fixed formatting of the text under "Jar file naming". Hopefully clarified the text under "Directory structure". Changed some occuranced of "<code>%{_xxx</code>}" into "<code>%{_xxx}</code>". Changed -javadoc Group tag from "Development Documentation" to "Documentation". Mostly rewrote the section on JNI packaging. (See wiki.) Removed this text: The <code>%{_jnidir</code>} rpm macro defines the main JNI jar repository. Like <code>%{_javadir</code>} it is declined in <code>-ext</code> and <code>-x.y.z</code> variants. It follows exactly the same rules as the <code>%{_javadir</code>}-derived tree structure, except that it hosts JAR files that use JNI. <code>%{_jnidir</code>} usually expands into <code>/usr/lib/java</code>. It seems to belong to the "The plan is to eventually..." part, but I don't really understand it. Explain and I'll add something back. :) Partially rewrote the section on prebuilt binaries and the suggested % prep section. (See wiki.) /abo

3 3

Broken URL in section on %global versus %define
by Todd Zullinger 31 Jan '10

31 Jan '10

Hi, I was pointing someone at the guidelines on %global versus %define and noticed that the URL to the bugfix description was incorrect. It seems to have picked up a trailing '|' character. (I blame wiki syntax. ;) The correct URL should be: https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I used to think the brain was the most advanced part of the body. Then I realized, look what's telling me that. -- Emo Phillips

2 1

RPM Group vs. Sugar
by Susi Lehtola 31 Jan '10

31 Jan '10

Hi, the Sugar activity guidelines http://fedoraproject.org/wiki/Packaging:SugarActivityGuidelines#Sample_SPEC instruct using Sugar/Activities as the RPM Group. Is using non-standard RPM groups in Fedora really allowed? The Creating Package HOWTO suggests that it is not, although AFAIK no guideline actually states anything about it. Of course, RPM groups are not very meaningful anymore as comps are used... -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

2 1

Placement of %doc
by Remi Collet 30 Jan '10

30 Jan '10

Hi, I'm searching info about %doc placement. Most of %doc files (from source tree) goes under /usr/share/doc/<package_name>-<version> For the pear package, the installer copy doc files to %{pear_docdir} = /usr/share/pear/doc/<extension_name> So two solutions 1/ It's ok to keep this file here and use %doc %{pear_docdir}/foo 2/ It's not ok, we MUST move them to /usr/share/doc ? Actually, most pear package apply 2 I'm asking this because a new package under review apply 1 https://bugzilla.redhat.com/show_bug.cgi?id=551724 And an (old) bug is open against php-pear https://bugzilla.redhat.com/show_bug.cgi?id=468255 But I don't find any usefull information in Guidelines. Regards. P.S. please also note that, because of 2 being applied on most packages, the result of "pear list-files foo" is not correct

2 1

xpaint requires xpaint-devel
by Michael Schwendt 29 Jan '10

29 Jan '10

xpaint installation requires xpaint-devel and emacs http://bugzilla.redhat.com/542967 May I get assistance here, please?

1 0

Usage of /var/db
by Christian Krause 28 Jan '10

28 Jan '10

Hello, During a review the following question came up: Would it be OK if a package creates /var/db/<pkgname> for various kind of reasons (in this case a daemon would serve audio files the user puts there)? In Fedora only the nscd uses this directory: /var/db/Makefile /var/db/nscd/* The FHS doesn't contain any specific guidelines about the usage of /var/db/ and a quick web search revealed that on a couple of systems some daemons use /var/db like this /var/db/mysql /var/db/openldap etc. 1. Would it be acceptable in Fedora as well that a package creates /var/db/<pkgname> ? 2. Would it make sense in this specific case, where a streaming server would serve the audio files from this directory (per default)? Personally I think that a collection of audio files should not be considered a database and so it shouldn't be there. Since usually the user has his audio collection in his home directory, I would just configure the daemon that way, that the user has to specifically configure the directory where the files reside the server should stream... Thanks & Best regards, Christian

3 3

Writeup of approved packaging guidelines
by Susi Lehtola 26 Jan '10

26 Jan '10

Hi, is there anything I can do to help the writeup of "my" guidelines for 5 months? For instance, new MPI packages are turning up with the packagers being blissfully unaware that policies exist for these sort of things. -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

2 1

Item for FPC consideration - changelogs
by Jon Stanley 25 Jan '10

25 Jan '10

I consider this to be common sense, but it's not in the guidelines right now - that changelog entries are immutable. To that end, I have a really simple draft up here for revision of the guidelines to explicitly state that. https://fedoraproject.org/wiki/User:Jstanley/Changelog_Draft

6 8

Packaging Gnac (An audio converter for GNOME)
by Taylon 24 Jan '10

24 Jan '10

Hello guys, I'm packaging Gnac, it's my first package and I have the following doubt: Gnac is an audio converter, it can convert a lot of audio files and some of these types aren't directly supported by Fedora. On the .desktop file, it register some of these non supported types. Michael Schwendt (he did the package review), find better if an application didn't register for MIME types it doesn't support, but some other applications like audio players does that. What I should to do in this case? The bugzilla link is: https://bugzilla.redhat.com/show_bug.cgi?id=555018 Blog - http://www.focolive.org

5 8

Short intro
by Maxim Burgerhout 23 Jan '10

23 Jan '10

Hi, My name is Maxim Burgerhout and I'd like to start contributing to Fedora development by maintaining a couple of packages. I work as a sysadmin / Linux consultant for my daytime job. Over the last couple of years, I have mainly worked with Red Hat boxes. During several training sessions I had at Red Hat over the past few years, I learned to create RPM's (amongst other things, of course) and I maintain a good number of them for internal use. Those are admittedly not build by the Fedora Guidelines, but I did my best to follow them correctly. I have created a couple of review requests already (linked below). I have packaged a couple of programs to get Yubikey support into Fedora. Yubikeys are fairly low-tech hardware tokens that generate one-time passwords. There's a couple of programs in Fedora to deal with them already: pam_yubico and ykclient. I have packaged a library and a client tool to customize the AES key in the device. As I am (or hope to be) a new packager, I will need sponsorship. I'll be more than happy to answer any questions about myself or the packages if this is required. I apologize if it is not customary to send introductions to these lists. My two review requests are at: 1. https://bugzilla.redhat.com/show_bug.cgi?id=557776 2. https://bugzilla.redhat.com/show_bug.cgi?id=557794 Kind regards, Maxim Burgerhout maxim(a)wzzrd.com ---------------- GPG Fingerprint EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A

1 0

Help needed handling package move
by Orion Poplawski 21 Jan '10

21 Jan '10

I package the eclipse-photran feature. Currently this is at version 5.0.0. The Photran project has merged with the PTP project which I currently am in the process of packaging. I'm still splitting out the photran compenents with the package names "eclipse-photran*" , but because PTP is at version 3.0.1, their versions are now lower. The photran component is still considered to be at 5.0.0 (or 5.0.1). Any suggestions on how to handle this would be appreciated. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

4 5

Emphasize correct hostname for SF.net URLs
by Till Maas 21 Jan '10

21 Jan '10

Hiyas, according toseveral messages about the source URL check in fedora-devel, people used to think that the correct hostname for Source0 from Sourceforge packages is download, but it is downloads. Therefore I propose to emphasize the correct hostname in the Source:URL guidelines by adding an admonition like this: https://fedoraproject.org/wiki/PackagingDrafts/SourceURL_sourceforge_downlo… Regards Till

6 9

Naming packages from apache.org
by Orion Poplawski 21 Jan '10

21 Jan '10

crossposting to java and packaging - Seems like we need an accepted standard for naming packages from apache.org, particularly commons.apache.org. We already have lots of "jakarta-commons-*" packages, but now "commons" is an ex-jakarta project and jakarta.apache.org/commons redirects to commons.apache.org. Same with jakarta taglibs (although that moved to tomcat). As of now, the only apache-* package I know of is apache-ivy, which I would have named simply "ivy". I've got a package request in for "commons-jexl"[1], but it has been suggested that it be named apache-commons-jexl. If it were named that I would want a Provides: commons-jexl much like most jakarta-commons-* packages, so it doesn't really clean up the namespace any (just adds to it in fact). commons-* is a lousy name though too, be very generic. So, I'm fine with either (although I think it's quite possible that "apache commons" could get renamed again), but at this juncture before a bunch more packages come in from apache commons, I think we should make a decision and stick with it. 1 - https://bugzilla.redhat.com/show_bug.cgi?id=531379 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

6 6

Let me introduce myself
by Morpheusv 20 Jan '10

20 Jan '10

Hello. Since early 2008 I have used Fedora as my personal system, since late 2008 came the concern to actively contribute to Fedora, and that's how I took my first step by becoming Fedora ambassador for my country. But the issue of collaborating in the development of free software, is something that has a couple of months of hanging around in my head. This is how the project started packing clamsmtp software, which is an SMTP filter that allows the antivirus scan for viruses with ClamAV. Since becoming a pre-packaged feel that Fedora is an excellent opportunity to contribute and expand my knowledge and experience. This is my first package, and I am looking to sponsor. See https: / / bugzilla.redhat.com / show_bug.cgi? Id = 555,059 Greatly appreciated your comments and suggestions. -- -- Andres Pascasio http://www.pascasio.org http://fedoraproject.org/wiki/User:Morpheusv

1 0

from atalk to netatalk
by HAT 19 Jan '10

19 Jan '10

Hi, Netatalk team is preparing netatalk 2.1beta now. We consult Fedora packagers. We will change initscript's name from "atalk" to "netatalk". from: /etc/rc.d/init.d/atalk to: /etc/rc.d/init.d/netatalk Do you have the objection in this? A keyword "atalk" is an abbreviation for "AppleTalk". AppleTalk will be disable by default in netatalk 2.1beta. A description has already been updated. Old: # description: This package enables Linux to talk to Macintosh # computers via the AppleTalk networking protocol and # provides printer, file sharing, and AppleTalk routing # services. New: # description: This package is an implementation of "AFP over TCP" # and provides printer, file sharing, and routing # services via legacy AppleTalk networking protocol. See also, http://marc.info/?l=netatalk-devel&m=126019960613004 -- HAT

1 0

Where should server state go?
by Bruno Wolff III 16 Jan '10

16 Jan '10

I am looking at adding a subpackage to colossus for a public facing game server that maintains some state in files. It isn't clear to me where this should go (other than being under /var). Packages don't seem to be consistent about this as far as I can see. Some possibilities might be: /var/colossus /var/lib/colossus /var/games/colossus /var/lib/games/colossus On a related note, is it Ok to keep a config file in /var so there are less places to go looking for information related to the server, or should that be kept in /etc?

2 1

Suggested specification to changelog guidelines
by Susi Lehtola 08 Jan '10

08 Jan '10

Hi, I'd like to suggest https://fedoraproject.org/wiki/PackagingDrafts/ChangelogStyles for discussion. Now some packages mix the styles, which IMHO is bad style. -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

4 6

Request for Guideline Clarification
by Rich Mattes 06 Jan '10

06 Jan '10

Hi all, I've been gathering bits and pieces of information regarding the packaging of shared libraries for a while now. As I understand it: - Normal .so libraries with versioned filenames go into the base package for a program when they exist - Unversioned .so libraries go into the -devel package -- If there are no versioned libraries for a program, should a versioned library be added or should the unversioned .so file be included in the base package? - Libraries which are used by other programs at runtime should be versioned, and in %{_libdir} -- Are there exceptions to this? When is it appropriate to leverage subdirectories and /etc/ld.so.conf.d/? - Libraries which are plugins to one specific program, and are dlopened by that program, do not need a versioned filename. They should go in their own subdierctory in %{_libdir} (e.g. /usr/lib/gstreamer-0.10) -- If packaged as seperate plugins, they should be in packages called packagename-plugins-pluginname, or something similar - All shared library filenames should begin with lib A lot of this isn't in the packaging guidelines, I think if these points could be clarified and included in the guidelines it would help to answer a lot of questions. Thanks, Rich

4 4

Clarification of Static Libraries packaging guidelines
by Michael Schwendt 05 Jan '10

05 Jan '10

$ yum list \*-static | wc -l 115 $ yum list \*-devel-static | wc -l 8 $ yum list \*-static | grep -v devel | wc -l 108 Perhaps I only have a nit-picky day, but https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Librar… clearly mentions *-static as in foo-static - and not foo-devel-static. Could this part of the guidelines be clarified, please? Related to this ambiguity in the naming guidelines, it's kind of pointless if some packages start creating -static subpackages, which provide a virtual -devel *and* a virtual -devel-static package in addition to a shared library base package. Effectively, it implies that another package could "BuildRequires: libfoo-devel" for _static_ linking even if a shared library is available. This is exactly what the old guidelines wanted to avoid (by separating -devel and -static subpackages).

4 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2010