Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Anthony G. Basile]

On 12/07/14 17:41, William Hubbs wrote:
> On Sun, Dec 07, 2014 at 08:32:57AM -0500, Rich Freeman wrote:
>> On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile
>> <basile@××××××××××××××.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.
> This makes sense to me as well, let's work twoard getting rid of
> toolchain.eclass.

Hardened has used the eclass in its overlay and continues to use it.  We 
do not wish to get rid of it.

@hardened, we should discuss this at our next meeting.

>>> 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?
> I thinkk this makes more sense as well. Historical reasons don't work
> for me by them selves as a reason to justify keeping old code,
> especially when it is to support versions of packages that are no longer
> really supported upstream.

I'm not sure what you mean by "old code" which is "no longer really 
supported upstream".  gcc is built using gcc.  We should have a window 
on gcc versions which goes backwards and forwards a couple of versions, 
so I can build 4.8 with 4.7 or 4.6 and vice versa.  And build 4.6 with 
4.5 or 4.4, etc.  There is an entire chain there. Keeping the detailed 
decisions in an eclass of what features were on/off for each version 
makes sense so we can conveniently track that chain.  When I say I want 
to keep history, that's what I'm talking about.  In hardened we went 
through a pains taking process of making sure the first hardened gcc-4 
versions (4.4 I believe) was buildable by the previous one, and that it 
could build itself and could rebuild itself both adding and remove 
hardening etc.  (BTW by "we" I mean Magnus who deserves all the kudos.  
I just helped with testing and told him what broke.)

If you want to simplify code, then let's bump all the gcc ebuilds to 
EAPI 4 or above and refactor the phase functions and remove all the EAPI 
checks.  But removing all instances of tc_version_is_* is not a good idea.

>
>>>> 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.
> Why do you want to keep these outdated and not supported versions of gcc
> around? Have you tried building a modern system with gcc-2 or gcc-3? I
> haven't but I'm sure it would fail horribly.

But not certain embedded systems or other scenarios.  gcc-3 for instance 
did hardening differently than 4.  While I'm not as interested in gcc-2, 
I don't want to see gcc-3 dumped.  Even minor leaps like 4.7 to 4.8 
introduced deep changes like requiring c++. Its easy to say, why do we 
need this? when one forgets that evolution, or was never familiar with it.

This line of reasoning is used often: "I can't see how this is useful 
for the type of systems I envision, so this is not useful." Gentoo is 
not that spectacular as a "regular" distro.  Only masochists pick gentoo 
as a desktop given that it has no installer --- why wouldn't the average 
user pick ubuntu over gentoo if they want something that "just works."  
But for niche systems, Gentoo shines like nothing else.  ChromeOS would 
never have been born of a debian-ish or fedora-ish distro.  Let's keep 
this alive.

>
>>> 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.

This statement is not true.  The maintainer is actively making commits 
to toolchain.eclass and gcc.  The problem stems from the maintainer 
ignoring patches to the eclass regarding certain fixes, eg the thorny 
dependencies on gcj[awt] which draws in windowing system stuff.  A 
compiler depending on media-libs/alsa-lib!  Yuck!

These are QA issues.  I do agree with Michal that they should be 
addressed.  I am willing to support QA against the maintainer as I said 
in a previous email, after a review of proposed changes.  But these 
problems are not the occasion to throw out the current approach to 
toolchain.

>
>   I tend to agree here too; let's get rid of the old versions of things
>   where we can and simplify.

This move will not simply things.  It will just re-encode the 
complexities in a new way.  Or it will throw out stuff we later realize 
we want.  Take a look at bug #513716, #513578, #513576 and others and 
tell me how any of the above suggestions to remove the eclass will make 
that ugliness simple?

If people really want this, then I'd rather see a fork in the tree for 
those "forward looking devs" and leave the current toolchian stuff in 
tact for us old "fuddy duddies" like me.

>
> William
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA