El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 11:07:30 +0200
> Thomas Sachau <tommy@gentoo.org> wrote:
>
> > Matt Turner schrieb:
> > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > >> It is a simple eclass using autotools out-of-source builds to build
> > >> packages for multiple ABIs when multilib is supported.
> > >
> > > Thanks a lot, Michał! This looks good to me.
> > >
> > >> Use case: xorg packages, ask Matt.
> > >
> > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > WINE. The emul- packages aren't a very good solution for a number of
> > > reasons.
> > >
> > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > I realized that almost everything in x11-libs/ could be converted very
> > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > addition to emul-linux-x86-opengl.
> > >
> > >
> >
> > This looks like a shortened duplication of a subset of multilib-portage
> > features. While this wont hurt multilib-portage (since it does exclude
> > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > many ebuilds, which then again need another rewrite (or more likely
> > revert), when multilib-portage is accepted in a future EAPI.
>
> s/when/if/
>
> > So i would prefer some help/support with multilib-portage to get it
> > accepted sooner, instead of this additional workaround for a subset of
> > packages.
>
> I prefer the simpler solution.
>
> > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > and wine do use multilib-portage, so we already have a working solution
> > for this issue.
>
> They will no longer have to do that.
>

I would prefer if eclass way could be extended to packages not using
autotools too, otherwise, we will still need emul packages for, for
example, qt libs. If that would be possible via eclass, maybe
multilib-portage wouldn't be needed but, if not, we will still need it
and, then, would be nice if this inclussion for autotools packages
wouldn't cause more problems to get the "strong" solution land in the
"near" future :/

The simpler solution (eclass) looks fine to me, but it would need to be
extended to more packages than autotools based ones to let it replace
portage-multilib/emul packages

On Sun, 23 Sep 2012 12:33:58 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > On Sun, 23 Sep 2012 11:07:30 +0200
> > Thomas Sachau <tommy@gentoo.org> wrote:
> >
> > > Matt Turner schrieb:
> > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > >> It is a simple eclass using autotools out-of-source builds to build
> > > >> packages for multiple ABIs when multilib is supported.
> > > >
> > > > Thanks a lot, Michał! This looks good to me.
> > > >
> > > >> Use case: xorg packages, ask Matt.
> > > >
> > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > reasons.
> > > >
> > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > I realized that almost everything in x11-libs/ could be converted very
> > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > addition to emul-linux-x86-opengl.
> > > >
> > > >
> > >
> > > This looks like a shortened duplication of a subset of multilib-portage
> > > features. While this wont hurt multilib-portage (since it does exclude
> > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > many ebuilds, which then again need another rewrite (or more likely
> > > revert), when multilib-portage is accepted in a future EAPI.
> >
> > s/when/if/
> >
> > > So i would prefer some help/support with multilib-portage to get it
> > > accepted sooner, instead of this additional workaround for a subset of
> > > packages.
> >
> > I prefer the simpler solution.
> >
> > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > and wine do use multilib-portage, so we already have a working solution
> > > for this issue.
> >
> > They will no longer have to do that.
> >
>
> I would prefer if eclass way could be extended to packages not using
> autotools too, otherwise, we will still need emul packages for, for
> example, qt libs. If that would be possible via eclass, maybe
> multilib-portage wouldn't be needed but, if not, we will still need it
> and, then, would be nice if this inclussion for autotools packages
> wouldn't cause more problems to get the "strong" solution land in the
> "near" future :/
>
> The simpler solution (eclass) looks fine to me, but it would need to be
> extended to more packages than autotools based ones to let it replace
> portage-multilib/emul packages

Qt uses cmake, doesn't it?

I don't mind having cmake-multilib as well? We could probably move
the foreach_abi() function to some more common eclass, like multilib
eclass.

--
Best regards,
Michał Górny

On Sun, 23 Sep 2012 12:02:01 +0200
hasufell <hasufell@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/23/2012 11:56 AM, Michał Górny wrote:
> >> So i would prefer some help/support with multilib-portage to get
> >> it accepted sooner, instead of this additional workaround for a
> >> subset of packages.
> >
> > I prefer the simpler solution.
> >
>
> I prefer the stronger solution. This is just a quick workaround.

How is it stronger? By doing implicit magic on every ebuild?

--
Best regards,
Michał Górny

El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 12:33:58 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
>
> > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > > On Sun, 23 Sep 2012 11:07:30 +0200
> > > Thomas Sachau <tommy@gentoo.org> wrote:
> > >
> > > > Matt Turner schrieb:
> > > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > > >> It is a simple eclass using autotools out-of-source builds to build
> > > > >> packages for multiple ABIs when multilib is supported.
> > > > >
> > > > > Thanks a lot, Michał! This looks good to me.
> > > > >
> > > > >> Use case: xorg packages, ask Matt.
> > > > >
> > > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > > reasons.
> > > > >
> > > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > > I realized that almost everything in x11-libs/ could be converted very
> > > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > > addition to emul-linux-x86-opengl.
> > > > >
> > > > >
> > > >
> > > > This looks like a shortened duplication of a subset of multilib-portage
> > > > features. While this wont hurt multilib-portage (since it does exclude
> > > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > > many ebuilds, which then again need another rewrite (or more likely
> > > > revert), when multilib-portage is accepted in a future EAPI.
> > >
> > > s/when/if/
> > >
> > > > So i would prefer some help/support with multilib-portage to get it
> > > > accepted sooner, instead of this additional workaround for a subset of
> > > > packages.
> > >
> > > I prefer the simpler solution.
> > >
> > > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > > and wine do use multilib-portage, so we already have a working solution
> > > > for this issue.
> > >
> > > They will no longer have to do that.
> > >
> >
> > I would prefer if eclass way could be extended to packages not using
> > autotools too, otherwise, we will still need emul packages for, for
> > example, qt libs. If that would be possible via eclass, maybe
> > multilib-portage wouldn't be needed but, if not, we will still need it
> > and, then, would be nice if this inclussion for autotools packages
> > wouldn't cause more problems to get the "strong" solution land in the
> > "near" future :/
> >
> > The simpler solution (eclass) looks fine to me, but it would need to be
> > extended to more packages than autotools based ones to let it replace
> > portage-multilib/emul packages
>
> Qt uses cmake, doesn't it?
>
> I don't mind having cmake-multilib as well? We could probably move
> the foreach_abi() function to some more common eclass, like multilib
> eclass.
>

Looks interesting, yes, it uses cmake. I guess we would need to move all
packages needing 32bits libs to this eclasses. Are you sure wouldn't be
better to try to go to an "upper" level like Alexis Ballier suggested
some messages ago?:
"On Sat, 22 Sep 2012 23:24:46 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.
>

to some extent, can't you do the same by unpacking twice to different
$S and calling src_prepare/compile/install instead of their
autotools-utils counterpart with tweaked $S so that it works with almost
every ebuild ?

-- this really starts to resemble multilib portage "

That would be better as there are a ton of ebuilds not inheritting
autotools-utils.eclass even being autotools based (think for example in
gnome packages or many others)

On Sun, 23 Sep 2012 13:03:56 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> > On Sun, 23 Sep 2012 12:33:58 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> >
> > > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > > > On Sun, 23 Sep 2012 11:07:30 +0200
> > > > Thomas Sachau <tommy@gentoo.org> wrote:
> > > >
> > > > > Matt Turner schrieb:
> > > > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > > > >> It is a simple eclass using autotools out-of-source builds to build
> > > > > >> packages for multiple ABIs when multilib is supported.
> > > > > >
> > > > > > Thanks a lot, Michał! This looks good to me.
> > > > > >
> > > > > >> Use case: xorg packages, ask Matt.
> > > > > >
> > > > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > > > reasons.
> > > > > >
> > > > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > > > I realized that almost everything in x11-libs/ could be converted very
> > > > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > > > addition to emul-linux-x86-opengl.
> > > > > >
> > > > > >
> > > > >
> > > > > This looks like a shortened duplication of a subset of multilib-portage
> > > > > features. While this wont hurt multilib-portage (since it does exclude
> > > > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > > > many ebuilds, which then again need another rewrite (or more likely
> > > > > revert), when multilib-portage is accepted in a future EAPI.
> > > >
> > > > s/when/if/
> > > >
> > > > > So i would prefer some help/support with multilib-portage to get it
> > > > > accepted sooner, instead of this additional workaround for a subset of
> > > > > packages.
> > > >
> > > > I prefer the simpler solution.
> > > >
> > > > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > > > and wine do use multilib-portage, so we already have a working solution
> > > > > for this issue.
> > > >
> > > > They will no longer have to do that.
> > > >
> > >
> > > I would prefer if eclass way could be extended to packages not using
> > > autotools too, otherwise, we will still need emul packages for, for
> > > example, qt libs. If that would be possible via eclass, maybe
> > > multilib-portage wouldn't be needed but, if not, we will still need it
> > > and, then, would be nice if this inclussion for autotools packages
> > > wouldn't cause more problems to get the "strong" solution land in the
> > > "near" future :/
> > >
> > > The simpler solution (eclass) looks fine to me, but it would need to be
> > > extended to more packages than autotools based ones to let it replace
> > > portage-multilib/emul packages
> >
> > Qt uses cmake, doesn't it?
> >
> > I don't mind having cmake-multilib as well? We could probably move
> > the foreach_abi() function to some more common eclass, like multilib
> > eclass.
> >
>
> Looks interesting, yes, it uses cmake. I guess we would need to move all
> packages needing 32bits libs to this eclasses. Are you sure wouldn't be
> better to try to go to an "upper" level like Alexis Ballier suggested
> some messages ago?:
> "On Sat, 22 Sep 2012 23:24:46 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > It is a simple eclass using autotools out-of-source builds to build
> > packages for multiple ABIs when multilib is supported.
> >
>
> to some extent, can't you do the same by unpacking twice to different
> $S and calling src_prepare/compile/install instead of their
> autotools-utils counterpart with tweaked $S so that it works with almost
> every ebuild ?
>
> -- this really starts to resemble multilib portage "
>
> That would be better as there are a ton of ebuilds not inheritting
> autotools-utils.eclass even being autotools based (think for example in
> gnome packages or many others)

You could fix those ebuilds to inherit it too . autotools-utils was
especially designed to use out-of-source builds for multilib
in the future.

I'm afraid the 'upper level' is technically impossible without either
going into PM itself (which means waiting for EAPI 6 at least
and getting some scary logic into it) or reinventing the phases alike
ruby-ng/python-distutils-ng. Well, the latter may be useful to some
degree; still, it would require each ebuild to redefine all phases.

--
Best regards,
Michał Górny

El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 13:03:56 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
>
> > El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> > > On Sun, 23 Sep 2012 12:33:58 +0200
> > > Pacho Ramos <pacho@gentoo.org> wrote:
> > >
> > > > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > > > > On Sun, 23 Sep 2012 11:07:30 +0200
> > > > > Thomas Sachau <tommy@gentoo.org> wrote:
> > > > >
> > > > > > Matt Turner schrieb:
> > > > > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > > > > >> It is a simple eclass using autotools out-of-source builds to build
> > > > > > >> packages for multiple ABIs when multilib is supported.
> > > > > > >
> > > > > > > Thanks a lot, Michał! This looks good to me.
> > > > > > >
> > > > > > >> Use case: xorg packages, ask Matt.
> > > > > > >
> > > > > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > > > > reasons.
> > > > > > >
> > > > > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > > > > I realized that almost everything in x11-libs/ could be converted very
> > > > > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > > > > addition to emul-linux-x86-opengl.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > This looks like a shortened duplication of a subset of multilib-portage
> > > > > > features. While this wont hurt multilib-portage (since it does exclude
> > > > > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > > > > many ebuilds, which then again need another rewrite (or more likely
> > > > > > revert), when multilib-portage is accepted in a future EAPI.
> > > > >
> > > > > s/when/if/
> > > > >
> > > > > > So i would prefer some help/support with multilib-portage to get it
> > > > > > accepted sooner, instead of this additional workaround for a subset of
> > > > > > packages.
> > > > >
> > > > > I prefer the simpler solution.
> > > > >
> > > > > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > > > > and wine do use multilib-portage, so we already have a working solution
> > > > > > for this issue.
> > > > >
> > > > > They will no longer have to do that.
> > > > >
> > > >
> > > > I would prefer if eclass way could be extended to packages not using
> > > > autotools too, otherwise, we will still need emul packages for, for
> > > > example, qt libs. If that would be possible via eclass, maybe
> > > > multilib-portage wouldn't be needed but, if not, we will still need it
> > > > and, then, would be nice if this inclussion for autotools packages
> > > > wouldn't cause more problems to get the "strong" solution land in the
> > > > "near" future :/
> > > >
> > > > The simpler solution (eclass) looks fine to me, but it would need to be
> > > > extended to more packages than autotools based ones to let it replace
> > > > portage-multilib/emul packages
> > >
> > > Qt uses cmake, doesn't it?
> > >
> > > I don't mind having cmake-multilib as well? We could probably move
> > > the foreach_abi() function to some more common eclass, like multilib
> > > eclass.
> > >
> >
> > Looks interesting, yes, it uses cmake. I guess we would need to move all
> > packages needing 32bits libs to this eclasses. Are you sure wouldn't be
> > better to try to go to an "upper" level like Alexis Ballier suggested
> > some messages ago?:
> > "On Sat, 22 Sep 2012 23:24:46 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> > > It is a simple eclass using autotools out-of-source builds to build
> > > packages for multiple ABIs when multilib is supported.
> > >
> >
> > to some extent, can't you do the same by unpacking twice to different
> > $S and calling src_prepare/compile/install instead of their
> > autotools-utils counterpart with tweaked $S so that it works with almost
> > every ebuild ?
> >
> > -- this really starts to resemble multilib portage "
> >
> > That would be better as there are a ton of ebuilds not inheritting
> > autotools-utils.eclass even being autotools based (think for example in
> > gnome packages or many others)
>
> You could fix those ebuilds to inherit it too . autotools-utils was
> especially designed to use out-of-source builds for multilib
> in the future.
>
> I'm afraid the 'upper level' is technically impossible without either
> going into PM itself (which means waiting for EAPI 6 at least
> and getting some scary logic into it) or reinventing the phases alike
> ruby-ng/python-distutils-ng. Well, the latter may be useful to some
> degree; still, it would require each ebuild to redefine all phases.
>

Then, I think that main blocker to use autotools-utils.eclass more
widely is that it needs at least eapi2, then, I am unsure if all
packages currently shipped in emul packages could bump their eapi due
compat with old systems.

Pacho Ramos schrieb:
> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
>> On Sun, 23 Sep 2012 11:07:30 +0200
>> Thomas Sachau <tommy@gentoo.org> wrote:
>>
>>> Matt Turner schrieb:
>>>> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>>>> It is a simple eclass using autotools out-of-source builds to build
>>>>> packages for multiple ABIs when multilib is supported.
>>>>
>>>> Thanks a lot, Michał! This looks good to me.
>>>>
>>>>> Use case: xorg packages, ask Matt.
>>>>
>>>> So the idea is that users want up-to-date 32-bit drivers for games and
>>>> WINE. The emul- packages aren't a very good solution for a number of
>>>> reasons.
>>>>
>>>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
>>>> I realized that almost everything in x11-libs/ could be converted very
>>>> easily, which would allow us to get rid of emul-linux-x86-xlibs in
>>>> addition to emul-linux-x86-opengl.
>>>>
>>>>
>>>
>>> This looks like a shortened duplication of a subset of multilib-portage
>>> features. While this wont hurt multilib-portage (since it does exclude
>>> most actions on ebuilds with USE=multilib), it will mean a rewrite for
>>> many ebuilds, which then again need another rewrite (or more likely
>>> revert), when multilib-portage is accepted in a future EAPI.
>>
>> s/when/if/
>>
>>> So i would prefer some help/support with multilib-portage to get it
>>> accepted sooner, instead of this additional workaround for a subset of
>>> packages.
>>
>> I prefer the simpler solution.
>>
>>> P.S.: I know, that users, who want up-to-date 32bit drivers for games
>>> and wine do use multilib-portage, so we already have a working solution
>>> for this issue.
>>
>> They will no longer have to do that.
>>
>
> I would prefer if eclass way could be extended to packages not using
> autotools too, otherwise, we will still need emul packages for, for
> example, qt libs. If that would be possible via eclass, maybe
> multilib-portage wouldn't be needed but, if not, we will still need it
> and, then, would be nice if this inclussion for autotools packages
> wouldn't cause more problems to get the "strong" solution land in the
> "near" future :/
>
> The simpler solution (eclass) looks fine to me, but it would need to be
> extended to more packages than autotools based ones to let it replace
> portage-multilib/emul packages
>

you mean something like this one?

https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass

That was the original eclass allowing cross-compile support, but
required ebuilds to inherit it. multilib-portage is based on this, but
does not require to modify the ebuilds themselves.

--

Thomas Sachau
Gentoo Linux Developer

On Sun, 23 Sep 2012 13:30:41 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió:
> > On Sun, 23 Sep 2012 13:03:56 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> >
> > > That would be better as there are a ton of ebuilds not inheritting
> > > autotools-utils.eclass even being autotools based (think for example in
> > > gnome packages or many others)
> >
> > You could fix those ebuilds to inherit it too . autotools-utils was
> > especially designed to use out-of-source builds for multilib
> > in the future.
> >
> > I'm afraid the 'upper level' is technically impossible without either
> > going into PM itself (which means waiting for EAPI 6 at least
> > and getting some scary logic into it) or reinventing the phases alike
> > ruby-ng/python-distutils-ng. Well, the latter may be useful to some
> > degree; still, it would require each ebuild to redefine all phases.
> >
>
> Then, I think that main blocker to use autotools-utils.eclass more
> widely is that it needs at least eapi2, then, I am unsure if all
> packages currently shipped in emul packages could bump their eapi due
> compat with old systems.

I doubt that is an important problem anymore, considering that portage
requires at least EAPI 2 (and some ebuilds use EAPI 3 already).

--
Best regards,
Michał Górny

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/23/2012 12:40 PM, Michał Górny wrote:
> On Sun, 23 Sep 2012 12:02:01 +0200 hasufell <hasufell@gentoo.org>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 09/23/2012 11:56 AM, Michał Górny wrote:
>>>> So i would prefer some help/support with multilib-portage to
>>>> get it accepted sooner, instead of this additional workaround
>>>> for a subset of packages.
>>>
>>> I prefer the simpler solution.
>>>
>>
>> I prefer the stronger solution. This is just a quick workaround.
>
> How is it stronger? By doing implicit magic on every ebuild?
>

a) does not involve modifying ebuilds
b) works in a larger scale
c) is tested and developed for quite some time
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQXvsmAAoJEFpvPKfnPDWzZAcH/11b4Wng7f+nyDpbFQhanpLW
56mQy4IGmEvmEqgrYyBPLtnXWh+BtNu+j0ogS8hNMxsVXvDw6H vJGbeXwebcQ6VY
OQS5l0IZvK9Zz+H4wm+ACv1i6fWPG9nRuMg8phRwfnq0jMIIF2 lP1nll5T/2QYU/
fvPxiweKca9id4hozc0C0319vpVjEoX9a8/dBh6JXGNlzPq54bf7+6qep8O7mWGo
9bKXkoobwd22wUnBajcOFg4mbMu7cnKsTn0PhQBXo2+tEV5Mhg ugGe8USq99u8xA
CQVVRcdbjyQZW90W8c0/Dniq8LMcTY6xoKmH5a2vG0dpHahYtKtCZ2sTruxgppc=
=KNcl
-----END PGP SIGNATURE-----

El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió:
> Pacho Ramos schrieb:
> > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> >> On Sun, 23 Sep 2012 11:07:30 +0200
> >> Thomas Sachau <tommy@gentoo.org> wrote:
> >>
> >>> Matt Turner schrieb:
> >>>> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> >>>>> It is a simple eclass using autotools out-of-source builds to build
> >>>>> packages for multiple ABIs when multilib is supported.
> >>>>
> >>>> Thanks a lot, Michał! This looks good to me.
> >>>>
> >>>>> Use case: xorg packages, ask Matt.
> >>>>
> >>>> So the idea is that users want up-to-date 32-bit drivers for games and
> >>>> WINE. The emul- packages aren't a very good solution for a number of
> >>>> reasons.
> >>>>
> >>>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
> >>>> I realized that almost everything in x11-libs/ could be converted very
> >>>> easily, which would allow us to get rid of emul-linux-x86-xlibs in
> >>>> addition to emul-linux-x86-opengl.
> >>>>
> >>>>
> >>>
> >>> This looks like a shortened duplication of a subset of multilib-portage
> >>> features. While this wont hurt multilib-portage (since it does exclude
> >>> most actions on ebuilds with USE=multilib), it will mean a rewrite for
> >>> many ebuilds, which then again need another rewrite (or more likely
> >>> revert), when multilib-portage is accepted in a future EAPI.
> >>
> >> s/when/if/
> >>
> >>> So i would prefer some help/support with multilib-portage to get it
> >>> accepted sooner, instead of this additional workaround for a subset of
> >>> packages.
> >>
> >> I prefer the simpler solution.
> >>
> >>> P.S.: I know, that users, who want up-to-date 32bit drivers for games
> >>> and wine do use multilib-portage, so we already have a working solution
> >>> for this issue.
> >>
> >> They will no longer have to do that.
> >>
> >
> > I would prefer if eclass way could be extended to packages not using
> > autotools too, otherwise, we will still need emul packages for, for
> > example, qt libs. If that would be possible via eclass, maybe
> > multilib-portage wouldn't be needed but, if not, we will still need it
> > and, then, would be nice if this inclussion for autotools packages
> > wouldn't cause more problems to get the "strong" solution land in the
> > "near" future :/
> >
> > The simpler solution (eclass) looks fine to me, but it would need to be
> > extended to more packages than autotools based ones to let it replace
> > portage-multilib/emul packages
> >
>
> you mean something like this one?
>
> https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass
>
> That was the original eclass allowing cross-compile support, but
> required ebuilds to inherit it. multilib-portage is based on this, but
> does not require to modify the ebuilds themselves.
>

Yes, that is what I meant... but I don't find hard to modify ebuilds to
inherit it :/