(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_...
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

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

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

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.

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

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

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?

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