[gentoo-dev] multilib amd64 news item for review

[gentoo-dev] multilib amd64 news item for review

[Michał Górny]

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

Hello, everyone.

Here's the first draft of news item for gx86-multilib. I tried to cover
all the important aspects. Please review and let me know what you think.


Title: True multilib support on amd64
Author: Michał Górny <mgorny@gentoo.org>
Content-Type: text/plain
Posted: 2015-01-28
Revision: 1
News-Item-Format: 1.0
Display-If-Keyword: amd64
Display-If-Keyword: ~amd64

Starting with 2015-03-29, we are enabling the true multilib support
on amd64 and masking the old emul-linux-x86 package sets for removal.
This change provides our users with the opportunity to build 32-bit
libraries from source with all the flexibility given by ebuilds, rather
than relying on pre-packaged binary versions of them.

The switch to the new system is likely to require a specific action from
the users of our multilib profiles. Since the new system collides with
the old one, the Package Manager must be able to clearly satisfy all
the dependencies using the new system in order to proceed. This may
require unmerging packages installed from third-party repositories that
have not been updated to support the new system.

In order to enable building necessary 32-bit libraries, users will be
required to enable the abi_x86_32 USE flag on respective packages.
In most of the cases, Portage will be able to deliver correct
suggestions for that when using the --autounmask feature. However, some
users may prefer setting ABI_X86 globally to enable 32-bit libraries
in all packages supporting building them.

In case of issues, blockers especially, the users users are recommended
to manually uninstall any emul-linux-x86 packages that may have been
installed on their systems. This will aid the Package Manager
in choosing the correct dependency resolution path. If using Portage,
this can be done using the following command:

    $ emerge -C 'app-emulation/emul-linux-x86*'

Note that after performing this step, 32-bit applications on your system
may become temporarily broken. Therefore, this step should be followed
by a @world upgrade immediately.


-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] multilib amd64 news item for review

[Alex Xu]

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

On 15/03/15 10:11 AM, Michał Górny wrote:
> In case of issues, blockers especially, the users users are recommended

looks OK otherwise.


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

Re: [gentoo-dev] multilib amd64 news item for review

[Ulrich Mueller]

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

>>>>> On Sun, 15 Mar 2015, Michał Górny wrote:

> Hello, everyone. Here's the first draft of news item for
> gx86-multilib. I tried to cover all the important aspects. Please
> review and let me know what you think.

> Title: True multilib support on amd64
> Author: Michał Górny <mgorny@gentoo.org>
> Content-Type: text/plain
> Posted: 2015-01-28
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Keyword: amd64
> Display-If-Keyword: ~amd64

Users of no-multilib profiles won't be affected, so maybe
Display-If-Profile should be used (in addition, or instead of
Display-If-Keyword)?

> Starting with 2015-03-29, we are enabling the true multilib support
> on amd64 and masking the old emul-linux-x86 package sets for removal.
> This change provides

I'm not a native speaker, but shouldn't a future tense be used here?

>                      our users with the opportunity to build 32-bit
> libraries from source with all the flexibility given by ebuilds, rather
> than relying on pre-packaged binary versions of them.

> The switch to the new system is likely to require a specific action from
> the users of our multilib profiles. Since the new system collides with
> the old one, the Package Manager must be able to clearly satisfy all
> the dependencies using the new system in order to proceed. This may
> require unmerging packages installed from third-party repositories that
> have not been updated to support the new system.

> In order to enable building necessary 32-bit libraries, users will be
> required to enable the abi_x86_32 USE flag on respective packages.

How? Maybe add a hint that this should be done in package.accept_keywords?

> In most of the cases, Portage will be able to deliver correct
> suggestions for that when using the --autounmask feature. However, some
> users may prefer setting ABI_X86 globally to enable 32-bit libraries
> in all packages supporting building them.

Again, add a hint how to do this?

> In case of issues, blockers especially, the users users

s/the users users/users/

>                                                         are recommended
> to manually uninstall any emul-linux-x86 packages that may have been
> installed on their systems. This will aid the Package Manager
> in choosing the correct dependency resolution path. If using Portage,
> this can be done using the following command:

>     $ emerge -C 'app-emulation/emul-linux-x86*'

> Note that after performing this step, 32-bit applications on your system

