packaging May 2011

packaging@lists.fedoraproject.org

25 participants
12 discussions

Changing default paths for mono packages
by Christian Krause 03 Jun '11

03 Jun '11

Hi, After discussing the topic on mono-devel and with the upstream mono developers I would like to run the following suggestions by the FPC: The way how mono is packaged in Fedora is uncommon with respect to mono's default search paths. The standard mono's libdir "/usr/lib" was changed to "%{_libdir}" (which is "/usr/lib64" on x86_64). Since this contradicts upstream's understanding of the directory structure it causes lots of unnecessary work for the maintainers and quite a couple of bug reports due to uncaught uses of these default paths within the mono packages. Nearly every mono package must be adjusted and so the majority of all patches for mono consists solely of %{_libdir} "fixes". Since it looks like that upstream (not only mono-core, basically all mono-based packages) does not agree to these changes, non of these patches are accepted upstream nor do we get any help from upstream if the issues are caused by Fedora's directory structure. However, solving this issue (and reverting the change to mono's default paths) would include to loose the ability to use 32bit parts of the mono stack in x86-64 - a feature which never worked correctly and is not available for perl or python either. Fedora's decision to change the default paths was based on a statement from the mono developers a couple of years ago regarding the architecture-independence of the mono assemblies. I have discussed this topic with upstream again, and there was an agreement that mono assemblies are treated as platform independent and so the original reason to change the paths is not valid anymore. Please see all details on the following wiki: https://fedoraproject.org/wiki/User:Chkr/MonoMultiarchChanges So my question to the FPC: Do you agree with the suggested changes? Best regards, Christian

6 12

[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway 29 May '11

29 May '11

Here is this week's change to the Fedora Packaging Guidelines: --- The systemd guidelines on naming unit files have been amended to tell packagers how to make compatibility symlinks for alternate service names should their service have had a different name in the past. http://fedoraproject.org/wiki/Packaging:Systemd#Naming --- These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC). Many thanks to the Fedora Community, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~spot

1 0

file /etc/sudoers from install of sudo-config-20110520-1.noarch conflicts with file from package sudo-1.7.2p1
by Calum 20 May '11

20 May '11

Hello all, I am rolling my own RPM to provide the correct sudoers config for the company where I'm working. I want it to archive the existing /etc/sudoers, and put down the company's one. However, when I install it, I get:file /etc/sudoers from install of sudo-config-20110520-1.noarch conflicts with file from package sudo-1.7.2p1 There are two ways around it that I know: 1. Put the file down as /etc/sudoers.companyname, and mv it in the %post 2. Unpackage sudo, modify, and re-package. I prefer not to do 2, as that will require keeping a close eye on the security errata of the package, and repackaging every time a new version is released. I'd rather keep the upstream package untouched, and just apply my config over the top. 1 works fine - however, it breaks the rpm -V functionality, which in my eyes is a big plus point for using RPMs. Installing with --replacefiles will work - however - however, I want to deploy the package with Puppet, and it doesn't seem to allow specifying that. Is there a way to create the RPM in such a way that --replacefiles is "built-in" to the RPM? Is there any other way of doing this - so that rpm -V works? Calum

5 8

[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway 18 May '11

18 May '11

Here are the latest changes to the Fedora Packaging Guidelines: --- A section has been added to the SysVInitScript guidelines covering the optional situation where a package that uses systemd unit files as the default also includes sysv initscripts in a subpackage: https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addi… --- The GIO scriptlets have been changed to not conditionalize the %post invocation. This works around a multilib issue. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GIO_modules --- The guideline that prohibits Fedora packages from using /srv has been updated to better represent what the FHS has to say about /srv and to clarify the expectations for Fedora packages which may be configured to use /srv. https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories… --- It was brought to the FPC's attention that while the new Guidelines covering MinGW packaging were technically correct, Fedora 16 did not yet contain the necessary toolchain to support the new Guidelines, nor was it clear that it would arrive in rawhide anytime soon. Accordingly, the "old" MinGW guidelines were put back in place at: https://fedoraproject.org/wiki/Packaging:MinGW The "new" MinGW guidelines remain approved, but are not active and packagers should not use them at this time. If/when the necessary toolchain components are packaged in Fedora, these guidelines will be re-enabled. In addition, the current MinGW guidelines were improved slightly to support the "new" SRPM naming standard. This is intended to prevent new MinGW packages from having to be re-reviewed when the "new" MinGW guidelines take effect. --- These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC). Many thanks to Kalev Lember, Matthew Miller, Michael Schwendt, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~spot

1 0

How to add additional files in rpm
by Sunil_Gupta2＠Dell.com 15 May '11

15 May '11

Hello list, I am trying to add some programs in rpm which are not the part of source package. I copied them in BUILD directory and mentioned them in %install and %files section but rpmbuild -bb specfile always say Install: cannot stat `iotestlist.sh`: No such file or directory Am I missing something? --Sunil

4 6

need LEGAL answer for gst-entrans
by Remi Collet 15 May '11

15 May '11

I'm on the way to review gst-entrans https://bugzilla.redhat.com/show_bug.cgi?id=639518 This is a collection of plug-ins and tools for the GStreamer It only requires liboil, but produce various plugins /usr/lib64/gstreamer-0.10/libgstavidemux.so /usr/lib64/gstreamer-0.10/libgstentrans.so /usr/lib64/gstreamer-0.10/libgstmencoder.so /usr/lib64/gstreamer-0.10/libgsttranscode.so /usr/lib64/gstreamer-0.10/libgstvirtualdub.so /usr/lib64/gstreamer-0.10/libgstyuv4mpeg.so So, I must ask if there is any patent issue to include it in fedora repository. I seems ok to me, but I'm not a expert in legal issue. Remi.

2 2

No Fedora Packaging Committee Meeting on May 4
by Tom Callaway 11 May '11

11 May '11

There will not be a Fedora Packaging Committee Meeting on May 4, our next meeting will be May 11 at 1500 UTC in #fedora-meeting on irc.freenode.net. Thanks, ~tom == Fedora Project

2 1

.gitignore - what is supposed to be in it ?
by Development discussions related to Fedora 10 May '11

10 May '11

Hi, I noticed my .gitignore has: rakarrack-0.5.8_Equinox.tar.bz2 /rakarrack-0.6.1.tar.bz2 /rakarrack-47245c3.tar.gz The tar I expected to find 4724 is there, but so are the last few versions. How does this work / is something going wrong ?

3 2

input on a conflicts case
by Kevin Fenzi 10 May '11

10 May '11

Greetings. I'm looking at the supybot-gribble package (under review). https://bugzilla.redhat.com/show_bug.cgi?id=693664 Currently it Conflicts: supybot. It's not really falling under any of the current cases on http://fedoraproject.org/wiki/Packaging:Conflicts but I think it might be another case to add next to compat packages. Background: supybot is a irc bot written in python. It's already in Fedora. Development is very slow. Currently many of the database functions in it don't work because they still haven't switched from sqlite1 for example. We also have several plugins that use it. supybot-gribble is a blessed rapid development fork. Changes here are fast paced and much more current. Once patches here look good and stable they are submitted back to the main supybot branch. It's much like a 'supybot-rawhide' or devel. The two packages share the name and python tree files. Upstream has no desire to rename things in supybot-gribble as this will make it harder to fold changes back into supybot. There is no great need to run both at the same time on the same machine. In the review I suggested we just let them conflict and setup the plugins so they would work with either (require /usr/bin/supybot). To me this seems like an acceptable Conflicts case related to the 'compat packages' case, except in this case it's 'newer/rawhide/ng version'. Thoughts? Flames? kevin

5 5

checking digest of one file
by Aaron Hanson 09 May '11

09 May '11

Hi All - I can't figure out how to see and validate a specific file digest on my Fedora 14 system; I think I must be missing something simple. Here's a quick example of what I'm trying to do: [user@host]$ rpm -q --dump coreutils |grep bin/ls /bin/ls 109208 1288784582 def61ac5ca608ba6f41eb08aa3eaa0b2274a67512938030830051d792fb3946e 0100755 root root 0 0 0 X [user@host]$ sha256sum /bin/ls 881282512562ad22095371f0865be66f5424b7590e6c73eb15aae884cf9edd1c /bin/ls Why doesn't the digest match? 'rpm' says the package is fine: [user@host]$ rpm -V coreutils [user@host]$ echo $? 0 Thanks. Aaron

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging May 2011