packaging August 2009

packaging@lists.fedoraproject.org

42 participants
23 discussions

"Explicit requires" and "requiring base package"
by Ville Skyttä 09 Sep '09

09 Sep '09

https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires Packages must not contain explicit Requires on libraries except when absolutely necessary. [...] https://fedoraproject.org/wiki/Packaging/Guidelines#Requiring_Base_Package Devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}. Usually, subpackages other than -devel should also require the base package using a fully versioned dependency. I think these two guidelines or their wording are more or less in conflict these days. Most -devel packages do not "absolutely necessarily" need an explicit dependency on the base package because rpm automatically adds soname dependencies from symlinks in -devel to the corresponding shared lib in the main/lib package. Ditto, many cases of other non-devel subpackages get automatic lib soname dependencies to the main/lib package. If the intent is to still require explicit deps like in "requiring base package" even though there are automatic ones that would usually work, just to be sure or for other reasons (possibility of compilation options, patchwork that affects some internal subpackages but not other -devel/lib package consumers), I think "requiring base packages" and "explicit requires" should be cross referenced noting that this is an exception and those explicit deps are indeed wanted. If not, IMO "requiring base package" should be softened so that it requires adding those explicit deps if no automatic ones are present, or just removed because that'd be redundant with "explicit requires" and the rest of the general dependency guidelines.

2 5

Packaging a game, need help with setgid security
by Ryan Rix 04 Sep '09

04 Sep '09

