packaging March 2013

packaging@lists.fedoraproject.org

31 participants
16 discussions

Required use of /opt for AWS compatability
by Jeff Peeler 09 Apr '13

09 Apr '13

The spec file in question is located here: https://github.com/sdake/heat-rpms/blob/master/heat-cfntools.spec I assume that since it is against Fedora guidelines to install to /opt, that there aren't any exceptions. We do have in the repo a script to create the AWS compatible symlinks in /opt, rather than the actual files: https://github.com/openstack/heat-cfntools/blob/master/bin/cfn-create-aws-s… Would it be acceptable to call the above script in the %post section? I'm just not sure the proper way to proceed with the compatability and guidelines being in conflict. Jeff

3 2

python3-pyside package issue
by Truong Anh Tuan 31 Mar '13

31 Mar '13

Hello folks, I got a problem when packaging a new package, ibus-bogo [1]. Upstream developers use Python 3 bindings for Qt4 while I just found python-pyside (for Python 2) in Fedora package database [2]. Seems I need to work on another new package python3-pyside too, right? Any ideas and suggestions? Btw, I submitted a new request on Bugzilla [3] to get that new package reviewed. It's highly appreciated if someone can take a look at. [1] https://github.com/BoGoEngine/ibus-bogo-python [2] https://admin.fedoraproject.org/pkgdb/acls/name/python-pyside [3] https://bugzilla.redhat.com/show_bug.cgi?id=917365 Thanks in advance, Tuan

2 2

Inconsistencies in Python package naming
by Bohuslav Kabrda 28 Mar '13

28 Mar '13

Hi all, so after spending some months with Python packaging, I came to think that the naming has to be standardized better. Problem 1: The naming guidelines say, that if there is "py" or "Py" in package name, you _can_ use that name for a package, otherwise use python-{name} [1]. So if I'm trying to install "pygments", I just try "pygments", but whoops - it's named python-pygments. How could I tell? Problem 2: If I install "PyYaml" (this time I was lucky and guessed correctly), then it's confusing that I have to install python3-PyYaml. Both should be prefixed "python[possibly 3]-", or none of them. Problem 3: The table in [2] is even more confusing. If the upstream name is "pygtk", why should Fedora's package be called "pygtk2"? Where did the "2" come from? Why do we need it if Python 3 version is clearly named "python3-pygtk"? So my proposal would be: Let's make it mandatory for all the Python package names to be prefixed with python-/python3-. If the upstream name already starts with "python-", then let's use that (possibly inserting the "3"). Another python implementations may pose a problem here - if we decide to package something for pypy, how do we call it? My suggestion would be to use it instead of "python-" - so "python-foo" would translate to "pypy-foo" in terms of binary RPM names. Please note, that very similar proposal was already discussed some time ago on python-devel [3], and this feature [4] (never actually proposed) was created back then. I'm trying to restart the discussion to make this moving. Thoughts? Thanks. -- Regards, Bohuslav "Slavek" Kabrda. [1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.2… [2] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.2… [3] http://lists.fedoraproject.org/pipermail/python-devel/2012-August/000435.ht… [4] https://fedoraproject.org/wiki/Features/PythonNamingDependingOnImplementati…

7 18

Filtering Provides for Node.js Binary Extension Modules
by T.C. Hollingsworth 26 Mar '13

26 Mar '13

Like the equivalent many other languages, Node.js C++ extension modules result in unwanted provides that by policy need to be filtered, We definitely want to provide a %nodejs_default_filter similar to Perl's %perl_default_filter to make this easy for packagers. However, I understand the old guidelines are outdated, and Perl's macro already uses the new version [1]. Should we go ahead and use the new version too when implementing %nodejs_default_filter or wait for the draft to be approved? Thanks! -T.C. [1] https://fedoraproject.org/wiki/User:Toshio/AutoProvidesAndRequiresFiltering…

3 2

Moving non-guideline stuff out of guidelines
by Stanislav Ochotnicky 22 Mar '13

22 Mar '13

As noted when we were giving FPC latest Java guidelines to review, we are in process of restructuring them in more significant ways. One of the most important aspects is moving documentation of tools outside of guidelines. Some parts of current Java guidelins[1-6] are prime examples of things that we are planning to move out of guidelines and into separate "Java Packaging HOWTO" document. Other guidelines probably don't suffer from this as much as Java ones (50% of text is description of how to use tools), but still... Goal is of course not to circumvent Fedora policies but make sure that guidelines contain the policy, whereas real documentation contains descriptions of how to do things. In other words guidelines should IMO contain *what* (not) to do, and other documents should tell packagers *how* to do it. Any thoughts on the matter? It will be some time before we submit an update to guidelines either way, but I like early feedback :-) [1] https://fedoraproject.org/wiki/Packaging:Java#add_maven_depmap_macro [2] https://fedoraproject.org/wiki/Packaging:Java#Additional_mappings [3] https://fedoraproject.org/wiki/Packaging:Java#Alternative_JAR_file_names [4] https://fedoraproject.org/wiki/Packaging:Java#Single_artifact_per_package [5] https://fedoraproject.org/wiki/Packaging:Java#Assignment_of_the_Maven_artif… [6] https://fedoraproject.org/wiki/Packaging:Java#Patching_Maven_pom.xml_files -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

2 1

Vote in ticket: Ruby Guidelines update
by Toshio Kuratomi 20 Mar '13

20 Mar '13

