1 |
On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile |
2 |
<basile@××××××××××××××.edu> wrote: |
3 |
> On 12/07/14 05:37, Michał Górny wrote: |
4 |
>> |
5 |
>> If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd |
6 |
>> appreciate any bug reports, except for those covering things i've |
7 |
>> already listed as missing :). Any further comments will be very helpful |
8 |
>> in deciding on the way forward. |
9 |
> |
10 |
> Removing the eclass is a bad idea: |
11 |
> |
12 |
> 0) This reduces code reusability. The eclass is used by sys-devel/kgcc64 in |
13 |
> the tree and (at least) the hardened-dev::musl overlay outside. |
14 |
|
15 |
Well, other packages could keep using the eclass. |
16 |
|
17 |
I think that eclasses tend to get abused in situations like these. It |
18 |
is one thing if you have 300 ebuilds that are all maintained together |
19 |
like there are with kde and logic really is shared in common between |
20 |
them. |
21 |
|
22 |
However, this eclass is only used by a few packages, the shared code |
23 |
isn't across stuff installed in parallel but across stuff that changes |
24 |
over time. This is done without upstream support for the most part, |
25 |
so it becomes a growing collection of workarounds. When eclasses |
26 |
start following different code paths every time a package that uses |
27 |
them is versioned, it makes a lot more sense to either version the |
28 |
eclass every time or move the code to the ebuild. |
29 |
|
30 |
> |
31 |
> 1) Those version specific conditionals that you don't like give a |
32 |
> history/comparison of gcc versions. It is not cruft. It encodes what |
33 |
> versions allow what features. Moving to the ebuilds makes this history much |
34 |
> harder to read. Think of a diff -Naur when producing a patch. I like the |
35 |
> current eclass approach. |
36 |
|
37 |
Why do we need a history/comparison of gcc written in shell script? |
38 |
Wouldn't a text file or webpage be a better way to document this? |
39 |
Wouldn't upstream be the place to document this? |
40 |
|
41 |
This seems a bit like saying that we don't need the EAPI/PMS guide or |
42 |
even PMS itself because anybody can just read the portage source code |
43 |
and figure out how it works. |
44 |
|
45 |
If you need a list of what features are supported in what versions of |
46 |
gcc, wouldn't it make more sense to create a wiki page somewhere? |
47 |
|
48 |
>> |
49 |
>> If there is a real interest in my fork, I will probably move it to gx86 |
50 |
>> as sys-devel/gcc-mgorny. |
51 |
> |
52 |
> |
53 |
> I don't think we should proceed this way. The way I'd like to proceed is to |
54 |
> introduce a new toolchain-r1.eclass which addresses at least your QA issues |
55 |
> below. If I understood Ryan's plan with the eclass, it was to simply |
56 |
> refactor the phase functions to modernize things but keep backwards compat. |
57 |
> When toolchain-r1.eclass is mature, then we switch the inherit. I'd like to |
58 |
> keep gcc-2* and gcc-3* around. We could consider cleaning up those ebuilds |
59 |
> to work with EAPI=4 or 5 with the new eclass or just leave them with the old |
60 |
> eclass. |
61 |
> |
62 |
> Also, no to the name sys-devel/gcc-mgorny. I very much appreciate the |
63 |
> excellent hard work you've done on eclasses, but the reason this is |
64 |
> happening is because of patches that toolchain lead is not accepting. |
65 |
> Anyhow, most of the work with gcc (in my opinion) is with the patches |
66 |
> against gcc itself which are housed in ~vapier, ~rhill and ~zorry. When you |
67 |
> don't accept my patches to gcc-mgorny, shall I add gcc-basile to the tree? |
68 |
|
69 |
Well, that would be in keeping with GLEP 39, which seems to encourage |
70 |
everybody to fork each other's packages. :) |
71 |
|
72 |
It seems like there is a fundamental disagreement here over the right |
73 |
way to refactor all this code. Honestly, the fact that nobody seems |
74 |
to even want to look at the toolchain suggests to me that |
75 |
simplification is probably worthwhile. |
76 |
|
77 |
> |
78 |
> I will also be happy to work on replacing |
79 |
>> |
80 |
>> the new versions of original sys-devel/gcc completely. With QA process |
81 |
>> against toolchain.eclass if necessary. |
82 |
>> |
83 |
> |
84 |
> Let's get the list of QA issues so I at least can work towards a |
85 |
> toolchain-r1.eclass if you're not interested in going that way. Also, I |
86 |
> take the QA issues seriously, but threatening a QA intervention against |
87 |
> toolchain and then acting by forking is heavy handed. QA actions against |
88 |
> the current codebase is understandable. |
89 |
|
90 |
Agree somewhat. |
91 |
|
92 |
Forking is perfectly fine - a complete non-issue. Trying to exclude |
93 |
the other branch in the name of QA is something we need to be careful |
94 |
about and consider on the merits. If somebody wants to add yet |
95 |
another gcc implementation to the tree and it is really lousy, I don't |
96 |
really have a problem with it if it builds and doesn't contain |
97 |
security issues, etc. I think people sometimes try to make QA into |
98 |
something that it isn't. In the same way there is nothing wrong with |
99 |
the existing gcc implementation being completely unmaintainable and |
100 |
obsolete as long as it builds and doesn't contain security issues. |
101 |
|
102 |
I think the real issue we run into in these kinds of cases is |
103 |
namespace. If I want to add my own competing ebuild for chromium I |
104 |
can't call it chromium. |
105 |
|
106 |
-- |
107 |
Rich |