[gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Hello,

There is a fair interest in multilib and while still early, it would be
a good moment to decide on how USE flags to use for it.

The current attempts are mostly using USE=multilib which is not really
expressive and poor. What I would go for is a clear variable specifying
which targets package is built for.


This raises the following questions:

1) do we want the default ABI to be switchable?

2) do we want irrelevant ABIs to be visible to emerge users?

By 2) I mean: do we want the users to see stuff like:

  MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
    (-ppc64_abi2) (-ppc64_abi3) ..."

or just the relevant part.

To be honest, I don't know if there's other way to hide USE flags than
using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
the flags per-arch, i.e. have:

  MULTILIB_AMD64="abi1 abi2 abi3"
  MULTILIB_PPC64="abi1 abi2 abi3"

with appropriate USE_EXPAND_HIDDEN set by profiles.


What are your thoughts? Which arches would like to use multilib? What
names for ABIs do you suggest?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 2904 bytes --]

On Sun, 20 Jan 2013 20:11:31 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Hello,
> 
> There is a fair interest in multilib and while still early, it would be
> a good moment to decide on how USE flags to use for it.
> 
> The current attempts are mostly using USE=multilib which is not really
> expressive and poor. What I would go for is a clear variable specifying
> which targets package is built for.

You just need to add 'ABI' and 'MULTILIB_ABIS' to
"emerge --info ${pkg}" output.

Do you plan to keep precise depends for packages?
like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.

What to do if someone builds a package only with non-default ABI?
(it means installed package does not quite work for default ABI)

like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
any of ABI=amd64 users.

In order to track such depends precisely you would need to add
ABI flags to each revdep recursively. It's quite invasive. Is it worth
the effort?

Currently USE=multilib means 'build for all toolchain-supported' ABIs.
It looks clean and short.

> This raises the following questions:
> 
> 1) do we want the default ABI to be switchable?
It already is via /etc/portage/env per-package.
Or via profile globally. arch/amd64/make.defaults:
  MULTILIB_ABIS="amd64 x86"                                                                                
  DEFAULT_ABI="amd64"

crossdev allows bootstrapping with any random default
ABI out there as one-liner:
    crossdev -A 'x32 amd64' x86_64-unknown-linux-gnu.

> 2) do we want irrelevant ABIs to be visible to emerge users?
> 
> By 2) I mean: do we want the users to see stuff like:
> 
>   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
>     (-ppc64_abi2) (-ppc64_abi3) ..."

Would adding irrelevant ABIs trigger rebuilds on world update?

Do you intermingle gentoo's $ARCH and ABI?
How many ABI vars do you expect to see for simple "common" cases?

  x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64)
  x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64)
  x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64)
  i686-pc-linux-gnu-gcc -m32 (host ARCH=x86)
  i686-pc-linux-gnu-gcc -m64 (host ARCH=x86)
  i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86)

3 or 6?

Looks like insane amount of metadata growth for each
plagued package.

> or just the relevant part.
> 
> To be honest, I don't know if there's other way to hide USE flags than
> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> the flags per-arch, i.e. have:
> 
>   MULTILIB_AMD64="abi1 abi2 abi3"
>   MULTILIB_PPC64="abi1 abi2 abi3"
> 
> with appropriate USE_EXPAND_HIDDEN set by profiles.

Having direct support in portage's core might reduce amount of
user-visible/storable metadata in main tree. No slightest idea
how it would look like though.

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3515 bytes --]

On Mon, 21 Jan 2013 01:05:56 +0300
Sergei Trofimovich <slyfox@gentoo.org> wrote:

> On Sun, 20 Jan 2013 20:11:31 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > There is a fair interest in multilib and while still early, it would be
> > a good moment to decide on how USE flags to use for it.
> > 
> > The current attempts are mostly using USE=multilib which is not really
> > expressive and poor. What I would go for is a clear variable specifying
> > which targets package is built for.
> 
> You just need to add 'ABI' and 'MULTILIB_ABIS' to
> "emerge --info ${pkg}" output.

