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