On 2015-03-30, Alan McKinnon <alan.mckin...@gmail.com> wrote:
> On 30/03/2015 15:04, Holger Hoffstätte wrote:
>> On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote:
>>> On Mon, 30 Mar 2015 12:15:01 +0000 (UTC), Holger Hoffstätte wrote:
>>>
>>>>> Portage does not override your choices, and it certainly does not
>>>>> allow one single ebuild to automagically change the behaviour of
>>>>> multiple other ebuilds. The correct way to bring about changes in
>>>>> behaviour is to add your global choices to make.conf (which is
>>>>> outside the control of the tree), or to add your explicit changes to
>>>>> package.* 
>>>>
>>>> ..that just shows the root of the problem: the ABI is not handled
>>>> consistently, but rather as a per-package configuration choice.
>>>
>>> The news item also showed how to make it a global choice, avoiding the
>>> need to multiple per-package directories.
>> 
>> I'm not sure that's a solution to the problem at all (which is why I
>> didn't do it on my machines either).

If the problem is that you don't want things to be inconsistent, then
it _does_ solve the problem.

>> Apart from always wasting much more work & resources than necessary
>> for no good reason

The reason is that somebody wanted their system to be "consistent." I
don't think that's a particulary good reason, but that's the nice
thing aboug Gentoo.  Everybody gets to decide what is important to
them, and build their system accordingly.

>> it doesn't answer the question what happens as soon as I want to
>> build a package that is 64-bit-only - in which case you'd end up in
>> the same situation we have now, just mirrored.

You can have your system be consistent by setting up everything using
global values in make.conf, or you can choose to override that
consistency by manually enabling/disabling USE variables on a
per-package basis.  That's how Gentoo works and how Gentoo has always
worked.  I don't how this is any different.

> Maybe it's time we asked the multilib devs how they intended to deal
> with these questions you raise.

It seems there are two options:

  1) Add abi_x86_32 on a package-by-package basis (or let emerge do it
     for you when you tell it to install something with 32-bit
     requirements like acroread).

  2) Add ABI_X86="64 32" to make.conf, and then add -abi_x86_32 on a
     package-by-package basis if/when you want to build something
     64-bit-only.

It looks like they intended for you to choose whether you want 32 bit
versions built as the exception or as the rule.  For the former, you
do 1). For the latter, you do 2).  

So far, I'm going with 1).  When I decided to install acroread this
morning, emerge added abi_x86_32 flags to package.use for about 80
packages.  The other option would have re-built about 200 packages.

Either way would have worked, but I wanted to see if emerge really was
able to selectively rebuild the subset of packages required by
acroread.  AFAICT, it did just fine.

-- 
Grant Edwards               grant.b.edwards        Yow! Yes, but will I
                                  at               see the EASTER BUNNY in
                              gmail.com            skintight leather at an
                                                   IRON MAIDEN concert?


Reply via email to