No, that's not the same. It's like python.eclass vs new Python
eclasses. Cheap hidden logic vs explicit USE-dep logic.

> Do you plan to keep precise depends for packages?
> like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.

Yes. ${MULTILIB_USEDEP} is for that (it currently evaluates
to 'multilib?').

> What to do if someone builds a package only with non-default ABI?
> (it means installed package does not quite work for default ABI)

Well, I was asking the same question. That was what my q1 was asking,
I think you misunderstood it.

> like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
> any of ABI=amd64 users.
> 
> In order to track such depends precisely you would need to add
> ABI flags to each revdep recursively. It's quite invasive. Is it worth
> the effort?

A good point. I'd say that the default impl should be built then.
But... how about making it a USE flag with use.force logic? That way,
it would be explicitly visible, and if someone really wanted to disable
it, he would be able to do it on his own responsibility.

> Currently USE=multilib means 'build for all toolchain-supported' ABIs.
> It looks clean and short.

But if we wanted to introduce x32, it would become no longer clean. I
believe many of our users want/need multilib only for running 32-bit
apps on amd64 (like wine). Why would they need x32 libraries?

But on the other hand, if we follow that logic we will probably have
no reason to enable x32 on amd64 for a long time. Maybe mips ABIs will
be a better example?

> > 2) do we want irrelevant ABIs to be visible to emerge users?
> > 
> > By 2) I mean: do we want the users to see stuff like:
> > 
> >   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
> >     (-ppc64_abi2) (-ppc64_abi3) ..."
> 
> Would adding irrelevant ABIs trigger rebuilds on world update?

That's a good question, especially wrt USE_EXPAND_HIDDEN.

> Do you intermingle gentoo's $ARCH and ABI?

I think not. I believe that ABIs shall be defined by profiles.
If someone tries to set ARCH for something incorrect for the profile,
that's not something we shall support, I believe.

> How many ABI vars do you expect to see for simple "common" cases?
> 
>   x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64)
>   x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64)
>   x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64)
>   i686-pc-linux-gnu-gcc -m32 (host ARCH=x86)
>   i686-pc-linux-gnu-gcc -m64 (host ARCH=x86)
>   i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86)
> 
> 3 or 6?

I think 3 will be enough.

> Looks like insane amount of metadata growth for each
> plagued package.

I don't think metadata is really important here. I believe that
the amount of additional metadata introduced by the packages affected
by multilib is not really one worth worrying.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Michał Górny schrieb:
> Hello,
> 
> There is a fair interest in multilib and while still early, it would be
> a good moment to decide on how USE flags to use for it.
> 
> The current attempts are mostly using USE=multilib which is not really
> expressive and poor. What I would go for is a clear variable specifying
> which targets package is built for.
> 
> 
> This raises the following questions:
> 
> 1) do we want the default ABI to be switchable?
> 
> 2) do we want irrelevant ABIs to be visible to emerge users?
> 
> By 2) I mean: do we want the users to see stuff like:
> 
>   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
>     (-ppc64_abi2) (-ppc64_abi3) ..."
> 
> or just the relevant part.
> 
> To be honest, I don't know if there's other way to hide USE flags than
> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> the flags per-arch, i.e. have:
> 
>   MULTILIB_AMD64="abi1 abi2 abi3"
>   MULTILIB_PPC64="abi1 abi2 abi3"
> 
> with appropriate USE_EXPAND_HIDDEN set by profiles.
> 
> 
> What are your thoughts? Which arches would like to use multilib? What
> names for ABIs do you suggest?
> 

So you want to re-implement multilib-portage in an eclass without the
additional benefits a package-manager level implementation has?

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 3451 bytes --]

