packaging August 2007

packaging@lists.fedoraproject.org

32 participants
30 discussions

Wiki is inconsistent on Mono file locations
by Mary Ellen Foster 27 Aug '07

27 Aug '07

Disclaimer: I'm not a Mono programmer; I'm just trying to package something that includes some Mono pieces. I was looking at the Wiki about packaging for Mono (http://fedoraproject.org/wiki/Packaging/Mono), and it seems to contradict itself. Under "File locations", it says Mono packages should install assemblies to %{_libdir} rather than /usr/lib or %{_datadir} Then, right below, it gives sample gacutil lines that install into %{_prefix}/lib, with a note that it might later change to %{_libdir} and a link to a bug with a lot of discussion, but no clear indication of whether the proposal was accepted or not. So, should my stuff go into %{_libdir} or %{_prefix}/lib? Thanks very much! MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/

2 2

commands under privileged users' path
by Mamoru Tasaka 24 Aug '07

24 Aug '07

Well, currently I am reviewing several reviewing requests and I asked a submitter to change user/group registration scriptlets according to http://fedoraproject.org/wiki/Packaging/UsersAndGroups and he/she changed as such. Then I noticed : %pre servers # Following the Wiki instructions ... getent group iceuser > /dev/null || groupadd -r iceuser <snip> Here "groupadd" (which is in Fedora under /usr/sbin) is used by only basename, not by full path. IMO this will cause a problem when "yum update" or "rpm -ivh" is done by normal users using "su -c" or "sudo" because normal users usually don't have /usr/sbin in their path. So I think that the following should be added to the wiki that commands which are under privileged users' path and not under normal users' path must be written with full path. Do you have any suggestions? Regards, Mamoru

2 2

Re: [Fedora-packaging] review guidelines vs packaging guidelines
by Nicolas Mailhot 23 Aug '07

23 Aug '07

Le Jeu 23 août 2007 12:58, Patrice Dumas a écrit : > Ok, I didn't understood it that way. But it isn't true, the guidelines > are setup such that having no ownership of a directory is impossible. I'm not so sure. The lax guidelines are more ambiguous, at no time do they clearly say "every directory must be owned" (with single or multiple owners). They say "the rule of thumb is everything must be owned but there are exceptions". And then proceed with some examples where every directory is accounted for without explicitely stating this is a hard rule. I don't think the OP would have been so happy with the lax version if he had understood them to enforce this rule. IMHO since the documented "exceptions" are clearly targetted at perl modules, it would be better to create a perl-filesystem package and forget about all the complex A/B convolutions in the guidelines. But that's for the perl SIG to discuss. -- Nicolas Mailhot

4 5

why not %{_datadir} on fonts scripletsnippet
by Jens-Ulrik Petersen 23 Aug '07

23 Aug '07

Hi, http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93ce… The "Fonts" scriptlets currently have: %{_bindir}/fc-cache /usr/share/fonts is there some subtle reason for not using %{_datadir} here? I'll for responses before changing it to: %{_bindir}/fc-cache %{_datadir}/fonts Jens -- Jens Petersen Internationalization Team Red Hat

4 8

Re: [Fedora-packaging] review guidelines vs packaging guidelines
by Nicolas Mailhot 23 Aug '07

23 Aug '07

Le Jeu 23 août 2007 11:52, Patrice Dumas a écrit : > It is not always worth creating a filesystem package for these cases. > Simply having more than one package own the directory is simpler, and > although not perfect, acceptable. When two packages share a directory sure it's not worth creating a separate package just for this directory. What I was suggesting was more like the games SIG collecting all the stray directories in a filesystem-games package, same for the perl SIG, etc Certainly there is a level at which you can create useful filesystem packages without falling in the whole-repository or single-directory package traps. That being said multiple ownership is compliant with the strict guidelines version, what I object to is no ownership as suggested by the lax variant. Regards, -- Nicolas Mailhot

2 1

review guidelines vs packaging guidelines
by Matthias Clasen 23 Aug '07

23 Aug '07

The review guidelines have this: - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that those directories exist. The packaging guidelines say: The rule of thumb is that your package should own all of the directories it creates except those owned by packages which your package depends on. However, there are exceptions to this. If the directory hierarchy your package is located in may change due to updates of packages you depend on, then you need to take care to own those pieces of the hierarchy. [...] Another exception for directory ownership in packages is when there is no clear dependency hierarchy. I think the shortened version in the review guidelines is misleading and causes us to err on the side of adding unwanted dependencies just for directory ownership reasons. Can we have it changed to mention the furhter exceptions that are discussed in the packaging guidelines ?

3 2

Are circular dependencies ok?
by Stepan Kasal 22 Aug '07

22 Aug '07

Hello, in perl, circular dependencies are heavily used. First, "perl" and "perl-libs" require each other; this is a usual solution of the multilib problem, rpm{,-libs} and python{,-libs} are doing the same. Let's put this aside. Second, package "perl-devel" requires packages: perl-CPAN perl-ExtUtils-Embed perl-ExtUtils-MakeMaker perl-Test-Harness perl-Test-Simple all these packages require perl-devel, most of them by a direct requirement, only perl-CPAN by requiring perl-ExtUtils-Embed. I believe this is correct: - the modules have to have separate rpm, to match the real situation: they use a separate versioning scheme, for example. - perl-devel has to require them; these modules are required by scripts packed in perl-devel But this seems to bring problems, see the comments in https://admin.fedoraproject.org/updates/testing/F7/perl-5.8.8-22.fc7 Is this just a bug in yum, or is there a problem on my side? Thanks, Stepan Kasal

5 12

Packaging guidelines for Emacsen add-on packages
by Jonathan Underwood 15 Aug '07

15 Aug '07

Dear Packaging Committee, I have placed a draft Guidelines document on the wiki for your consideration. This document covers the packaging of Emacs and XEmacs add-on packages, and provides two template spec files with the intention of lowering the inertial barrier to developing packages for (X)Emacs. The doc can be found here: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns And I have added it to the table here: http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo This document doesn't attempt to change guidelines in any way, but rather clarify the situation as presented in the Package Naming Guidelines, and codify them in the form of spec templates. Comments gladly received! Best wishes, Jonathan

7 49

Missing the meeting today
by Toshio Kuratomi 14 Aug '07

14 Aug '07

Sorry for the last minuteness of this, My sister's stuck at the airport so I'll be missing the meeting. -Toshio

1 0

Missing today's meeting
by Ralf Corsepius 14 Aug '07

14 Aug '07

Hi, due to sudden unplanned commitments, I'll not be able to attend today's FPC meeting. Ralf

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2007