So far you have used third person throughout, so avoid the "your"
here.

> may become temporarily broken. Therefore, this step should be followed
> by a @world upgrade immediately.

Maybe a pointer to the wiki could be added? How about this:
https://wiki.gentoo.org/wiki/Multilib_System_without_emul-linux_Packages
(with that page being updated if necessary).

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] multilib amd64 news item for review

[Rich Freeman]

On Sun, Mar 15, 2015 at 10:43 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Sun, 15 Mar 2015, Michał Górny wrote:
>
>> Starting with 2015-03-29, we are enabling the true multilib support
>> on amd64 and masking the old emul-linux-x86 package sets for removal.
>> This change provides
>
> I'm not a native speaker, but shouldn't a future tense be used here?
>
>>                      our users with the opportunity to build 32-bit
>> libraries from source with all the flexibility given by ebuilds, rather
>> than relying on pre-packaged binary versions of them.
>

I suggest:

Starting on 2015-03-29, we are enabling true multilib support
on amd64 and masking the old emul-linux-x86 package sets for removal.
This change provides our users with the opportunity to build 32-bit
libraries from source with all the flexibility given by ebuilds, rather
than relying on pre-packaged binary versions of them.

I just changed "with" to "on" and dropped a "the."  I think this
sounds fairly natural - a grammar nazi might disagree, but I'd rate
the paragraph above average for a native born American college
graduate.  (Granted, that isn't saying a whole lot).  Without those
tweaks I'd say it is still better than a lot of stuff that passes for
prose these days.  :)

Trust me, you don't want to see my attempts at German, so I'll be the
last to critique anybody's use of English (American or otherwise)...

--
Rich

Re: [gentoo-dev] multilib amd64 news item for review

[Ben de Groot]

On 15 March 2015 at 22:43, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Sun, 15 Mar 2015, Michał Górny wrote:
>
>> Hello, everyone. Here's the first draft of news item for
>> gx86-multilib. I tried to cover all the important aspects. Please
>> review and let me know what you think.
>
>> Title: True multilib support on amd64
>> Author: Michał Górny <mgorny@gentoo.org>
>> Content-Type: text/plain
>> Posted: 2015-01-28
>> Revision: 1
>> News-Item-Format: 1.0
>> Display-If-Keyword: amd64
>> Display-If-Keyword: ~amd64
>
> Users of no-multilib profiles won't be affected, so maybe
> Display-If-Profile should be used (in addition, or instead of
> Display-If-Keyword)?
>
>> Starting with 2015-03-29, we are enabling the true multilib support
>> on amd64 and masking the old emul-linux-x86 package sets for removal.
>> This change provides
>
> I'm not a native speaker, but shouldn't a future tense be used here?

English teacher here: no. The present continuous ("are enabling") is a
normal way to express the future in English.
The only changes necessary here, as already noted, is changing 'with'
to 'on' before the date, and dropping 'the' before true.

It may be nice to specify *stable* amd64. I would also say that 'true'
is incorrect, as the emul packages were also truly multilib, just
implemented in a different way. Maybe 'eclass-based' is more specific
and less opinionated?

>>                      our users with the opportunity to build 32-bit
>> libraries from source with all the flexibility given by ebuilds, rather
>> than relying on pre-packaged binary versions of them.
> [...]
>> installed on their systems. This will aid the Package Manager
>> in choosing the correct dependency resolution path. If using Portage,
>> this can be done using the following command:
>
>>     $ emerge -C 'app-emulation/emul-linux-x86*'
>
>> Note that after performing this step, 32-bit applications on your system
>
> So far you have used third person throughout, so avoid the "your"
> here.

I agree. Maybe 'that'?

-- 
Cheers,

Ben | yngwin
Gentoo developer

[gentoo-dev] Re: multilib amd64 news item for review

[Duncan]

Ben de Groot posted on Mon, 16 Mar 2015 00:25:08 +0800 as excerpted:

> I would also say that 'true'
> is incorrect, as the emul packages were also truly multilib, just
> implemented in a different way. Maybe 'eclass-based' is more specific
> and less opinionated?

"Gentoo style build-from-sources"?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] multilib amd64 news item for review

[Michał Górny]

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