Sergei Trofimovich schrieb:
> On Sun, 20 Jan 2013 20:11:31 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
>> Hello,
>>
>> There is a fair interest in multilib and while still early, it would be
>> a good moment to decide on how USE flags to use for it.
>>
>> The current attempts are mostly using USE=multilib which is not really
>> expressive and poor. What I would go for is a clear variable specifying
>> which targets package is built for.
> 
> You just need to add 'ABI' and 'MULTILIB_ABIS' to
> "emerge --info ${pkg}" output.
> 
> Do you plan to keep precise depends for packages?
> like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.
> 
> What to do if someone builds a package only with non-default ABI?
> (it means installed package does not quite work for default ABI)
> 
> like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
> any of ABI=amd64 users.
> 
> In order to track such depends precisely you would need to add
> ABI flags to each revdep recursively. It's quite invasive. Is it worth
> the effort?
> 
> Currently USE=multilib means 'build for all toolchain-supported' ABIs.
> It looks clean and short.
> 
>> This raises the following questions:
>>
>> 1) do we want the default ABI to be switchable?
> It already is via /etc/portage/env per-package.
> Or via profile globally. arch/amd64/make.defaults:
>   MULTILIB_ABIS="amd64 x86"                                                                                
>   DEFAULT_ABI="amd64"
> 
> crossdev allows bootstrapping with any random default
> ABI out there as one-liner:
>     crossdev -A 'x32 amd64' x86_64-unknown-linux-gnu.
> 
>> 2) do we want irrelevant ABIs to be visible to emerge users?
>>
>> By 2) I mean: do we want the users to see stuff like:
>>
>>   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
>>     (-ppc64_abi2) (-ppc64_abi3) ..."
> 
> Would adding irrelevant ABIs trigger rebuilds on world update?
> 
> Do you intermingle gentoo's $ARCH and ABI?
> How many ABI vars do you expect to see for simple "common" cases?
> 
>   x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64)
>   x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64)
>   x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64)
>   i686-pc-linux-gnu-gcc -m32 (host ARCH=x86)
>   i686-pc-linux-gnu-gcc -m64 (host ARCH=x86)
>   i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86)
> 
> 3 or 6?
> 
> Looks like insane amount of metadata growth for each
> plagued package.
> 
>> or just the relevant part.
>>
>> To be honest, I don't know if there's other way to hide USE flags than
>> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
>> the flags per-arch, i.e. have:
>>
>>   MULTILIB_AMD64="abi1 abi2 abi3"
>>   MULTILIB_PPC64="abi1 abi2 abi3"
>>
>> with appropriate USE_EXPAND_HIDDEN set by profiles.
> 
> Having direct support in portage's core might reduce amount of
> user-visible/storable metadata in main tree. No slightest idea
> how it would look like though.
> 

Support for cross-compiling packages for toolchain-supported ABIs
already exists and works for some years in multilib-portage (code in the
multilib branch of portage git repo, ebuild in the multilib-portage
overlay with very basic setup instructions in the doc dir of the overlay
and the #gentoo-multilib-overlay channel in freenode for questions).

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

On Mon, 21 Jan 2013 00:01:05 +0100
Thomas Sachau <tommy@gentoo.org> wrote:

> Michał Górny schrieb:
> > Hello,
> > 
> > There is a fair interest in multilib and while still early, it would be
> > a good moment to decide on how USE flags to use for it.
> > 
> > The current attempts are mostly using USE=multilib which is not really
> > expressive and poor. What I would go for is a clear variable specifying
> > which targets package is built for.
> > 
> > 
> > This raises the following questions:
> > 
> > 1) do we want the default ABI to be switchable?
> > 
> > 2) do we want irrelevant ABIs to be visible to emerge users?
> > 
> > By 2) I mean: do we want the users to see stuff like:
> > 
> >   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
> >     (-ppc64_abi2) (-ppc64_abi3) ..."
> > 
> > or just the relevant part.
> > 
> > To be honest, I don't know if there's other way to hide USE flags than
> > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> > the flags per-arch, i.e. have:
> > 
> >   MULTILIB_AMD64="abi1 abi2 abi3"
> >   MULTILIB_PPC64="abi1 abi2 abi3"
> > 
> > with appropriate USE_EXPAND_HIDDEN set by profiles.
> > 
> > 
> > What are your thoughts? Which arches would like to use multilib? What
> > names for ABIs do you suggest?
> > 
> 
> So you want to re-implement multilib-portage in an eclass without the
> additional benefits a package-manager level implementation has?

