Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@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
On Wed, 23 Jan 2013 08:03:56 -0300 Alexis Ballier aball...@gentoo.org wrote: On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Wed, 23 Jan 2013 16:27:17 +0100 Michał Górny mgo...@gentoo.org wrote: On Wed, 23 Jan 2013 08:03:56 -0300 Alexis Ballier aball...@gentoo.org wrote: On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
В письме от 23 января 2013 08:03:56 пользователь Alexis Ballier написал: On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@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:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Wed, 23 Jan 2013 21:36:22 +0400 Alexey Shvetsov ale...@gentoo.org wrote: В письме от 23 января 2013 08:03:56 пользователь Alexis Ballier написал: On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@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.
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Sun, 20 Jan 2013 20:11:31 +0100 Michał Górny mgo...@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
On Sun, 20 Jan 2013 23:33:39 +0100
Michał Górny mgo...@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
On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Sun, 20 Jan 2013 20:11:31 +0100
Michał Górny mgo...@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
signature.asc
Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Mon, 21 Jan 2013 01:05:56 +0300
Sergei Trofimovich sly...@gentoo.org wrote:
On Sun, 20 Jan 2013 20:11:31 +0100
Michał Górny mgo...@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
signature.asc
Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
Sergei Trofimovich schrieb:
On Sun, 20 Jan 2013 20:11:31 +0100
Michał Górny mgo...@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
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Mon, 21 Jan 2013 00:01:05 +0100 Thomas Sachau to...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
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 e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
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
On Sun, Jan 20, 2013 at 3:01 PM, Thomas Sachau to...@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?
