packaging January 2010

packaging@lists.fedoraproject.org

36 participants
19 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2010