Could you stay on topic, please?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit :
> Michał Górny schrieb:
> > Hello,
> > 
> > There is a fair interest in multilib and while still early, it would be
> > a good moment to decide on how USE flags to use for it.
> > 
> > The current attempts are mostly using USE=multilib which is not really
> > expressive and poor. What I would go for is a clear variable specifying
> > which targets package is built for.
> > 
> > 
> > This raises the following questions:
> > 
> > 1) do we want the default ABI to be switchable?
> > 
> > 2) do we want irrelevant ABIs to be visible to emerge users?
> > 
> > By 2) I mean: do we want the users to see stuff like:
> > 
> >   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
> >     (-ppc64_abi2) (-ppc64_abi3) ..."
> > 
> > or just the relevant part.
> > 
> > To be honest, I don't know if there's other way to hide USE flags than
> > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> > the flags per-arch, i.e. have:
> > 
> >   MULTILIB_AMD64="abi1 abi2 abi3"
> >   MULTILIB_PPC64="abi1 abi2 abi3"
> > 
> > with appropriate USE_EXPAND_HIDDEN set by profiles.
> > 
> > 
> > What are your thoughts? Which arches would like to use multilib? What
> > names for ABIs do you suggest?
> > 
> 
> So you want to re-implement multilib-portage in an eclass without the
> additional benefits a package-manager level implementation has?

Well that's the point of the eclass that was proposed a few days ago
allow building multiple ABIs. Having clear USE-dep like python-r1.eclass
is imho the way to go.

As said in another reply of this thread, USE=multilib really is a
solution that has its problems (no fine PM control for ABIs, slow
updates of emul-pkgs) to the current problem and portage-multilib, well
it's a subject that pops up from time to time I have no idea how and
will it will come nor do I have time to help on that front.

However this eclass would enable quick and easy per-ebuild support for
multiple ABIs just like python-r1 and friends, and this is a good thing
for every maintainer that wants to provide this kind of support. I know
I would, at least to get rid of the always lagging emul packages.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]

Gilles Dartiguelongue schrieb:
> Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit :
>> Michał Górny schrieb:
>>> Hello,
>>>
>>> There is a fair interest in multilib and while still early, it would be
>>> a good moment to decide on how USE flags to use for it.
>>>
>>> The current attempts are mostly using USE=multilib which is not really
>>> expressive and poor. What I would go for is a clear variable specifying
>>> which targets package is built for.
>>>
>>>
>>> This raises the following questions:
>>>
>>> 1) do we want the default ABI to be switchable?
>>>
>>> 2) do we want irrelevant ABIs to be visible to emerge users?
>>>
>>> By 2) I mean: do we want the users to see stuff like:
>>>
>>>   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
>>>     (-ppc64_abi2) (-ppc64_abi3) ..."
>>>
>>> or just the relevant part.
>>>
>>> To be honest, I don't know if there's other way to hide USE flags than
>>> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
>>> the flags per-arch, i.e. have:
>>>
>>>   MULTILIB_AMD64="abi1 abi2 abi3"
>>>   MULTILIB_PPC64="abi1 abi2 abi3"
>>>
>>> with appropriate USE_EXPAND_HIDDEN set by profiles.
>>>
>>>
>>> What are your thoughts? Which arches would like to use multilib? What
>>> names for ABIs do you suggest?
>>>
>>
>> So you want to re-implement multilib-portage in an eclass without the
>> additional benefits a package-manager level implementation has?
> 
> Well that's the point of the eclass that was proposed a few days ago
> allow building multiple ABIs. Having clear USE-dep like python-r1.eclass
> is imho the way to go.
> 
> As said in another reply of this thread, USE=multilib really is a
> solution that has its problems (no fine PM control for ABIs, slow
> updates of emul-pkgs) to the current problem and portage-multilib, well
> it's a subject that pops up from time to time I have no idea how and
> will it will come nor do I have time to help on that front.

