[gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Michał Górny]

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

Hi,

I'd like to give you a heads up and explanation on what I'm doing
today.

I'm in the process of converting emul-linux-x86-xlibs dependencies
in gx86 with any-of dependencies supporting both emul-linux and split
multilib packages.

The goal of that process is to allow peaceful co-existence of both
solutions while the migration work is being and a smooth transition
once it's done.

The common kind of committed dep now looks like:

  || (
    (
      x11-libs/libXfoo[abi_x86_32]
      x11-libs/libXbar[abi_x86_32]
    )
    app-emulation/emul-linux-x86-xlibs
  )

And before you ask -- it works better than I'd expect it to. Portage
just does the right thing depending on ABI_X86 setting. From my quick
(and not thorough tests), it even seems to handle switching
from emul-linux to multilib packages and back.

There are two notes however:

1. well, the deps aren't that 100% awesome in EAPI<5 with paludis. It
may not enforce USE-deps correctly, but a global ABI_X86 setting plus
@world rebuild will make it work fine. but anyway -- whenever possible,
please try to migrate packages to EAPI=5.

2. some of the binary packages may actually prefer versioned deps to
ensure matching SONAME.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Ciaran McCreesh]

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

On Sun, 21 Apr 2013 21:43:04 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> 1. well, the deps aren't that 100% awesome in EAPI<5 with paludis. It
> may not enforce USE-deps correctly, but a global ABI_X86 setting plus
> @world rebuild will make it work fine. but anyway -- whenever
> possible, please try to migrate packages to EAPI=5.

I would be interested to hear where you're getting "may not enforce
USE-deps correctly" from... Have you found a bug that we don't know
about, or do you mean "enforces USE dependencies when you don't want
it to", or "follows the spec when enforcing use dependencies", or
something like that?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Matt Turner]

On Sun, Apr 21, 2013 at 12:43 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Hi,
>
> I'd like to give you a heads up and explanation on what I'm doing
> today.
>
> I'm in the process of converting emul-linux-x86-xlibs dependencies
> in gx86 with any-of dependencies supporting both emul-linux and split
> multilib packages.

Awesome. Thank you so much for doing this.

I know you've spent a ton of time and effort on this (and also on all
of the discussions...) and I really want to thank you.

This is a serious improvement to Gentoo. Really nice work.

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Ben de Groot]

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

On 22 April 2013 03:43, Michał Górny <mgorny@gentoo.org> wrote:

> Hi,
>
> I'd like to give you a heads up and explanation on what I'm doing
> today.
>
> I'm in the process of converting emul-linux-x86-xlibs dependencies
> in gx86 with any-of dependencies supporting both emul-linux and split
> multilib packages.
>
> The goal of that process is to allow peaceful co-existence of both
> solutions while the migration work is being and a smooth transition
> once it's done.
>
> The common kind of committed dep now looks like:
>
>   || (
>     (
>       x11-libs/libXfoo[abi_x86_32]
>       x11-libs/libXbar[abi_x86_32]
>     )
>     app-emulation/emul-linux-x86-xlibs
>   )
>
> And before you ask -- it works better than I'd expect it to. Portage
> just does the right thing depending on ABI_X86 setting. From my quick
> (and not thorough tests), it even seems to handle switching
> from emul-linux to multilib packages and back.
>
> There are two notes however:
>
> 1. well, the deps aren't that 100% awesome in EAPI<5 with paludis. It
> may not enforce USE-deps correctly, but a global ABI_X86 setting plus
> @world rebuild will make it work fine. but anyway -- whenever possible,
> please try to migrate packages to EAPI=5.
>
> 2. some of the binary packages may actually prefer versioned deps to
> ensure matching SONAME.
>
> --
> Best regards,
> Michał Górny
>

It should come as no surprise that I am not happy with this. While I
applaud your efforts to attempt to improve the multilib situation, I don't
think we are quite at the stage yet where this can be pushed as the default
choice, as you are doing now.

In my opinion this belongs in an overlay for further development and much
more extensive testing. You are now pushing this to ebuilds that may very
well go stable within weeks — unless I'm missing something and you are
masking these features / useflags on stable.

I am also not convinced this is the approach to multilib that we should be
taking, and I know there are others for who this is controversial as well.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[-- Attachment #2: Type: text/html, Size: 2830 bytes --]

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Alexis Ballier]

On Mon, 22 Apr 2013 20:21:55 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> It should come as no surprise that I am not happy with this. While I
> applaud your efforts to attempt to improve the multilib situation, I
> don't think we are quite at the stage yet where this can be pushed as
> the default choice, as you are doing now.
> 
> In my opinion this belongs in an overlay for further development and
> much more extensive testing. You are now pushing this to ebuilds that
> may very well go stable within weeks — unless I'm missing something
> and you are masking these features / useflags on stable.

