packaging September 2006

packaging@lists.fedoraproject.org

36 participants
29 discussions

Request to drop %(%{__id_u} -n) in preferred buildroot
by Axel Thimm 05 Jan '07

05 Jan '07

Hi, I think the `preferred buildroot' is not really making sense. The above has developed historically out of a misunderstanding in ancient buildroot times. When people were building as root and BuildRoots were defined as %{_tmppath}/%{name}-%{version}-root, some considered "root" to mean the uid of the builder. Later %release was added and some replaced root with `id -un`. Even later some realized that root was referring to the BuildRoot and in order to play safe added both. I'm using %{_tmppath}/%{name}-%{version}-%{release}-root in my packages and someone is now nitpicking on why not using the preferred BuildRoot as given in the guidelines. Instead of locally fighting a BuildRoot battle, I'd better get the guidelines fixed ;) Also consider what this really is about: Deambiguifying the BuildRoot per package makes sense as there may be several build processes sharing the same filesystem (either locally or through NFS), but deambiguifying the build user, too, means that we assume that the same EVR package will be possibly built on the same filesystem by different users? And even simultaneously? It makes more sense to include a conditional epoch or target/arch in the buildroot that the builder. In fact the best thing for a buildsystem is to override the buildroot adding a build-id to it anyway. -- Axel.Thimm at ATrpms.net

10 23

--vendor fedora, rationale/motivation?
by Rex Dieter 29 Nov '06

29 Nov '06

Per http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines: The vendor prefix (desktop-file-install --vendor=...) must be set to fedora". I don't understand the rationale/motivation behind requiring '--vendor fedora' I can, however, see that desktop-file-install's current implementation(*) of prepending %{vendor}- to the .desktop file name has some problems/issues: 1. .desktop filename now varies from upstream 2. --vendor may change when/if Extras bits are pulled into Core and/or RHEL. 3. *In particular*: when users start employing menu editors, since most(all?) of them base their customizations on the .desktop file name. -- Rex (*) If desktop-file-install's implementation instead followed something like kde's practice of using a vendor directory (e.g. /usr/share/applications/kde), then (1) and (3) would no longer be an issue.

4 6

libtool(.la) archive policy proposal
by Rex Dieter 15 Oct '06

15 Oct '06

See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives Comments? -- Rex

9 83

.so files in main package for python packages
by Christopher Stone 05 Oct '06

05 Oct '06

Upstream says there is a packaging error in one of my packages, pypoker-eval-devel. Upstream claims that the .so file should not be in the devel package but should be in the main package. I told upstream about our .so rule saying .so files should be in -devel, but he said this is not the case for python packages, and promptly demonstrated that the libxml2-python package is similar and that this package puts the .so files in the main pacakge on Fedora as well. So is libxml2-python package in error, or is upstream correct and there are exceptions to the .so rule for python packages? Upstream informs me that my package will break unless I put the .so file in the main package.

3 3

MS shared source license
by Paul F. Johnson 28 Sep '06

28 Sep '06

Hi, I've packaged IronPython and it's quite happy here. However, it looks like the license is the MS shared source one. Is it worth even submitting it for FE review? TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzulügen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; Lügner, Betrüger, Fixer und Wohltäter zu niemandem

4 4

Absent (Sep 28, 2006)
by Tom Callaway 27 Sep '06

27 Sep '06

Dear Teacher, Spot will not be able to attend tomorrows FESCO and Fedora Packaging Committee meetings because he has to go sell Linux to unsuspecting companies in Indianapolis. Please excuse him from his duties for the day. Thanks, ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954

1 0

desktop-file-install --vendor=... proposal, comments?
by Rex Dieter 26 Sep '06

26 Sep '06

See http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles Comments? -- Rex

3 6

Including a static library
by Matthias Saou 26 Sep '06

26 Sep '06

Hi, Regarding this bug : https://bugzilla.redhat.com/204568 It does makes sense to ship the DirectFB static libraries for some users. So here are my questions : - Should they be put into the existing -devel sub-package? - Should they be put into a new separate sub-package? (-static) I'm asking because since it's not really for "development", it would make sense to split it out in a new sub-package. Also, that way it would avoid any possible scenario where something rebuilding against DirectFB would "accidentally" link statically instead of dynamically. Thoughts? Some existing guideline I might have missed? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.17-1.2647.fc6 Load : 0.08 0.12 0.12

10 12

GTK+ icon cache "bugs" on ScriptletSnippets
by Marcin Garski 25 Sep '06

25 Sep '06

Hello, I'm a maintainer of Krusader package in Fedora Extras. Recently I've recived bug report http://bugzilla.redhat.com/206650 yum install krusader Installing: krusader ######################### [1/1] No theme index file in '/usr/share/icons/locolor'. If you really want to create an icon cache here, use --ignore-theme-index. I've started to investigate it. The problem is GTK+ icon cache. I've used in my spec file scripts from: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets (GTK+ icon cache section). This scripts doesn't check if %{_datadir}/icons/hicolor/index.theme exist, so in this case gtk-update-icon-cache generate such error. My proposed resolution for this bug can be found in http://bugzilla.redhat.com/206860 but I will also paste it here: if [ -x %{_bindir}/gtk-update-icon-cache ]; then if [ -f %{_datadir}/icons/hicolor/index.theme ]; then touch --no-create %{_datadir}/icons/hicolor || : %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : fi fi -- Best Regards Marcin Garski

3 5

Taking care of renamed config file
by Till Maas 21 Sep '06

21 Sep '06

Hiyas, I am updating the spec of john to the newest version. John now uses john.conf as config file but used john.ini before. Should I now rename existing john.ini to john.conf within a post or pre scriptlet or only add the new config file? I would prefer to rename it in a pre scriptlet if it is an upgrade so that the new shipped config file would be created as john.conf.rpmnew. Regards, Till

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging September 2006