multilib-portage exists and works for years, the problem usually is,
that posts about it are ignored until i write something about "planned
to ask council", which results in new requests to be fulfilled (for the
inclusion of this feature in the next EAPI). This could also get us rid
of USE=multilib and the emul packages. ;-)

> However this eclass would enable quick and easy per-ebuild support for
> multiple ABIs just like python-r1 and friends, and this is a good thing
> for every maintainer that wants to provide this kind of support. I know
> I would, at least to get rid of the always lagging emul packages.

As already written in another thread not long ago, the USE flag part
(shown USE flags per arch and USE flag dependencies) will be pretty hard
to implement at eclass level. So i will wait and see, if someone can
surprise me with a solution, that works as good as multilib-portage
without bad side effects or additional work for all sides.


-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Chí-Thanh Christopher Nguyễn]

Thomas Sachau schrieb:
> So you want to re-implement multilib-portage in an eclass without the additional benefits a
package-manager level implementation has?

Once the package-manager level implementation becomes available in g-x86
then we can switch to it. If something in the proposed changes makes the
PM implementation harder or causes additional work, please point this
out so it can be addressed.

Personally I wouldn't mind waiting until the next council meeting and
keep all changes in the x11 overlay until then.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Matt Turner]

On Sun, Jan 20, 2013 at 3:01 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> So you want to re-implement multilib-portage in an eclass without the
> additional benefits a package-manager level implementation has?

I really wish you'd just make the PMS diff and get your stuff
implemented. How long has it been?

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Alexis Ballier]

On Sun, 20 Jan 2013 20:11:31 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Hello,
> 
> There is a fair interest in multilib and while still early, it would
> be a good moment to decide on how USE flags to use for it.
> 
> The current attempts are mostly using USE=multilib which is not really
> expressive and poor. What I would go for is a clear variable
> specifying which targets package is built for.
> 
> 
> This raises the following questions:
> 
> 1) do we want the default ABI to be switchable?

I'd say no but I do not see any real problem with it.

> 2) do we want irrelevant ABIs to be visible to emerge users?
> 
> By 2) I mean: do we want the users to see stuff like:
> 
>   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
>     (-ppc64_abi2) (-ppc64_abi3) ..."
> 
> or just the relevant part.


just the relevant part, you'd probably need PM support here but showing
it all doesn't hurt, it's just less convenient.

> 
> To be honest, I don't know if there's other way to hide USE flags than
> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> the flags per-arch, i.e. have:
> 
>   MULTILIB_AMD64="abi1 abi2 abi3"
>   MULTILIB_PPC64="abi1 abi2 abi3"
> 
> with appropriate USE_EXPAND_HIDDEN set by profiles.

I don't like that at all.
I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there
is no name collision)
we certainly want skype to depend on libitneeds[abi_x86], not 'amd64?
( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )'


Alexis.

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Alexis Ballier]

On Sun, 20 Jan 2013 23:33:39 +0100
Michał Górny <mgorny@gentoo.org> wrote:

[...]
> > Do you plan to keep precise depends for packages?
> > like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.
> 
> Yes. ${MULTILIB_USEDEP} is for that (it currently evaluates
> to 'multilib?').

In that very precise case (gcc/glibc) I'd say no: it's probably saner
to leave the toolchain as it is, ie, able to build all supported abis.
It probably means an end to implicit system deps for the rest of the
system set though.

