1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
2 |
Hash: SHA1
|
3 |
|
4 |
On Wed, 20 Jun 2012 16:50:33 -0400
|
5 |
Richard Yao <ryao@g.o> wrote:
|
6 |
> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote: |
7 |
> > On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@g.o> |
8 |
> > wrote: |
9 |
> >> Multilib (and/or multiarch) support The current binaries cause a |
10 |
> >> great deal of pain, particularly when a user does not want to |
11 |
> >> upgrade something. I had this problem with WINE and glibc because |
12 |
> >> I wanted to avoid the reverse memcpy() fiasco on my systems. This |
13 |
> >> situation would have been avoided entirely if the package manager |
14 |
> >> supported multilib. |
15 |
> > |
16 |
> > This one's unlikely to happen unless someone's prepared to put in |
17 |
> > the work. |
18 |
> |
19 |
> The multilib-portage overlay already has this working. |
20 |
|
21 |
But there is no spec, nor is there a developer-centric description of
|
22 |
it.
|
23 |
|
24 |
> > So far as I know, every PM relies heavily upon bash anyway (and |
25 |
> > can't easily be made not to), so even if developers would accept |
26 |
> > having to rewrite all their eclasses, it still wouldn't remove the |
27 |
> > dep. |
28 |
> |
29 |
> Lets address POSIX compliance in the ebuilds first. Then we can deal |
30 |
> with the package managers. |
31 |
|
32 |
Why? It's highly doubtful the package manglers could switch shells even
|
33 |
if they wanted to, and even if every ebuild started using EAPI 5. It's
|
34 |
wasted effort.
|
35 |
|
36 |
- --
|
37 |
Ciaran McCreesh
|
38 |
-----BEGIN PGP SIGNATURE-----
|
39 |
Version: GnuPG v2.0.19 (GNU/Linux)
|
40 |
|
41 |
iEYEARECAAYFAk/iOG8ACgkQ96zL6DUtXhG5FgCgw3V9qz3o1d0A4TUw5y83lfCE
|
42 |
LWkAnRbY4WKJz1xribnhUat0YL1XEwHR
|
43 |
=dYt+
|
44 |
-----END PGP SIGNATURE----- |