Hello group, I have recently finished packaging the game IVAN (http://ivan.sf.net) for Fedora 11: Iter Vehemens ad Necum is a graphical roguelike game. It features advanced bodypart and material handling, multi-colored lighting and, above all, deep gameplay. Like many roguelikes, it has a shared high score file and Bones files that all users are meant to have their scores and final data written to. As a result, the game is forced to run setgid games so that it has the rights to write to /var/games/ivan/. While packaging this application, I got a lot of help from some of the Fedora-KDE guys (hi Kevin, Ben) and they both suggested I run this through Fedora Security SIG so that the game would properly demote itself to non-setgid when it doesn't need to. What is the proper channel to go about this? Should I just mail to the security list? Should I put this package up for review beforehand/in the meantime? Thanks and Best, Ryan Rix -- Ryan Rix (623)-826-0051 Fortune: I'm DESPONDENT ... I hope there's something DEEP-FRIED under this miniature DOMED STADIUM ... http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash XMPP: phrkonaleash(a)gmail.com | MSN: phrkonaleash(a)yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh(a)irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels.

3 8

F-11 to F-12 transition
by Federico Hernandez 01 Sep '09

01 Sep '09

Now this might really be a newbie question but since I haven't maintained a package that long yet I wonder how the transition now from F-11 to the future F-12 works. At what point can/must I check out a new CVS branch for F-12 of my package? Will it be created automatically and all the packages in rawhide will move by magic into F-12? Or do I need to request one via bugzilla? Just wondering as I have never been around for this transition. Greetings, /Federico

3 5

bringing back to life a package (drivel)
by Andrey A.Kolov 31 Aug '09

31 Aug '09

Hi, I would like to pick up a drivel (blog tool) package. It is in the list of Retired packages since July 2008, as upstream was frozen at that time. Now it seems alive, new version was released in April 2009. I have contacted Paul W.Frields (who has maintained drivel in Fedora) some time ago and he was keen to offer me maintaining this package. I have checked on koji (https://koji.fedoraproject.org/koji/taskinfo?taskID=1636387) and it seems that old source are good enough to work on F11. My idea is to bring old version to F11 now until I will finish accommodating new sources. However, if this approach is not in line with rules and policies I will be glad to follow your advises. In any case, I will need some coaching. Is it possible for someone to spend a little bit time with me on IRC (@fedora-devel, probably) to understand further steps and actions ? Thanking you in advance, Andrey

3 3

how to force rpmbuild to use local libraries?
by Krzesimir Nowak 28 Aug '09

28 Aug '09

Hi, I'm using Fedora 11, so all software in repository are stable ones, but I'm developing a library using unstable versions of them (e.g. I have now glibmm24 2.20, and I need it in version 2.21.3). I have those unstable versions installed in my home directory (that is `~/usr/') and I'm testing my library on them by using parallel environment provided by `jhbuild shell'. I decided to build a package with rpmbuild, but it uses `/usr/' path for everything (pkg-config files and such) even if I execute it from my parallel environment, so building the package ends quickly with message of unmet dependencies or in configure stage, when I pass `--nodeps' option. My question is: is there a way to force rpmbuild to use libraries in my home directory instead of those in `/usr/'? Thanks for your help, Krzem.

2 4

directory ownership in f-spot package
by Christian Krause 28 Aug '09

28 Aug '09

Hi, Trying to fulfill all requirements regarding the directory ownership described here http://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership has some implications for the f-spot package: Please consider the following: A package (here f-spot) provides a screensaver plugin for gnome-screensaver in /usr/libexec/gnome-screensaver/ . I see 3 possible solutions how to handle the directory ownership of /usr/libexec/gnome-screensaver (which is already owned by gnome-screensaver package): 1. The most trivial way would be to let f-spot depend on the gnome-screensaver, don't own /usr/libexec/gnome-screensaver and just put its executable there. The drawback is that it may not be wanted that the installation of a photo managing software requires the installation of a specific screensaver. 2. The f-spot package could make use of the exception and own /usr/libexec/gnome-screensaver/ as well. However, the functionality-wise f-spot's screensaver would still depend on gnome-screensaver. There would be also the minor problem that the package would claim to provide a functionality in various menus which would not be there if gnome-screensaver would not be installed. 3. I could move screensaver part of f-spot into a sub-package. Only the sub-package would then require gnome-screensaver. This would properly satisfy all packaging requirements, but the users who want this functionality must install the sub-package manually since they will loose this feature during the update from the complete package to the one which is split in two parts. >From a packaging point of view I tend to choose option 3 despite its drawbacks. Would this be a good way? Best regards, Christian

3 2

Strawman: standardize 8-space tab width
by Jason L Tibbitts III 28 Aug '09

28 Aug '09

After seeing an argument in a review over someone using a five-space tab width (?!), I submit the following for flameage: https://fedoraproject.org/wiki/PackagingDrafts/Tabs - J<

12 20

Compat packages: Any best practices, rules, guidelines?
by Ryan Lynch 28 Aug '09

28 Aug '09

I'm trying to re-package a piece of software for Fedora. The catch is that this software depends about 15-20 specific versions of external libraries that Fedora ships, but only in a newer version. In several cases, this conflict is a deal-breaker--i.e., other installed software relies on the official Fedora library package/version, so I can't just replace the official RPM outright with a site-specific version. I would like to stay as close as possible to Fedora's packaging best practices. Even if I don't submit the resulting packages to Fedora for review, it's important to get as close to the guidelines as possible. >From what I understand, the "right" way to package multiple parallel versions of one library is the 'compat-*' convention ( http://docs.fedoraproject.org/drafts/rpm-guide-en/ch18s02.html has an overview). I took a look at the specs and manifests for a couple of existing compat packages, and I think I understand the concept pretty well. I think I can adapt the existing spec files and follow the conventions. But I have a lot of questions, too, and I was hoping that anybody in the know could help me. * Is anything about the compat convention standardized, or a matter of policy? I saw that the FESCO discussed about the issue, a while back, but I feel like I may have missed something more recent. * I can understand why large numbers of compat packages are frowned upon, and 15+ compats to support one measly application seems excessive, even to me. Is this the kind of thing that would torpedo a package review, completely? Or is there room for discussion, given a commitment to improve the situation (i.e., update the application) in time? * What kinds of compat packages, and what specifically about them, are considered bad? I've noticed that some compats don't appear to be included in Fedora, like 'compat-python24'. It seems like a useful package, but I'm seeing it in RPM Fusion--why didn't it pass review? * In the future, what direction is Fedora taking the compat convention? What kinds of long-term issues should I worry about, if I want to get ahead of the curve? If anyone can point me to existing resources on the compat subject, I would appreciate the links, too. Ryan B. Lynch ryan.b.lynch(a)gmail.com

2 1

MPI and Fortran drafts
by Susi Lehtola 26 Aug '09

26 Aug '09

Hello again, I have updated the MPI draft at https://fedoraproject.org/wiki/PackagingDrafts/MPI to take into account the comments that araised in discussion on the list. As I have been dealing with quite a few Fortran packages I have realized that the current laissez-faire mentality may not be enough and a standard is needed for file placement. https://fedoraproject.org/wiki/PackagingDrafts/Fortran As before, comments are welcome. -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

4 14

Meeting minutes
by Pierre-Yves Chibon 21 Aug '09

21 Aug '09

Hello, I have been looking for the minutes of the last meetings of the packaging comittee but I couldn't find them on the wiki [1] or on the fedora-packaging or fedora-devel mailing list. Are they available somewhere ? Did I look in the wrong place ? Thanks in advance, Best regards, Pierre [1] http://fedoraproject.org/wiki/Packaging:Minutes

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2009