[...]
> > like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
> > any of ABI=amd64 users.
> > 
> > In order to track such depends precisely you would need to add
> > ABI flags to each revdep recursively. It's quite invasive. Is it
> > worth the effort?
> 
> A good point. I'd say that the default impl should be built then.
> But... how about making it a USE flag with use.force logic? That way,
> it would be explicitly visible, and if someone really wanted to
> disable it, he would be able to do it on his own responsibility.

+1

[...]
> > Looks like insane amount of metadata growth for each
> > plagued package.
> 
> I don't think metadata is really important here. I believe that
> the amount of additional metadata introduced by the packages affected
> by multilib is not really one worth worrying.
> 

+1 too
OTOH, if you don't have this metadata you cannot really distinguish
between packages needing multilib and those that do not care (I
wouldn't want to run texlive-latexextra src_* phases twice or three
times because I want multilib).

Alexis.

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

On Mon, 21 Jan 2013 10:27:30 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> > To be honest, I don't know if there's other way to hide USE flags than
> > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> > the flags per-arch, i.e. have:
> > 
> >   MULTILIB_AMD64="abi1 abi2 abi3"
> >   MULTILIB_PPC64="abi1 abi2 abi3"
> > 
> > with appropriate USE_EXPAND_HIDDEN set by profiles.
> 
> I don't like that at all.
> I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there
> is no name collision)

Well, there is one :).

> we certainly want skype to depend on libitneeds[abi_x86], not 'amd64?
> ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )'

Yes, that seems reasonable.

On the other hand, mips will most likely want some prefix with names
like 'n32' and 'n64'.

Well, I think I'll have to ping the arch teams to see what kinds
of multilib they want.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Mon, 21 Jan 2013 10:27:30 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> > To be honest, I don't know if there's other way to hide USE flags than
> > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> > the flags per-arch, i.e. have:
> > 
> >   MULTILIB_AMD64="abi1 abi2 abi3"
> >   MULTILIB_PPC64="abi1 abi2 abi3"
> > 
> > with appropriate USE_EXPAND_HIDDEN set by profiles.
> 
> I don't like that at all.
> I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there
> is no name collision)
> we certainly want skype to depend on libitneeds[abi_x86], not 'amd64?
> ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )'

Just a quick idea.

How would you feel about abi_x86_32? (similarly _64, _x32)

That would be almost natural names with the trick variable being
ABI_X86, therefore having all the fore-mentioned advantages.

The deps would look like:

  libitneeds[abi_x86_32]

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Alexis Ballier]

On Wed, 23 Jan 2013 09:24:26 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 21 Jan 2013 10:27:30 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > > To be honest, I don't know if there's other way to hide USE flags
> > > than using USE_EXPAND_HIDDEN. If we want to use that, we'd have
> > > to split the flags per-arch, i.e. have:
> > > 
> > >   MULTILIB_AMD64="abi1 abi2 abi3"
> > >   MULTILIB_PPC64="abi1 abi2 abi3"
> > > 
> > > with appropriate USE_EXPAND_HIDDEN set by profiles.
> > 
> > I don't like that at all.
> > I'd go for ABI= the union of all the MULTILIB_ABIS variables (if
> > there is no name collision)
> > we certainly want skype to depend on libitneeds[abi_x86], not
> > 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )'
> 
> Just a quick idea.
> 
> How would you feel about abi_x86_32? (similarly _64, _x32)
> 
> That would be almost natural names with the trick variable being
> ABI_X86, therefore having all the fore-mentioned advantages.
> 
> The deps would look like:
> 
>   libitneeds[abi_x86_32]
> 

Sounds good too, I just would want it to be shared between arches that
can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc.
You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ?
This would have all the benefits I think, very good idea :)

Alexis.

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

