packaging October 2009

packaging@lists.fedoraproject.org

41 participants
21 discussions

Proposal: naming convention for Python 3 packages and subpackages
by David Malcolm 04 Nov '09

04 Nov '09

(Resurrecting the "Proposal: Python 3 in Fedora 13" thread; see: https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html and https://fedoraproject.org/wiki/Features/Python3F13 ) On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote: > On 10/01/2009 10:15 AM, David Malcolm wrote: [snip] > > "Naming convention" proposal: > > How does this sound: > > - an rpm with a "python-" prefix means a python 2 rpm, of the > > "default" python 2 minor version (for Fedora this will be the most > > recent stable upstream minor release, for EPEL it will be the minor > > release of 2 that came with the distro, so 2.4 for EPEL5) > > > > - an rpm with a "python3-" prefix means a python 3 rpm, of the > > "default" python 3 minor version (for Fedora this will be the most > > recent stable upstream release) > > > > What about packages without a "python-" prefix? Proposal: If upstream > > has a naming convention for python2 vs python3, use it. Otherwise, add > > a "python3-" prefix to make things clear. I'm not sure about the > > details here. Examples? > > > +1 to the basics. There are a lot of details to work out: Current naming conventions for Python packages are in https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.2… I rather like the idea of standardizing on a "python3-" prefix for _all_ Python 3 module packages and subpackages, even if this leads to inconsistencies with their counterparts in the python 2 stack. It would make the "threeness" of the packages stand out more. (NB: I hope that we'll eventually be in a place where we can cut over embedders and users of python (e.g. gedit, gdb, mod_python etc) from 2 to 3; I'm _not_ suggesting we do anything to their names. Obviously such a move is a long way off) > This seems fine even though it's a bit redundant: python3-pygtk2 and > python3-pygpgme. We could combine: - the "always use a python3-" rule I invented just above (ahem) and - the "When in doubt, use the name of the module that you type to import it in a script" advice from the python module guidelines. This would make the above examples be "python3-gtk" and "python3-gpgme" > What to do with things that have python in their suffix: > gstreamer-python => gstreamer-python3? Or python3-gstreamer? Or > python3-gstreamer-python? Most of these are subpackages of existing > packages. Again, following the combination of the two rules above: "python3-gstreamer" > A cornercase is the gnome-python2 package. These are python bindings to > gnome2. gnome-python2 is the upstream name. For python3, do we want > python3-gnome-python2, python3-gnome2, python3-gnome-python2 ? >From my reading of "rpm -qi gnome-python2", the upstream name is "gnome-python", so perhaps "python3-gnome" is the thing to use here? Thoughts? Dave

3 3

Python 3 compatibility update to Python guidelines
by Ville Skyttä 04 Nov '09

04 Nov '09

https://fedoraproject.org/wiki/Packaging:Python %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} These no longer work with Python 3 due to "print" changes. They should be replaced with something like these that work with both Python 2 and 3 (already done in spectemplate-python.spec in rpmdevtools git): %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import *; import sys; sys.stdout.write(get_python_lib())")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import *; import sys; sys.stdout.write(get_python_lib(1))")}

3 8

ruby/rubygem packagers - advice needed
by Matthew Kent 29 Oct '09

29 Oct '09

Having some difficulty deciding on the right path for this package, need some advice. ohai - http://wiki.opscode.com/display/ohai/Home "Ohai detects data about your operating system. It can be used standalone, but it's primary purpose is to provide node data to Chef." - Written in Ruby. - Available as a rubygem. - No standalone install via tar.gz + setup.rb yet. - 6 dependencies. All currently packaged as rubygem-* packages. 5 of which I'm the maintainer. - Available in Debian/Ubuntu as 'ohai', packaged from source and uses no rubygems at all. - require 'rubygems' has been removed from the codebase, only time it's loaded now is when the user installs via gems and it generates the little /usr/bin/ohai wrapper. Options: a) Package as rubygem-ohai from .gem Pro - Easiest method, rubygem-* dependencies work as is. Pro - As there is no setup.rb yet this may ease maintenance. Con - Different from Debian naming. ohai is also very similar to the 'facter' package that puppet uses, should be positioned in the same way. Con - Can only use what's carried in the gem, eg: man page isn't. Would have to carry as a separate Source. Could have unit tests removed from the gem in the future if they grow too large (upstream did this for another gem they produce). b) Package as ohai from a checkout of the git tag, dependencies on rubygem-* packages Pro - Common package name with other distros. Pro - Have access to install all content, including the man page. Con - Handcrafted %install. Con - Have to forever patch lib/ohai to load rubygems so the dependencies resolve. c) Package as ohai from a checkout of the git tag, dependencies on non gem ruby-* packages Pro - Common package name with other distros. Pro - Have access to install all content, including the man page. Pro - No need to patch to load rubygems. Con - Handcrafted %install. Con - Will need to produce non gem sub packages for every dependency, immediately adding 4 additional rpms to the repos. d) ? This decision making process is much the same for my main goal of packaging Chef (http://wiki.opscode.com/display/chef/Home) but has bigger implications as it has way more dependencies, needs init scripts, it's own user, etc. Stuff that is probably beyond the scope of rubygem-* packages (?). I'm leaning toward option c) as I like the idea of using the unmodified source in it's entirety, which once a setup.rb is added upstream won't be that bad. I'm interested to hear any thoughts on potentially generating a bunch more ruby-* packages though. Thoughts? - Matt

2 1

Using Debian packaging bits in Fedora packages
by Mary Ellen Foster 28 Oct '09

28 Oct '09

I was just wondering -- is there a policy on using bits of Debian packages in Fedora packages? As a concrete example, if Debian has already packaged a Java library and has written a build.xml file (essentially, a Makefile) for building it, am I allowed to include that file in my package? Should I apply the whole Debian patch (complete with upstream URL) and then copy the build.xml to where it needs to be, or can I just grab the build.xml file itself and include it as a source? Thanks for any suggestions, MEF -- Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/ Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab School of Mathematical and Computer Sciences, Heriot-Watt University Heriot-Watt University is a Scottish charity registered under charity number SC000278

6 5

Help please? How do I express a dependency on a Perl module not installed in a standard place within an RPM spec file?
by richard.hellier＠stfc.ac.uk 27 Oct '09

27 Oct '09

Hi, Situation I have is this: (a) I have a bunch of perl scripts that use a perl module (say Foo) that is not installed on the "package build machine" (b) On the target machine, the FOO module was "hand installed" in antiquity in /opt/foo In the perl scripts, I have: Use lib qw{/opt/foo/lib}; Use Foo::Bar; SO - I can build the package fine but when I try to install it, I get the messages: error: Failed dependencies: perl(Foo::Bar) is needed by some-package-1.1.1-1.noarch Any ideas, please, how I can "teach" the spec file that the required perl module lives in a certain place on the target machine? Thanks! Richard. -- Scanned by iCritical.

3 2

app wants runtime help file in /usr/share/help
by Development discussions related to Fedora 27 Oct '09

27 Oct '09

Hi, an app I maintain recently gained a help menu. It expects to find the single help.html file in /usr/share/help (ie: make install helpdir=%{buildroot}%{_datadir}/help ) This folder seems to be owned by rarian, and hence doesn't seem to make sense as location to place this help file. Is the best approach to patch the src so that it expects to find the help file in a better location ? What would that location be ? ie. maybe: make install helpdir=%{buildroot}%{_datadir}/%{name} , and then adjust src to look there ? Cheers, David Timms

2 4

Help need to create rpm package for my java pplication
by sunil.sahoo＠artificialmachines.com 26 Oct '09

26 Oct '09

Hi all, I have created a java application. Now I need to create rpm package for that application. Also I want to put desktop shortcut and icon also. means if i go to Applications and click on shortcut then my original program will start. Actually I have created an rpm file it works fine, But I was unable to get how to do for desktop shortcut and icon for that application I need your help Thanks Sunil Kumar Sahoo

3 2

Errors in Packaging:Python#Byte_Compiled_Files
by Ville-Pekka Vainio 25 Oct '09

25 Oct '09

Hi, I'm adding a Python interface to a package of mine and was reading https://fedoraproject.org/wiki/Packaging:Python#Byte_Compiled_Files where it says: %install install -d %{python_sitelib}/foo install -pm 0644 foo.py %{python_sitelib}/foo/ but you can't actually use %{python_sitelib} on it's own in %install. I think those instructions should be something like: %install install -d $RPM_BUILD_ROOT%{python_sitelib}/foo install -pm 0644 foo.py $RPM_BUILD_ROOT%{python_sitelib}/foo/ -- Ville-Pekka Vainio

3 2

updated F12 dependent packages
by Sean Middleditch 25 Oct '09

25 Oct '09

Hey everyone, I've got two packages in F12, libtelnet and clc, where clc is dependent on a specific version of libtelnet. I pushed libtelnet 0.12 into F12-updates-testing, but I cannot get clc in. The new version of clc has a hard dependency on libtelnet 0.12, but the repo for F12 hasn't rebuilt. According to Koji, it can't rebuild the repo because now clc won't build due to the old version only building against 0.11. How the hell am I supposed to push the update clc and fix the repo building?

2 2

Garbage Collection of fc12 build [X-Post]
by Rangeen Basu 23 Oct '09

23 Oct '09

Hi The fc12 build of one of my packages has been tagged with trashcan and will be deleted by koji. Does this mean that the package will be removed from the fc12 repository? If so then how can it be saved as it is a part of the fedora electronic lab and must not be removed at this point. -- Regards Rangeen Basu Roy Chowdhury Fedora Ambassador sherry151(a)gmail.com Sent from Bangalore, KA, India

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging October 2009