Dnia 2015-03-15, o godz. 15:43:56
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Sun, 15 Mar 2015, Michał Górny wrote:
> 
> > Hello, everyone. Here's the first draft of news item for
> > gx86-multilib. I tried to cover all the important aspects. Please
> > review and let me know what you think.
> 
> > Title: True multilib support on amd64
> > Author: Michał Górny <mgorny@gentoo.org>
> > Content-Type: text/plain
> > Posted: 2015-01-28
> > Revision: 1
> > News-Item-Format: 1.0
> > Display-If-Keyword: amd64
> > Display-If-Keyword: ~amd64
> 
> Users of no-multilib profiles won't be affected, so maybe
> Display-If-Profile should be used (in addition, or instead of
> Display-If-Keyword)?

Display-If-Profile does exact profile matching, so we'd have to keep
an up-to-date list of all profiles derived from multilib amd64...

> > Starting with 2015-03-29, we are enabling the true multilib support
> > on amd64 and masking the old emul-linux-x86 package sets for removal.
> > This change provides
> 
> I'm not a native speaker, but shouldn't a future tense be used here?
> 
> >                      our users with the opportunity to build 32-bit
> > libraries from source with all the flexibility given by ebuilds, rather
> > than relying on pre-packaged binary versions of them.
> 
> > The switch to the new system is likely to require a specific action from
> > the users of our multilib profiles. Since the new system collides with
> > the old one, the Package Manager must be able to clearly satisfy all
> > the dependencies using the new system in order to proceed. This may
> > require unmerging packages installed from third-party repositories that
> > have not been updated to support the new system.
> 
> > In order to enable building necessary 32-bit libraries, users will be
> > required to enable the abi_x86_32 USE flag on respective packages.
> 
> How? Maybe add a hint that this should be done in package.accept_keywords?

It can't :P. But added a hint for package.use.

> > In most of the cases, Portage will be able to deliver correct
> > suggestions for that when using the --autounmask feature. However, some
> > users may prefer setting ABI_X86 globally to enable 32-bit libraries
> > in all packages supporting building them.
> 
> Again, add a hint how to do this?

Likewise.

> > In case of issues, blockers especially, the users users
> 
> s/the users users/users/

Fixed.

> >                                                         are recommended
> > to manually uninstall any emul-linux-x86 packages that may have been
> > installed on their systems. This will aid the Package Manager
> > in choosing the correct dependency resolution path. If using Portage,
> > this can be done using the following command:
> 
> >     $ emerge -C 'app-emulation/emul-linux-x86*'
> 
> > Note that after performing this step, 32-bit applications on your system
> 
> So far you have used third person throughout, so avoid the "your"
> here.

Fixed.

> 
> > may become temporarily broken. Therefore, this step should be followed
> > by a @world upgrade immediately.
> 
> Maybe a pointer to the wiki could be added? How about this:
> https://wiki.gentoo.org/wiki/Multilib_System_without_emul-linux_Packages
> (with that page being updated if necessary).

If someone has time to uncruft that wiki page, I'd be happy to link it.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] multilib amd64 news item for review

[Ulrich Mueller]

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

>>>>> On Tue, 17 Mar 2015, Michał Górny wrote:

>> Users of no-multilib profiles won't be affected, so maybe
>> Display-If-Profile should be used (in addition, or instead of
>> Display-If-Keyword)?

> Display-If-Profile does exact profile matching, so we'd have to keep
> an up-to-date list of all profiles derived from multilib amd64...

Indeed, that might be too much effort. Show it to all amd64 users then.

>> How? Maybe add a hint that this should be done in package.accept_keywords?

> It can't :P. But added a hint for package.use.

That's what I meant, of course. :)

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] multilib amd64 news item for review

[Michał Górny]

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

Dnia 2015-03-15, o godz. 15:11:47
Michał Górny <mgorny@gentoo.org> napisał(a):

> Hello, everyone.
> 
> Here's the first draft of news item for gx86-multilib. I tried to cover
> all the important aspects. Please review and let me know what you think.

Here's -r1:

Title: True multilib support on amd64
Author: Michał Górny <mgorny@gentoo.org>
Content-Type: text/plain
Posted: 2015-01-28
Revision: 1
News-Item-Format: 1.0
Display-If-Keyword: amd64
Display-If-Keyword: ~amd64