On Wed, 23 Jan 2013 08:03:56 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Wed, 23 Jan 2013 09:24:26 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Mon, 21 Jan 2013 10:27:30 -0300
> > Alexis Ballier <aballier@gentoo.org> wrote:
> > 
> > > > To be honest, I don't know if there's other way to hide USE flags
> > > > than using USE_EXPAND_HIDDEN. If we want to use that, we'd have
> > > > to split the flags per-arch, i.e. have:
> > > > 
> > > >   MULTILIB_AMD64="abi1 abi2 abi3"
> > > >   MULTILIB_PPC64="abi1 abi2 abi3"
> > > > 
> > > > with appropriate USE_EXPAND_HIDDEN set by profiles.
> > > 
> > > I don't like that at all.
> > > I'd go for ABI= the union of all the MULTILIB_ABIS variables (if
> > > there is no name collision)
> > > we certainly want skype to depend on libitneeds[abi_x86], not
> > > 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )'
> > 
> > Just a quick idea.
> > 
> > How would you feel about abi_x86_32? (similarly _64, _x32)
> > 
> > That would be almost natural names with the trick variable being
> > ABI_X86, therefore having all the fore-mentioned advantages.
> > 
> > The deps would look like:
> > 
> >   libitneeds[abi_x86_32]
> > 
> 
> Sounds good too, I just would want it to be shared between arches that
> can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc.
> You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ?
> This would have all the benefits I think, very good idea :)

Yes.

I'm currently looking for a clean way to hide it without having to
repeat that in a dozen profiles. But it seems that portage and PMS
disagree again about the shape of USE_EXPAND_HIDDEN...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

On Wed, 23 Jan 2013 16:27:17 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Wed, 23 Jan 2013 08:03:56 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Wed, 23 Jan 2013 09:24:26 +0100
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > On Mon, 21 Jan 2013 10:27:30 -0300
> > > Alexis Ballier <aballier@gentoo.org> wrote:
> > > 
> > > > > To be honest, I don't know if there's other way to hide USE flags
> > > > > than using USE_EXPAND_HIDDEN. If we want to use that, we'd have
> > > > > to split the flags per-arch, i.e. have:
> > > > > 
> > > > >   MULTILIB_AMD64="abi1 abi2 abi3"
> > > > >   MULTILIB_PPC64="abi1 abi2 abi3"
> > > > > 
> > > > > with appropriate USE_EXPAND_HIDDEN set by profiles.
> > > > 
> > > > I don't like that at all.
> > > > I'd go for ABI= the union of all the MULTILIB_ABIS variables (if
> > > > there is no name collision)
> > > > we certainly want skype to depend on libitneeds[abi_x86], not
> > > > 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )'
> > > 
> > > Just a quick idea.
> > > 
> > > How would you feel about abi_x86_32? (similarly _64, _x32)
> > > 
> > > That would be almost natural names with the trick variable being
> > > ABI_X86, therefore having all the fore-mentioned advantages.
> > > 
> > > The deps would look like:
> > > 
> > >   libitneeds[abi_x86_32]
> > > 
> > 
> > Sounds good too, I just would want it to be shared between arches that
> > can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc.
> > You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ?
> > This would have all the benefits I think, very good idea :)
> 
> Yes.
> 
> I'm currently looking for a clean way to hide it without having to
> repeat that in a dozen profiles. But it seems that portage and PMS
> disagree again about the shape of USE_EXPAND_HIDDEN...

Sorry, my bad. Read the wrong section of the well-organized PMS.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Alexey Shvetsov]

[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]

