1 |
Dnia 2015-03-15, o godz. 15:43:56 |
2 |
Ulrich Mueller <ulm@g.o> napisał(a): |
3 |
|
4 |
> >>>>> On Sun, 15 Mar 2015, Michał Górny wrote: |
5 |
> |
6 |
> > Hello, everyone. Here's the first draft of news item for |
7 |
> > gx86-multilib. I tried to cover all the important aspects. Please |
8 |
> > review and let me know what you think. |
9 |
> |
10 |
> > Title: True multilib support on amd64 |
11 |
> > Author: Michał Górny <mgorny@g.o> |
12 |
> > Content-Type: text/plain |
13 |
> > Posted: 2015-01-28 |
14 |
> > Revision: 1 |
15 |
> > News-Item-Format: 1.0 |
16 |
> > Display-If-Keyword: amd64 |
17 |
> > Display-If-Keyword: ~amd64 |
18 |
> |
19 |
> Users of no-multilib profiles won't be affected, so maybe |
20 |
> Display-If-Profile should be used (in addition, or instead of |
21 |
> Display-If-Keyword)? |
22 |
|
23 |
Display-If-Profile does exact profile matching, so we'd have to keep |
24 |
an up-to-date list of all profiles derived from multilib amd64... |
25 |
|
26 |
> > Starting with 2015-03-29, we are enabling the true multilib support |
27 |
> > on amd64 and masking the old emul-linux-x86 package sets for removal. |
28 |
> > This change provides |
29 |
> |
30 |
> I'm not a native speaker, but shouldn't a future tense be used here? |
31 |
> |
32 |
> > our users with the opportunity to build 32-bit |
33 |
> > libraries from source with all the flexibility given by ebuilds, rather |
34 |
> > than relying on pre-packaged binary versions of them. |
35 |
> |
36 |
> > The switch to the new system is likely to require a specific action from |
37 |
> > the users of our multilib profiles. Since the new system collides with |
38 |
> > the old one, the Package Manager must be able to clearly satisfy all |
39 |
> > the dependencies using the new system in order to proceed. This may |
40 |
> > require unmerging packages installed from third-party repositories that |
41 |
> > have not been updated to support the new system. |
42 |
> |
43 |
> > In order to enable building necessary 32-bit libraries, users will be |
44 |
> > required to enable the abi_x86_32 USE flag on respective packages. |
45 |
> |
46 |
> How? Maybe add a hint that this should be done in package.accept_keywords? |
47 |
|
48 |
It can't :P. But added a hint for package.use. |
49 |
|
50 |
> > In most of the cases, Portage will be able to deliver correct |
51 |
> > suggestions for that when using the --autounmask feature. However, some |
52 |
> > users may prefer setting ABI_X86 globally to enable 32-bit libraries |
53 |
> > in all packages supporting building them. |
54 |
> |
55 |
> Again, add a hint how to do this? |
56 |
|
57 |
Likewise. |
58 |
|
59 |
> > In case of issues, blockers especially, the users users |
60 |
> |
61 |
> s/the users users/users/ |
62 |
|
63 |
Fixed. |
64 |
|
65 |
> > are recommended |
66 |
> > to manually uninstall any emul-linux-x86 packages that may have been |
67 |
> > installed on their systems. This will aid the Package Manager |
68 |
> > in choosing the correct dependency resolution path. If using Portage, |
69 |
> > this can be done using the following command: |
70 |
> |
71 |
> > $ emerge -C 'app-emulation/emul-linux-x86*' |
72 |
> |
73 |
> > Note that after performing this step, 32-bit applications on your system |
74 |
> |
75 |
> So far you have used third person throughout, so avoid the "your" |
76 |
> here. |
77 |
|
78 |
Fixed. |
79 |
|
80 |
> |
81 |
> > may become temporarily broken. Therefore, this step should be followed |
82 |
> > by a @world upgrade immediately. |
83 |
> |
84 |
> Maybe a pointer to the wiki could be added? How about this: |
85 |
> https://wiki.gentoo.org/wiki/Multilib_System_without_emul-linux_Packages |
86 |
> (with that page being updated if necessary). |
87 |
|
88 |
If someone has time to uncruft that wiki page, I'd be happy to link it. |
89 |
|
90 |
-- |
91 |
Best regards, |
92 |
Michał Górny |