List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sun, 17 Jun 2012 11:43:30 +0200
Hans de Graaff <email@example.com> wrote:
> On Sun, 2012-06-17 at 09:26 +0200, Michał Górny wrote:
> > I'm attaching a reStructuredText version of the spec. You can view
> > it rendered as a gist. But please keep the replies on the list,
> > rather than forking the gist.
> I don't like the approach taken in 6. I'd rather state that there
> should not be file collisions between the dynamic slots. We already
> handle things this way in ruby (with a common 'all' and specific
> version builds).
That is impossible for most of the build systems. If Ruby has a nice
ability to split between building common and ABI-specific stuff, that's
great. But Python doesn't have one. Bindings built using other
languages don't have that either.
The usual way of handling that is through letting all the ABIs install
to the same image, and then installing whatever got merged as a result.
The spec practically suggests the same yet split in time.
Shortly saying, we can't do that or we will be stuck installing
everything by hand, which will practically make this idea useless.
> For 9c I can't see us limiting users to a single ruby implementation
> by default (the only current exception is www-apache/passenger), so a
> combined ||() block makes no sense to me. I think it is better to be
> explicit here and express the real situation with multiple ||() blocks
> if needed.
I think you misunderstand the concept of combined block. It was mostly
supposed to be useful when a single package provides bindings for
multiple languages, so that a single build would involve building
bindings for one ABI of one language.
Multiple blocks would involve building bindings for both one Python ABI
and one Ruby ABI at a time which means scary results. That probably
even won't work, so splitting it is the only alternative to one big
> Finally, I don't expect ruby to use this unless we can ensure that
> this works with our current ebuilds without changes. I'm fine with
> supporting some code in the eclass to determine which mechanism to
> use in which way, but we won't be spending huge amounts of time
> switching to yet another system. To me the perceived benefits aren't
> big enough.
I'm trying hard to make this as painless as possible but I can't
guarantee single ebuilds (uncommon cases) wouldn't need changes.
However, I'm trying hard to ensure that majority would be clearly
handled by eclasses.