В письме от 23 января 2013 08:03:56 пользователь Alexis Ballier написал:
> On Wed, 23 Jan 2013 09:24:26 +0100
> 
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Mon, 21 Jan 2013 10:27:30 -0300
> > 
> > Alexis Ballier <aballier@gentoo.org> wrote:
> > > > To be honest, I don't know if there's other way to hide USE flags
> > > > than using USE_EXPAND_HIDDEN. If we want to use that, we'd have
> > > > 
> > > > to split the flags per-arch, i.e. have:
> > > >   MULTILIB_AMD64="abi1 abi2 abi3"
> > > >   MULTILIB_PPC64="abi1 abi2 abi3"
> > > > 
> > > > with appropriate USE_EXPAND_HIDDEN set by profiles.
> > > 
> > > I don't like that at all.
> > > I'd go for ABI= the union of all the MULTILIB_ABIS variables (if
> > > there is no name collision)
> > > we certainly want skype to depend on libitneeds[abi_x86], not
> > > 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )'
> > 
> > Just a quick idea.
> > 
> > How would you feel about abi_x86_32? (similarly _64, _x32)
> > 
> > That would be almost natural names with the trick variable being
> > ABI_X86, therefore having all the fore-mentioned advantages.
> > 
> > The deps would look like:
> >   libitneeds[abi_x86_32]
> 
> Sounds good too, I just would want it to be shared between arches that
> can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc.
> You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ?
> This would have all the benefits I think, very good idea :)
> 
> Alexis.

Shared abi names are bad idea. For example
mips abis : 
o32
n32
n64
eabi
x86:
x86_32
x86_x32
x86_64

Actualy first three one are equivalent in their internal behavior. But i dont 
think that its good idea to have one name for all. Think about multiarch 
installs where you can have binaries from different architectures in one 
system.
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

[-- Attachment #1.2: Type: text/html, Size: 12671 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Alexis Ballier]

On Wed, 23 Jan 2013 21:36:22 +0400
Alexey Shvetsov <alexxy@gentoo.org> wrote:

> В письме от 23 января 2013 08:03:56 пользователь Alexis Ballier
> написал:
> > On Wed, 23 Jan 2013 09:24:26 +0100
> > 
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > On Mon, 21 Jan 2013 10:27:30 -0300
> > > 
> > > Alexis Ballier <aballier@gentoo.org> wrote:
> > > > > To be honest, I don't know if there's other way to hide USE
> > > > > flags than using USE_EXPAND_HIDDEN. If we want to use that,
> > > > > we'd have
> > > > > 
> > > > > to split the flags per-arch, i.e. have:
> > > > >   MULTILIB_AMD64="abi1 abi2 abi3"
> > > > >   MULTILIB_PPC64="abi1 abi2 abi3"
> > > > > 
> > > > > with appropriate USE_EXPAND_HIDDEN set by profiles.
> > > > 
> > > > I don't like that at all.
> > > > I'd go for ABI= the union of all the MULTILIB_ABIS variables (if
> > > > there is no name collision)
> > > > we certainly want skype to depend on libitneeds[abi_x86], not
> > > > 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )'
> > > 
> > > Just a quick idea.
> > > 
> > > How would you feel about abi_x86_32? (similarly _64, _x32)
> > > 
> > > That would be almost natural names with the trick variable being
> > > ABI_X86, therefore having all the fore-mentioned advantages.
> > > 
> > > The deps would look like:
> > >   libitneeds[abi_x86_32]
> > 
> > Sounds good too, I just would want it to be shared between arches
> > that can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc.
> > You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ?
> > This would have all the benefits I think, very good idea :)
> > 
> > Alexis.
> 
> Shared abi names are bad idea. For example
> mips abis : 
> o32
> n32
> n64
> eabi
> x86:
> x86_32
> x86_x32
> x86_64
> 
> Actualy first three one are equivalent in their internal behavior.
> But i dont think that its good idea to have one name for all.

Sorry, I don't get it. What was meant here was one USE_EXPAND variable
per group of similar arches. Different abis are, of course,
distinguished within each variable.

> Think
> about multiarch installs where you can have binaries from different
> architectures in one system.

It depends what we want through multilib. I personally think multiarch
is out of scope: there is crossdev for that.

Alexis.