Starting on 2015-03-29, we are enabling true multilib support on amd64
and masking the old emul-linux-x86 package sets for removal. This
change provides our users with the opportunity to build 32-bit libraries
from source with all the flexibility given by ebuilds and the security
of using mainline ebuilds, rather than relying on pre-packaged binary
versions of them.

The switch to the new system is likely to require a specific action from
the users of our multilib profiles. Since the new system collides with
the old one, the Package Manager must be able to clearly satisfy all
the dependencies using the new system in order to proceed. This may
require unmerging packages installed from third-party repositories that
have not been updated to support the new system.

In order to enable building necessary 32-bit libraries, users will be
required to enable the abi_x86_32 USE flag on respective packages.
This can be done using /etc/portage/package.use entries alike
the following:

    sys-libs/zlib abi_x86_32

In most of the cases, Portage will be able to deliver correct
suggestions for that when using the --autounmask feature. However, some
users may prefer setting ABI_X86 globally to enable 32-bit libraries
in all packages that support building them. This can be done using
the following package.use entry:

    */* abi_x86_32

In case of issues, blockers especially, users are recommended
to manually uninstall any emul-linux-x86 packages that may have been
installed on their systems. This will aid the Package Manager
in choosing the correct dependency resolution path. If using Portage,
this can be done using the following command:

    $ emerge -C 'app-emulation/emul-linux-x86*'

Note that after performing this step, 32-bit applications on user's
system may become temporarily broken. Therefore, this step should be
followed by a @world upgrade immediately.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] multilib amd64 news item for review

[René Neumann]

Am 17.03.2015 um 16:33 schrieb Michał Górny:
>  However, some
> users may prefer setting ABI_X86 globally to enable 32-bit libraries
> in all packages that support building them. This can be done using
> the following package.use entry:
>
>      */* abi_x86_32
>

I'm confused: Has this a different semantics from adding 
USE+='abi_x86_32' to make.conf? If no, why mention this strange way 
(which is new to me) for setting default global useflags.

And to bring this even further: Wouldn't the nicest approach to add
   ABI_X86="32"
or
   ABI_X86="32 64"
to make.conf? (With the latter being more descriptive, as the first one 
might suggest that _only_ 32bit should be built).

- René

Re: [gentoo-dev] multilib amd64 news item for review

[Michał Górny]

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

Dnia 2015-03-17, o godz. 16:55:32
René Neumann <lists@necoro.eu> napisał(a):

