Hi everyone,
I've been thinking a lot about the whole concept of Python2/3 packaging and
from my point of view it seems somehow confusing (renaming of python 3
binaries, split srpms/one srpm stuff and so on). I'm currently working with few
people on a "stack" (or software collection) concept, that we are testing with
Ruby and some of its libraries, as we are stepping to 1.9.3 from 1.8.7.
Basically, the stack allows you to have one runtime (say, python2) in normal
directory structure and then have a separate directory structure for another
runtime (python3 in this case) under /opt. So you don't need to rename all
paths and executables to python3-* and /usr/lib/python{2,3} or something like
that, but instead you use
$ python-binary
for the core system executable and you run
$ scl enable python3 "python-binary"
(where python3 is the name of the stack).
A great advantage of this concept is, that you have only one specfile, which
can be built both for the core system and for the stack and you don't need to
do any renaming or stuff like that. So when you decide that python 3 should be
in the core system, you just rebuild the packages in a different buildroot (I
think it can be achieved for both the split python2/3 SRPMS and SRPMS which
generate python2/3 RPMS from one source, but I'd have to think about a way how
to do it nice and systematically for both cases - but split SRPMS would be
better).
I'll try to explain how to get stack or core system RPM from one SRPM in
different buildroots:
- There is a library called scl-utils [1], that is aimed at providing the core
functionality for any stack. It has a runtime part, (the "scl enable ...")
which takes care of redefining systems paths, and a build part, which contains
redefinition of all macros that you normally use in the specfile (like
%{_libdir} etc.).
- If the build part of scl-utils is present in the buildroot that you are
building in, the resulting RPM has the relocated paths and installs under /opt.
If the build part of scl-utils is not in the buildroot, the resulting RPM gets
built normally for the core system.
(It is a little bit more complicated, but I think that everyone gets the point.)
If anyone of you is interested how this works with Ruby, there is a testing
prototype of a Ruby scl. You can read all the instructions how to install and
run the stack at [2] - but actually, this documentation is about an older
version, which was actually named stack, so here are the up-to-date commands:
- add the repofile from
http://bkabrda.fedorapeople.org/scl_1.8.7_01-27/scl_ruby_1.8.7.repo
- install the whole stack by "yum install scl_ruby_1.8.7" after adding the repo
- other commands from [2] apply, only substitute stack for scl (for example
'scl enable ruby_1.8.7 "irb"' will launch the ruby interactive console)
I think it would be great to consider this concept as an alternative (possibly
sometime even replacement) to the current python/python3 state. What do you
think, Pythonists? (And please don't kill me, I am just trying to suggest
something, not break the current concept or start a flame war :) )
Regards,
Bohuslav "Slavek" Kabrda.
[1] http://koji.fedoraproject.org/koji/packageinfo?packageID=12980
[2] http://mmaslano.livejournal.com/6963.html
_______________________________________________
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