Since FPC hasn't had quorum for several weeks, the members at the meeting today decided to select one or two tickets each and propose votes in ticket. Here's my low hanging fruit: https://fedorahosted.org/fpc/ticket/256 We voted to approve this initially 4 weeks ago however after more discussion in the ticket it became apparent that the update is unclear on what would be misuse of the -d switch to the %gem_install macro. To unstick that, I proposed a change to the guideline: https://fedorahosted.org/fpc/ticket/256#comment:10 Please vote in the ticket or discuss here. Thank you, Toshio

1 0

RPM macro for /usr/lib/rpm/macros.d?
by Björn Persson 16 Mar '13

16 Mar '13

I have a file of RPM macros (macros.gnat) which has been in /etc/rpm until now. I agree with the recent decision that such files aren't configuration, and therefore I'm moving it to /usr/lib/rpm/macros.d. Should I write the path as "%{_rpmconfigdir}/macros.d", or is there a better macro to use? Björn Persson

2 2

[Proposal] Packaging guidelines/spec per version
by Vít Ondruch 14 Mar '13

14 Mar '13

Hi, Wouldn't it be possible to have packaging guidelines versioned by Fedora version? If this would be accompanied by the rule, that .spec files can't be shared as well (using some conditions), this would allow us to have much faster evolution of our packaging. I'll give you a few examples. = Tilde versioning It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited by guidelines [2]. = Support for /usr/lib/rpm/macros.d/ Available since RPM 4.11 [3, 4], i.e. Fedora 19, nobody place the additional macros there (well I'll fix Ruby and RubyGems as soon as I'll have some free cycles). Actually it could be nice scripted. = Changes in Ruby guidelines There are currently 3 versions of Ruby guidelines [5], which apply to different versions of Fedora and EPEL anyway. = %clean section Not mandated since F13 [6], but widely used in older packages. That could be easily removed by script it there would not be chance that the package is in use for EPEL5 = BuildRoot tag Not needed since F10! [7] But needed by EPEL. BTW you should not update packages in EPEL, to keep ABI stability, anyway, so why you should carry around such thing in F20? There is high chance that EPEL5 package contains much older version. = mandatory %defattr at the beginning of %files section Not needed since RPM 4.4 [8]. This is not exhaustive list. If you just count %clean section, BuildRoot tag and %deffattr, the spec file could be 5 lines shorter. 5 lines which can make difference in maintainability, in attraction new packagers, since they would not need to wonder "what the BuildRoot is there for?" What I have learned during recent rebuild of Ruby packages is that the .specs, which contains conditions to support different versions of Fedora or EPEL are the one, which are the hardest to maintain. There is no simple way how to automatically migrate them to support newer guidelines. This exactly prohibits the innovation. This prohibits any new feature which we could benefit. If the .spec would be specific to the Fedora version, it could follow the latest and greatest development. However there are some version specific branches which prevent that. Some may object, that the resulting binary RPM should be compatible between Fedoras and installable everywhere, but I can assure you, that you cannot install any RPM which depends on Ruby from F18 to F19 and vice versa, so the argument is moot. This apply also to all libraries after soname bump, not just that we are doing something terribly wrong in Ruby. So please, consider this proposal. In a long term (speaking about really long term now), the .spec file should contain just a few lines, such as SOURCE0 and the rest would be done by a few simple macros. Take a look for example what Java guys did recently [9] and how it used to be [10] (I am sure they could provide you better examples :). This would let us to focus on more important things then copy pasting guidelines to .spec files. Thank you Vít [1] http://www.rpm.org/wiki/Releases/4.10.0 [2] http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag [3] http://www.rpm.org/wiki/Releases/4.11.0 [4] https://bugzilla.redhat.com/show_bug.cgi?id=846679 [5] https://fedoraproject.org/wiki/Packaging:Ruby [6] https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean [7] https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag [8] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions [9] https://fedoraproject.org/wiki/Packaging:Java#Apache_Maven [10] https://fedoraproject.org/w/index.php?title=Packaging:Java&oldid=246507#mav…

10 29

Question about packaging of MPICH2
by Andrew Prokhorenkov 12 Mar '13

12 Mar '13

I get confused with the environment modules with MPICH2 package. It has two identical modules files: /etc/modulefiles/mpich2-i386 /etc/modulefiles/mpi/mpich2-i386 If they are identical, why not to make one of them a symlink? Does even both files needed? For example, in openmpi there is only one file: /etc/modulefiles/mpi/openmpi-i386 -- Andrew Prokhorenkov

2 1

FPC Meeting this week
by Toshio Kuratomi 11 Mar '13

11 Mar '13

This is just a heads up that I will probably not be available this week for the FPC meeting. If someone else wants to run it, please do. the only two commands you absolutely need to know are: #startmeeting fpc #endmeeting If you need me to vote after the meeting on certain tickets, just let me know. Next week I hope to be present for the meeting but I can't promise I will. I'm at the PyCon conference both weeks but next week is the hackfest portion so it will depends on internet connectivity more than scheduling. The Haskell Guidelines are one thing that needs to be looked over and voted upon: https://fedorahosted.org/fpc/ticket/194 The filtering guidelines need one vote to pass (or five negative votes to fail): https://fedorahosted.org/fpc/ticket/189 I think that all other tickets that we were voting on in trac are done. Lots of "new" tickets if you get past those two. -Toshio

4 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2013