1 |
On 29/02/12 22:57, Alexandre Rostovtsev wrote: |
2 |
> On Wed, 2012-02-29 at 21:24 +0100, Krzysztof Pawlik wrote: |
3 |
>> On 29/02/12 20:51, Alexandre Rostovtsev wrote: |
4 |
>>> The proposed eclass omits three features from python.eclass which are |
5 |
>>> heavily used in the gnome stack. |
6 |
>> |
7 |
>> Correct me if I'm wrong, but Gnome doesn't use standard distutils? |
8 |
> |
9 |
> Gnome is mostly written in C and therefore uses standard autotools :) |
10 |
|
11 |
Ok, thank you for this information. |
12 |
|
13 |
>>> Second, there doesn't seem to be any support for packages that do not |
14 |
>>> install in python's site-packages and do not allow multiple python ABIs. |
15 |
>>> If I have, for example, a package that installs python modules |
16 |
>>> in /usr/lib/appname or /usr/share/appname, how can I specify that |
17 |
>>> PYTHON_TARGETS="python2.6" or "python2.7" or "python3.2" is allowed, but |
18 |
>>> something like PYTHON_TARGETS="python2.7 python3.2" is not? |
19 |
>> |
20 |
>> You're correct, note that I've stressed that this eclass is mainly for |
21 |
>> distutils-based packages. I'm not using Gnome, so can you provide some package |
22 |
>> examples that I can look at? |
23 |
>> |
24 |
>> <personal opinion> |
25 |
>> If package decides to use given language then please, please play by the rules |
26 |
>> set by the rest of world (Ruby -> gems, Python -> distutils, Perl -> CPAN, PHP |
27 |
>> -> PEAR). |
28 |
>> |
29 |
>> I don't like installing Python code outside of site-packages, the only exception |
30 |
>> to that rule is portage (at least for now). |
31 |
>> </personal opinion> |
32 |
> |
33 |
> Some non-python packages allow python-based plugins. Obviously these |
34 |
> plugins live in the package's plugin directory (not in python's |
35 |
> site-packages) and use the package's main build system (not distutils), |
36 |
> and multiple python ABIs cannot be supported because that would result |
37 |
> in colliding plugins. Typical examples are app-editors/gedit, |
38 |
> media-gfx/gimp, media-sound/rhythmbox, or media-video/totem. |
39 |
> |
40 |
> Some packages install a C library that links to a specific version of |
41 |
> libpython or that defines a particular python version string at compile |
42 |
> time, making it impossible to use the package with multiple python ABIs. |
43 |
> Examples I know are dev-libs/libpeas and dev-python/nautilus-python. |
44 |
> |
45 |
> And then there are packages which could support e.g. multiple python2 |
46 |
> ABIs in theory, but doing so in practice would require a fair bit of |
47 |
> patching, taking substantial effort with no real benefit for end users. |
48 |
> An example that springs to mind here is gnome-extra/zeitgeist. |
49 |
|
50 |
I see - so it's the same case as with KDE (like Andreas wrote) - it's actually |
51 |
not a "python package" but rather an embedded Python. That's very different case |
52 |
than I'm targeting with this eclass (at least for now). |
53 |
|
54 |
>> I'd be happy to hear how to solve this - what prefix or suffix to use? One way |
55 |
>> would be quite trivial: if only one implementation is enabled do not create |
56 |
>> script-${impl}, go with single file, does that sound good? |
57 |
> |
58 |
> That would be the ideal solution. |
59 |
|
60 |
Ok, I've implemented this solution, now if one implementation is enabled there |
61 |
will be only one script, no foo-IMPL mangling. I've added also ability to |
62 |
install the script in other directory than /usr/bin. Hope this solves this case. |
63 |
|
64 |
Thank you for your comments and suggestions :) |
65 |
|
66 |
-- |
67 |
Krzysztof Pawlik <nelchael at gentoo.org> key id: 0xF6A80E46 |
68 |
desktop-misc, java, vim, kernel, python, apache... |