| 1 |
On Sun, 17 Jun 2012 11:43:30 +0200 |
| 2 |
Hans de Graaff <graaff@g.o> wrote: |
| 3 |
|
| 4 |
> On Sun, 2012-06-17 at 09:26 +0200, Michał Górny wrote: |
| 5 |
> |
| 6 |
> > I'm attaching a reStructuredText version of the spec. You can view |
| 7 |
> > it rendered as a gist[1]. But please keep the replies on the list, |
| 8 |
> > rather than forking the gist. |
| 9 |
> |
| 10 |
> I don't like the approach taken in 6. I'd rather state that there |
| 11 |
> should not be file collisions between the dynamic slots. We already |
| 12 |
> handle things this way in ruby (with a common 'all' and specific |
| 13 |
> version builds). |
| 14 |
|
| 15 |
That is impossible for most of the build systems. If Ruby has a nice |
| 16 |
ability to split between building common and ABI-specific stuff, that's |
| 17 |
great. But Python doesn't have one. Bindings built using other |
| 18 |
languages don't have that either. |
| 19 |
|
| 20 |
The usual way of handling that is through letting all the ABIs install |
| 21 |
to the same image, and then installing whatever got merged as a result. |
| 22 |
The spec practically suggests the same yet split in time. |
| 23 |
|
| 24 |
Shortly saying, we can't do that or we will be stuck installing |
| 25 |
everything by hand, which will practically make this idea useless. |
| 26 |
|
| 27 |
> For 9c I can't see us limiting users to a single ruby implementation |
| 28 |
> by default (the only current exception is www-apache/passenger), so a |
| 29 |
> combined ||() block makes no sense to me. I think it is better to be |
| 30 |
> explicit here and express the real situation with multiple ||() blocks |
| 31 |
> if needed. |
| 32 |
|
| 33 |
I think you misunderstand the concept of combined block. It was mostly |
| 34 |
supposed to be useful when a single package provides bindings for |
| 35 |
multiple languages, so that a single build would involve building |
| 36 |
bindings for one ABI of one language. |
| 37 |
|
| 38 |
Multiple blocks would involve building bindings for both one Python ABI |
| 39 |
and one Ruby ABI at a time which means scary results. That probably |
| 40 |
even won't work, so splitting it is the only alternative to one big |
| 41 |
block. |
| 42 |
|
| 43 |
> Finally, I don't expect ruby to use this unless we can ensure that |
| 44 |
> this works with our current ebuilds without changes. I'm fine with |
| 45 |
> supporting some code in the eclass to determine which mechanism to |
| 46 |
> use in which way, but we won't be spending huge amounts of time |
| 47 |
> switching to yet another system. To me the perceived benefits aren't |
| 48 |
> big enough. |
| 49 |
|
| 50 |
I'm trying hard to make this as painless as possible but I can't |
| 51 |
guarantee single ebuilds (uncommon cases) wouldn't need changes. |
| 52 |
However, I'm trying hard to ensure that majority would be clearly |
| 53 |
handled by eclasses. |
| 54 |
|
| 55 |
-- |
| 56 |
Best regards, |
| 57 |
Michał Górny |
Archives