Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: tommy@g.o
Subject: Re: [gentoo-dev] [RFC] Dynamic SLOTs
Date: Sun, 17 Jun 2012 15:53:53
Message-Id: 20120617175342.49253a2e@pomiocik.lan
In Reply to: Re: [gentoo-dev] [RFC] Dynamic SLOTs by Thomas Sachau
On Sun, 17 Jun 2012 17:46:00 +0200
Thomas Sachau <tommy@g.o> wrote:

> >> Beside that, it seems to solve things pretty similar to the > >> proposed way in multilib-portage for cross-compiling (which could > >> also be adapted for multi-slot languages) with different wording > >> and with additional work for ebuild maintainers. And since my > >> proposal already uses USE flags, things would not change visually > >> for users of e.g. ruby or php. > > > > I'm sad you aren't even trying to listen. Your attempt implies that > > every single change in targets requires rebuilding all of them. If I > > weren't using 32-bit libs, and now I want to compile 32-bit wine, I > > have to recompile most of my libraries for both ABIs. That is > > a no go for me. > > So you want to build a 32bit package, which is depending on 32bit > libs, but want to do that without the needed dependencies? Please > tell me, how that works.
I'm trying to build a 32bit package and its 32bit dependencies. Your solution involves building a 32bit package and rebuilding all 64bit packages which happen to be its dependencies for no reason.
> > And adjusting that for other multi-slot languages is pointless. > > Because they do the same already. > > So you dont like one framework for all multi-slot languages and prefer > having each one using their own solution? Or do you just dislike my > idea for them and want to use your own suggestion for them?
I'm just saying that your framework doesn't change anything for user; it just involves some work to change the label. -- Best regards, Michał Górny


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] [RFC] Dynamic SLOTs Thomas Sachau <tommy@g.o>
Re: [gentoo-dev] [RFC] Dynamic SLOTs Ian Stakenvicius <axs@g.o>