> Am 17.03.2015 um 16:33 schrieb Michał Górny:
> >  However, some
> > users may prefer setting ABI_X86 globally to enable 32-bit libraries
> > in all packages that support building them. This can be done using
> > the following package.use entry:
> >
> >      */* abi_x86_32
> >
> 
> I'm confused: Has this a different semantics from adding 
> USE+='abi_x86_32' to make.conf? If no, why mention this strange way 
> (which is new to me) for setting default global useflags.

Because this is how users learn new fun stuff. Like sane configuration.

> And to bring this even further: Wouldn't the nicest approach to add
>    ABI_X86="32"

This will disable some 64-bit web browser plugins.

> or
>    ABI_X86="32 64"
> to make.conf? (With the latter being more descriptive, as the first one 
> might suggest that _only_ 32bit should be built).

This will enable some possibly-unwanted 64-bit software, e.g. 64-bit
Windows support in wine.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] multilib amd64 news item for review

[Andreas K. Huettel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Dienstag, 17. März 2015, 17:29:50 schrieb Michał Górny:

> >    ABI_X86="32 64"
> > to make.conf? (With the latter being more descriptive, as the first one 
> > might suggest that _only_ 32bit should be built).
> 
> This will enable some possibly-unwanted 64-bit software, e.g. 64-bit
> Windows support in wine.
> 

errhm... I guess this needs an explanation. Why is this not equivalent?

Sounds like a bug to me.

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVCFvgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwNzlCRDk4QzA4RENBRkYzQUEwRjQzMDlF
QkU2QTMzNkJFMTkwMzlDAAoJEOvmoza+GQOcbVEP/RDZjUvRs+iDoxvE9DA0MruI
8USQ5YpPWx4Yp35t2+P1nf9x1drFUeJp6XDSl0Qqeg92AVQG777RPH1PdSdgMOWb
n/+B4LKxfpLu7YfOi+/fp2ENyH/SmwZinFY1M4WtZ5mt8+AGZe008J/Y/YboDGSy
5DKSqf/+JnW6WTNt48wgShetV00Wv9q1YHFEnnODTiVwi1nQ9yf+W8bNMBsMxKxO
cn6k6xsLuPA2xzzmuqDnRSpG7NmZpOM9nU75jG0TVJCg8gjQEY4/lE2Cncwk0Y9z
rACDWGryTnFZG1A9oogpkUPvdZ1dUjh52FaCtJryrikypKfiSMMseGXbmgbnLt1I
WbQoVK0G7DpwETwOU/pdse+6e2/q9hskOYWbnrZizXULlXmlD7zjvZ65gL9ipzCe
mn1mam+fS8kiBXq7Ruz1RFEqH6M35KXN5EOfXtrK+VSABY1YD7X/p056kOJ1ikjB
XmE4UzdPgk2uczvQ3KiTNSU23U2sXd6v/KCM/HcODahvPK7PuOJAakHARxWVewIA
Ey7tBiOKtHuC0GEF29RJNSQb0EEkWq1gW+p82v/AnsQnfwVu9uJ7NRK5X0bg+R6j
P/u5uTwpQ5acJtg2NDBzXBkPBcmhZzJsL3172s0FsAMvOWC9UOpVApvtEWVqkXm3
aaUPxImOq5XIoPK4px+Z
=6nW0
-----END PGP SIGNATURE-----

[gentoo-dev] Re: multilib amd64 news item for review

[Nikos Chantziaras]

On 17/03/15 18:29, Michał Górny wrote:
> Dnia 2015-03-17, o godz. 16:55:32
> René Neumann <lists@necoro.eu> napisał(a):
>
>> Am 17.03.2015 um 16:33 schrieb Michał Górny:
>>>   However, some
>>> users may prefer setting ABI_X86 globally to enable 32-bit libraries
>>> in all packages that support building them. This can be done using
>>> the following package.use entry:
>>>
>>>       */* abi_x86_32
>>>
>>
>> I'm confused: Has this a different semantics from adding
>> USE+='abi_x86_32' to make.conf? If no, why mention this strange way
>> (which is new to me) for setting default global useflags.
>
> Because this is how users learn new fun stuff. Like sane configuration.

I don't see why ABI_X86 is not the sane option. Using wildcards in 
package.use is what sounds insane to me.

Are you suggesting that the sane way of setting USE flags globally is 
moving them from make.conf into package.use and use wildcards to set 
them globally?


>> And to bring this even further: Wouldn't the nicest approach to add
>>     ABI_X86="32"
>
> This will disable some 64-bit web browser plugins.

I don't see why the package.use wildcard wouldn't do that too.


>>     ABI_X86="32 64"
>> to make.conf? (With the latter being more descriptive, as the first one
>> might suggest that _only_ 32bit should be built).
>
> This will enable some possibly-unwanted 64-bit software, e.g. 64-bit
> Windows support in wine.

I don't see why the package.use wildcard wouldn't do that too.

Re: [gentoo-dev] Re: multilib amd64 news item for review

[Michał Górny]

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

Dnia 2015-03-29, o godz. 19:14:43
Nikos Chantziaras <realnc@gmail.com> napisał(a):

