1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 02/24/2013 03:57 PM, Michał Górny wrote: |
5 |
> On Sun, 24 Feb 2013 05:22:43 +0100 hasufell <hasufell@g.o> |
6 |
> wrote: |
7 |
> |
8 |
>> Before people start asking I should explain why I started this: |
9 |
>> https://bugs.gentoo.org/show_bug.cgi?id=458638 |
10 |
>> |
11 |
>> I think having such an eclass has several advantages over |
12 |
>> autootools-multilib.eclass (which depends on |
13 |
>> autotools-utils.eclass) as it is now: |
14 |
> |
15 |
> You wanted the other points, so here you go. |
16 |
> |
17 |
>> a) Less eclass dependencies. One could argue: the more eclasses |
18 |
>> my ebuild uses the more prone to error and exposed to changes it |
19 |
>> is. |
20 |
> |
21 |
> That's as good as bundling libraries. Really. |
22 |
|
23 |
That analogy is flawed. It's about ebuild design and the fact that I |
24 |
don't just convert my ebuild to _multilib_, but also to |
25 |
_autotools-utils_, so I have to keep an eye on another provider. |
26 |
|
27 |
> |
28 |
>> b) easier conversion in some cases: often times a simple rename |
29 |
>> src_compile -> multilib_src_compile will do |
30 |
> |
31 |
> Easy != good. The eclass switch is a good point to fix bugs which |
32 |
> should have been fixed long ago. By making it unnecessary, you |
33 |
> just keep those bugs live and hidden. |
34 |
> |
35 |
>> c) it allows more custom definition of phase functions |
36 |
> |
37 |
> More custom than what? |
38 |
|
39 |
Than autotools-multilib.eclass. |
40 |
|
41 |
> |
42 |
>> d) the previous point will also allow to convert go-mono.eclass |
43 |
>> packages without introducing yet another eclass for that |
44 |
> |
45 |
> So you're introducing a hacky eclass just because you're too lazy |
46 |
> to convert go-mono packages properly and too impatient to let |
47 |
> others do the work properly for you? |
48 |
|
49 |
Please point out where the eclass is hacky. I haven't heard a |
50 |
technical argument against it despite that you think |
51 |
autotools-multilib.eclass is better. |
52 |
That might be true, but then I don't understand why people refuse to |
53 |
use it which is the only reason I am proposing this. |
54 |
|
55 |
Also, I am not too lazy to convert go-mono packages. I have already |
56 |
written the go-mono-multilib.eclass and it looks almost the same as |
57 |
autotools-multilib-minimal.eclass, so I am wondering why I want |
58 |
code-duplication in eclasses. |
59 |
|
60 |
> |
61 |
>> e) autotools-utils.eclass does a bit more than just calling |
62 |
>> default phase functions; the developer has little choice on this |
63 |
>> matter unless he wants to rewrite his ebuild based on |
64 |
>> multilib-build.eclass which will create a lot of code duplication |
65 |
>> in ebuilds, hence this proposition |
66 |
> |
67 |
> And as I already told you, this argument just proves that you |
68 |
> don't know the eclass in question and just throwing random |
69 |
> accusations. |
70 |
> |
71 |
|
72 |
No, I was just rephrasing other peoples concerns. |
73 |
|
74 |
>> I don't have a problem with the present eclasses, but I find this |
75 |
>> a logical enhancement. |
76 |
> |
77 |
> If that's logical, then please provide a graph showing where it |
78 |
> logically fits. Because so far, it's either hate-built redundant |
79 |
> eclass or quick draft eclass written for a single package. |
80 |
> |
81 |
|
82 |
I don't understand you. |
83 |
It works on more than one package. |
84 |
|
85 |
|
86 |
Anyway... as I said, I don't care how this problem is solved. I only |
87 |
care about the availability of 32bit libs |
88 |
-----BEGIN PGP SIGNATURE----- |
89 |
Version: GnuPG v2.0.19 (GNU/Linux) |
90 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
91 |
|
92 |
iQEcBAEBAgAGBQJRKi3GAAoJEFpvPKfnPDWzkW4H/3uaQ++8Rky1GKi+Tvffz45i |
93 |
x+yNpPtje/gWFKjXVeWxQZfNV/tLsq1TZM0ruzixB6lO1vFD6Ql+8ZiuTrHHRvuV |
94 |
at3+iT2AycSTeNs0qRUHjICOn5V6fMNQyIxJsrFS+HNEEbYfE36+S91YvN9WwHr6 |
95 |
Q2PDBp+3jueJXNVeZh+zdSQL4eo2fEuJ39/pa42SPbeRGGm6aw1SnhD9RYBcRZuf |
96 |
GyuTOk7R+vwp55i4d7xXyb8eEDVh7uSqikb7OniNA15a7wrmpSLsfwonhZS/a3Qq |
97 |
R/pQDXGm+aDDk7ZwXGCWRvGd7ARLqED5A+5yKcfyQeZ99RP6KHW8+xEwkr8M54I= |
98 |
=3uKD |
99 |
-----END PGP SIGNATURE----- |