It is not default unless abi_x86_32 & friends are enabled; old
behavior is preserved until these flag are default in multilib profiles.
It is also not stable until the multilib deps are stable, which is
independent of packages having the || dep being stable. If there is a
need then useflags can be masked on stable also so that, again,
behavior remains the same on stable.

Alexis.

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Ben de Groot]

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

On 22 April 2013 21:51, Alexis Ballier <aballier@gentoo.org> wrote:

> On Mon, 22 Apr 2013 20:21:55 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
> > It should come as no surprise that I am not happy with this. While I
> > applaud your efforts to attempt to improve the multilib situation, I
> > don't think we are quite at the stage yet where this can be pushed as
> > the default choice, as you are doing now.
> >
> > In my opinion this belongs in an overlay for further development and
> > much more extensive testing. You are now pushing this to ebuilds that
> > may very well go stable within weeks — unless I'm missing something
> > and you are masking these features / useflags on stable.
>
> It is not default unless abi_x86_32 & friends are enabled; old
> behavior is preserved until these flag are default in multilib profiles.
> It is also not stable until the multilib deps are stable, which is
> independent of packages having the || dep being stable. If there is a
> need then useflags can be masked on stable also so that, again,
> behavior remains the same on stable.
>
> Alexis.
>

Alright, that wasn't immediately obvious. That does make these changes more
acceptable.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[-- Attachment #2: Type: text/html, Size: 1895 bytes --]

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Matt Turner]

On Mon, Apr 22, 2013 at 5:21 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 22 April 2013 03:43, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> Hi,
>>
>> I'd like to give you a heads up and explanation on what I'm doing
>> today.
>>
>> I'm in the process of converting emul-linux-x86-xlibs dependencies
>> in gx86 with any-of dependencies supporting both emul-linux and split
>> multilib packages.
>>
>> The goal of that process is to allow peaceful co-existence of both
>> solutions while the migration work is being and a smooth transition
>> once it's done.
>>
>> The common kind of committed dep now looks like:
>>
>>   || (
>>     (
>>       x11-libs/libXfoo[abi_x86_32]
>>       x11-libs/libXbar[abi_x86_32]
>>     )
>>     app-emulation/emul-linux-x86-xlibs
>>   )
>>
>> And before you ask -- it works better than I'd expect it to. Portage
>> just does the right thing depending on ABI_X86 setting. From my quick
>> (and not thorough tests), it even seems to handle switching
>> from emul-linux to multilib packages and back.
>>
>> There are two notes however:
>>
>> 1. well, the deps aren't that 100% awesome in EAPI<5 with paludis. It
>> may not enforce USE-deps correctly, but a global ABI_X86 setting plus
>> @world rebuild will make it work fine. but anyway -- whenever possible,
>> please try to migrate packages to EAPI=5.
>>
>> 2. some of the binary packages may actually prefer versioned deps to
>> ensure matching SONAME.
>>
>> --
>> Best regards,
>> Michał Górny
>
>
> It should come as no surprise that I am not happy with this. While I applaud
> your efforts to attempt to improve the multilib situation, I don't think we
> are quite at the stage yet where this can be pushed as the default choice,
> as you are doing now.
>
> In my opinion this belongs in an overlay for further development and much
> more extensive testing. You are now pushing this to ebuilds that may very
> well go stable within weeks — unless I'm missing something and you are
> masking these features / useflags on stable.
>
> I am also not convinced this is the approach to multilib that we should be
> taking, and I know there are others for who this is controversial as well.
>
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
> Gentoo Qt project lead, Gentoo Wiki admin

Do I assume correctly that this is a response to the freetype and
fontconfig multilib bugs?

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Ben de Groot]

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

On 22 April 2013 23:38, Matt Turner <mattst88@gentoo.org> wrote:

> Do I assume correctly that this is a response to the freetype and
> fontconfig multilib bugs?
>

This thread is not directly about that, but it is related.

I'm not convinced that this multilib solution is mature enough to be
pushed so speedily into the tree. But maybe I'm the only one...

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[-- Attachment #2: Type: text/html, Size: 887 bytes --]

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Pacho Ramos]

El mar, 23-04-2013 a las 01:03 +0800, Ben de Groot escribió:
> On 22 April 2013 23:38, Matt Turner <mattst88@gentoo.org> wrote:
>         Do I assume correctly that this is a response to the freetype
>         and
>         fontconfig multilib bugs?
> 
> 
> This thread is not directly about that, but it is related.
> 
> 
> I'm not convinced that this multilib solution is mature enough to be
> pushed so speedily into the tree. But maybe I'm the only one...
> 
> 
> -- 
> Cheers,
> 
> Ben | yngwin
> Gentoo developer
> Gentoo Qt project lead, Gentoo Wiki admin