> On 17/03/15 18:29, Michał Górny wrote:
> > Dnia 2015-03-17, o godz. 16:55:32
> > René Neumann <lists@necoro.eu> napisał(a):
> >
> >> Am 17.03.2015 um 16:33 schrieb Michał Górny:
> >>>   However, some
> >>> users may prefer setting ABI_X86 globally to enable 32-bit libraries
> >>> in all packages that support building them. This can be done using
> >>> the following package.use entry:
> >>>
> >>>       */* abi_x86_32
> >>>
> >>
> >> I'm confused: Has this a different semantics from adding
> >> USE+='abi_x86_32' to make.conf? If no, why mention this strange way
> >> (which is new to me) for setting default global useflags.
> >
> > Because this is how users learn new fun stuff. Like sane configuration.
> 
> I don't see why ABI_X86 is not the sane option. Using wildcards in 
> package.use is what sounds insane to me.

Because it overrides the defaults without providing a way to append to
them.

> Are you suggesting that the sane way of setting USE flags globally is 
> moving them from make.conf into package.use and use wildcards to set 
> them globally?

Yes.

> >> And to bring this even further: Wouldn't the nicest approach to add
> >>     ABI_X86="32"
> >
> > This will disable some 64-bit web browser plugins.
> 
> I don't see why the package.use wildcard wouldn't do that too.

It is applied on top of the default rather than overriding it.

> >>     ABI_X86="32 64"
> >> to make.conf? (With the latter being more descriptive, as the first one
> >> might suggest that _only_ 32bit should be built).
> >
> > This will enable some possibly-unwanted 64-bit software, e.g. 64-bit
> > Windows support in wine.
> 
> I don't see why the package.use wildcard wouldn't do that too.

Ditto.

-- 
Best regards,
Michał Górny

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

[gentoo-dev] Re: multilib amd64 news item for review

[Nikos Chantziaras]

On 29/03/15 19:24, Michał Górny wrote:
> Dnia 2015-03-29, o godz. 19:14:43
> Nikos Chantziaras <realnc@gmail.com> napisał(a):
>
>> On 17/03/15 18:29, Michał Górny wrote:
>>> Dnia 2015-03-17, o godz. 16:55:32
>>> René Neumann <lists@necoro.eu> napisał(a):
>>>
>>>> Am 17.03.2015 um 16:33 schrieb Michał Górny:
>>>>>    However, some
>>>>> users may prefer setting ABI_X86 globally to enable 32-bit libraries
>>>>> in all packages that support building them. This can be done using
>>>>> the following package.use entry:
>>>>>
>>>>>        */* abi_x86_32
>>>>>
>>>>
>>>> I'm confused: Has this a different semantics from adding
>>>> USE+='abi_x86_32' to make.conf? If no, why mention this strange way
>>>> (which is new to me) for setting default global useflags.
>>>
>>> Because this is how users learn new fun stuff. Like sane configuration.
>>
>> I don't see why ABI_X86 is not the sane option. Using wildcards in
>> package.use is what sounds insane to me.
>
> Because it overrides the defaults without providing a way to append to
> them.

According to emerge --info, ABI_X86 seems to append, not override. In 
make.conf:

   ABI_X86="32"

Then:

   $ emerge --info | grep -i abi_x86

You get:

   ABI_X86="32 64"


"64" seems to be always there. You cannot override it. Using 
ABI_X86="32" in make.conf seems to only append "32" to the default.

If this is not the case, and "*/* abi_x86_32" in package.use really does 
something different, then this is implemented in a way too confusing for 
people and should be considered a bug :-/

Re: [gentoo-dev] Re: multilib amd64 news item for review

[Michał Górny]

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

Dnia 2015-03-29, o godz. 19:59:19
Nikos Chantziaras <realnc@gmail.com> napisał(a):

> On 29/03/15 19:24, Michał Górny wrote:
> > Dnia 2015-03-29, o godz. 19:14:43
> > Nikos Chantziaras <realnc@gmail.com> napisał(a):
> >
> >> On 17/03/15 18:29, Michał Górny wrote:
> >>> Dnia 2015-03-17, o godz. 16:55:32
> >>> René Neumann <lists@necoro.eu> napisał(a):
> >>>
> >>>> Am 17.03.2015 um 16:33 schrieb Michał Górny:
> >>>>>    However, some
> >>>>> users may prefer setting ABI_X86 globally to enable 32-bit libraries
> >>>>> in all packages that support building them. This can be done using
> >>>>> the following package.use entry:
> >>>>>
> >>>>>        */* abi_x86_32
> >>>>>
> >>>>
> >>>> I'm confused: Has this a different semantics from adding
> >>>> USE+='abi_x86_32' to make.conf? If no, why mention this strange way
> >>>> (which is new to me) for setting default global useflags.
> >>>
> >>> Because this is how users learn new fun stuff. Like sane configuration.
> >>
> >> I don't see why ABI_X86 is not the sane option. Using wildcards in
> >> package.use is what sounds insane to me.
> >
> > Because it overrides the defaults without providing a way to append to
> > them.
> 
> According to emerge --info, ABI_X86 seems to append, not override. In 
> make.conf:
> 
>    ABI_X86="32"
> 
> Then:
> 
>    $ emerge --info | grep -i abi_x86
> 
> You get:
> 
>    ABI_X86="32 64"
> 
> 
> "64" seems to be always there. You cannot override it. Using 
> ABI_X86="32" in make.conf seems to only append "32" to the default.

Portage may do that because it's forced by default. But some packages
'unforce' it, and that's when it matters.

> 
> If this is not the case, and "*/* abi_x86_32" in package.use really does 
> something different, then this is implemented in a way too confusing for 
> people and should be considered a bug :-/

Yes, USE support in make.conf is a big pile of random misbehaviors
and bugs that need to be killed with fire.


-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: multilib amd64 news item for review

[Andrew Savchenko]

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

On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote:
> > If this is not the case, and "*/* abi_x86_32" in package.use really does 
> > something different, then this is implemented in a way too confusing for 
> > people and should be considered a bug :-/
> 
> Yes, USE support in make.conf is a big pile of random misbehaviors
> and bugs that need to be killed with fire.

The proposal above is an absolute madness, especially for global
USE flags.

Why users should deal with dozens (if not hundreds useless */*)?

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: multilib amd64 news item for review

[Ciaran McCreesh]

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

On Sun, 29 Mar 2015 20:35:27 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:
> The proposal above is an absolute madness, especially for global
> USE flags.
> 
> Why users should deal with dozens (if not hundreds useless */*)?

The syntax for package.use allows multiple flags per line, and
comments...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: multilib amd64 news item for review

[Michał Górny]

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

Dnia 2015-03-29, o godz. 20:35:27
Andrew Savchenko <bircoph@gentoo.org> napisał(a):

> On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote:
> > > If this is not the case, and "*/* abi_x86_32" in package.use really does 
> > > something different, then this is implemented in a way too confusing for 
> > > people and should be considered a bug :-/
> > 
> > Yes, USE support in make.conf is a big pile of random misbehaviors
> > and bugs that need to be killed with fire.
> 
> The proposal above is an absolute madness, especially for global
> USE flags.
> 
> Why users should deal with dozens (if not hundreds useless */*)?

To get sane, consistent and predictable config for a start. But you
know that you can specify multiple flags on one line, right? In fact,
'*/* ' is shorter than 'USE=""'!


-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: multilib amd64 news item for review

[Andrew Savchenko]

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

On Sun, 29 Mar 2015 19:43:51 +0200 Michał Górny wrote:
> Dnia 2015-03-29, o godz. 20:35:27
> Andrew Savchenko <bircoph@gentoo.org> napisał(a):
> 
> > On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote:
> > > > If this is not the case, and "*/* abi_x86_32" in package.use really does 
> > > > something different, then this is implemented in a way too confusing for 
> > > > people and should be considered a bug :-/
> > > 
> > > Yes, USE support in make.conf is a big pile of random misbehaviors
> > > and bugs that need to be killed with fire.
> > 
> > The proposal above is an absolute madness, especially for global
> > USE flags.
> > 
> > Why users should deal with dozens (if not hundreds useless */*)?
> 
> To get sane, consistent and predictable config for a start. But you
> know that you can specify multiple flags on one line, right?

I'm well aware of that..

> In fact, '*/* ' is shorter than 'USE=""'!

Only for short sets. For a long list of USE flags right now I have:
USE="
flag1
-flag2
flag3
...
flag433
"

This is an easily maintainable list, which is alphabetically sorted
(it is trivial to do in vim).

Why 433 flags? Because for flags common to more than a single
package I don't want to duplicate them. For unique flags I have 225
entries (with comments) in package.use.

With your proposal I have three alternatives:

1.
*/* long list of 433 flags

Hard to read, hard to maintain, no benefits.

2.
*/* flag1
*/* -flag2
*/* flag3
...
*/* flag433

A lot of useless stuff, no benefits.

3.
*/* \
flag1 \
-flag2 \
flag3 \
... \
flag433

A lot of useless stuff, no benefits, easy to make mistake (e.g.
forgot "\" after a new flag and have a lot of stuff broken).

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: multilib amd64 news item for review

[Nikos Chantziaras]

On 29/03/15 21:00, Andrew Savchenko wrote:
> */* long list of 433 flags

Yeah, just noticed that I can't split the lines.

I then tried to define an array of USE flags in make.conf:

   GLOBAL_USE_FLAGS=( ... )

so that I can then use that array in package.use, but for some reason 
make.conf doesn't accept arrays :-/

Re: [gentoo-dev] Re: multilib amd64 news item for review

[Michał Górny]

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

Dnia 2015-03-29, o godz. 21:31:49
Nikos Chantziaras <realnc@gmail.com> napisał(a):

> On 29/03/15 21:00, Andrew Savchenko wrote:
> > */* long list of 433 flags
> 
> Yeah, just noticed that I can't split the lines.
> 
> I then tried to define an array of USE flags in make.conf:
> 
>    GLOBAL_USE_FLAGS=( ... )
> 
> so that I can then use that array in package.use, but for some reason 
> make.conf doesn't accept arrays :-/

Because make.conf is only pseudo-shell that is parsed with a broken
pseudo-shell parser.

-- 
Best regards,
Michał Górny

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

[gentoo-dev] Re: multilib amd64 news item for review

[Nikos Chantziaras]

On 29/03/15 20:28, Michał Górny wrote:
> Dnia 2015-03-29, o godz. 19:59:19
> Nikos Chantziaras <realnc@gmail.com> napisał(a):
>> According to emerge --info, ABI_X86 seems to append, not override. In
>> make.conf:
>>
>>     ABI_X86="32"
>>
>> Then:
>>
>>     $ emerge --info | grep -i abi_x86
>>
>> You get:
>>
>>     ABI_X86="32 64"
>>
>>
>> "64" seems to be always there. You cannot override it. Using
>> ABI_X86="32" in make.conf seems to only append "32" to the default.
>
> Portage may do that because it's forced by default. But some packages
> 'unforce' it, and that's when it matters.
>
>>
>> If this is not the case, and "*/* abi_x86_32" in package.use really does
>> something different, then this is implemented in a way too confusing for
>> people and should be considered a bug :-/
>
> Yes, USE support in make.conf is a big pile of random misbehaviors
> and bugs that need to be killed with fire.

Looks like I'm moving USE flags and abi_x86_32 into package.use...

I hope that doesn't compromise emerge --info output for bugzilla issues?

Re: [gentoo-dev] multilib amd64 news item for review

[Ben de Groot]

On 17 March 2015 at 23:33, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2015-03-15, o godz. 15:11:47
> Michał Górny <mgorny@gentoo.org> napisał(a):
>
>
> Here's -r1:
> [...]

I think this is really great! Just one small nitpick:

> Note that after performing this step, 32-bit applications on user's
> system may become temporarily broken.

Make that "the user's system".

-- 
Cheers,

Ben | yngwin
Gentoo developer

[gentoo-dev] Re: multilib amd64 news item for review

[Duncan]

Ben de Groot posted on Wed, 18 Mar 2015 15:40:02 +0800 as excerpted:

> On 17 March 2015 at 23:33, Michał Górny <mgorny@gentoo.org> wrote:
>> Dnia 2015-03-15, o godz. 15:11:47 Michał Górny <mgorny@gentoo.org>
>> napisał(a):
>>
>>
>> Here's -r1:
>> [...]
> 
> I think this is really great! Just one small nitpick:
> 
>> Note that after performing this step, 32-bit applications on user's
>> system may become temporarily broken.
> 
> Make that "the user's system".

What about...

Note: 32-bit applications may be temporarily broken after this step.

Concise and to the point. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: multilib amd64 news item for review

[Ben de Groot]

On 18 March 2015 at 20:46, Duncan <1i5t5.duncan@cox.net> wrote:
> Ben de Groot posted on Wed, 18 Mar 2015 15:40:02 +0800 as excerpted:
>
>> On 17 March 2015 at 23:33, Michał Górny <mgorny@gentoo.org> wrote:
>>> Dnia 2015-03-15, o godz. 15:11:47 Michał Górny <mgorny@gentoo.org>
>>> napisał(a):
>>>
>>>
>>> Here's -r1:
>>> [...]
>>
>> I think this is really great! Just one small nitpick:
>>
>>> Note that after performing this step, 32-bit applications on user's
>>> system may become temporarily broken.
>>
>> Make that "the user's system".
>
> What about...
>
> Note: 32-bit applications may be temporarily broken after this step.
>
> Concise and to the point. =:^)

Even better!

-- 
Cheers,

Ben | yngwin
Gentoo developer