I don't know why do you think that solution is not mature enough, what
specific problems are you *currently* hitting? I think mgorny already
handled the freetype problem with its headers

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Michał Górny]

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

On Mon, 22 Apr 2013 20:21:55 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 22 April 2013 03:43, Michał Górny <mgorny@gentoo.org> wrote:
> 
> > The common kind of committed dep now looks like:
> >
> >   || (
> >     (
> >       x11-libs/libXfoo[abi_x86_32]
> >       x11-libs/libXbar[abi_x86_32]
> >     )
> >     app-emulation/emul-linux-x86-xlibs
> >   )
>
> It should come as no surprise that I am not happy with this. While I
> applaud your efforts to attempt to improve the multilib situation, I don't
> think we are quite at the stage yet where this can be pushed as the default
> choice, as you are doing now.

This is an any-of dep, so it does not really change anything for
emul-linux users. I've taken specifically this approach to relax
the timeline for multilib attempt and allow testing it without the need
to enforce it on anyone.

> I am also not convinced this is the approach to multilib that we should be
> taking, and I know there are others for who this is controversial as well.

I'm afraid that so far the most negative opinions came from people
directly related to the portage-multilib project. While I value their
opinion, I'm afraid they are a little biased by the fact that we're
working on something alternate to their project, and which may cause
their work to end up mostly irrelevant.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Matt Turner]

On Mon, Apr 22, 2013 at 10:03 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 22 April 2013 23:38, Matt Turner <mattst88@gentoo.org> wrote:
>>
>> Do I assume correctly that this is a response to the freetype and
>> fontconfig multilib bugs?
>
>
> This thread is not directly about that, but it is related.
>
> I'm not convinced that this multilib solution is mature enough to be
> pushed so speedily into the tree. But maybe I'm the only one...

Many an email has been exchanged about the merits of this approach,
with a consensus reached and the work already done.

I think using your position as maintainer of these packages isn't a
good way to express your concerns.

Re: [gentoo-dev] FYI: emul-linux-x86-xlibs deps being replaced in gx86

[Thomas Sachau]

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

Michał Górny schrieb:
> On Mon, 22 Apr 2013 20:21:55 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
> 
>> On 22 April 2013 03:43, Michał Górny <mgorny@gentoo.org> wrote:
>>
>>> The common kind of committed dep now looks like:
>>>
>>>   || (
>>>     (
>>>       x11-libs/libXfoo[abi_x86_32]
>>>       x11-libs/libXbar[abi_x86_32]
>>>     )
>>>     app-emulation/emul-linux-x86-xlibs
>>>   )
>>
>> It should come as no surprise that I am not happy with this. While I
>> applaud your efforts to attempt to improve the multilib situation, I don't
>> think we are quite at the stage yet where this can be pushed as the default
>> choice, as you are doing now.
> 
> This is an any-of dep, so it does not really change anything for
> emul-linux users. I've taken specifically this approach to relax
> the timeline for multilib attempt and allow testing it without the need
> to enforce it on anyone.
> 
>> I am also not convinced this is the approach to multilib that we should be
>> taking, and I know there are others for who this is controversial as well.
> 
> I'm afraid that so far the most negative opinions came from people
> directly related to the portage-multilib project. While I value their
> opinion, I'm afraid they are a little biased by the fact that we're
> working on something alternate to their project, and which may cause
> their work to end up mostly irrelevant.
> 

Really, please stop spreading FUD.

Neither me as the maintainer of multilib-portage nor Steven as the
original author of the multilib-native eclass have been telling you to
stop your project, lied about you or insulted you personally (which i
sadly cannot say the reverse way).

The only situations, where you got negative feedback from me was in
cases you did something bad (like moving headers into the libdir causing
breakage for depending packages and additional work onto other maintainers).

Additionally, i already wrote, that i am ok with an eclass based
solution under certain conditions, so how you get to the conclusion,
that i am against it is probably your secret.

And finally, multilib-portage will still have its usecases if and when
your eclass based multilib suggestions get widely used, so the
irrelevance is again your personal view.

You partly duplicated my work and need to be pushed hard to also add the
features i have already developed and tested (like headers wrapping and
binary wrapping). So i am rather amused about your behaviour and
attitude to code/features already developed and tested in
multilib-portage then anything else. ;-)

-- 

Thomas Sachau
Gentoo Linux Developer


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