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
<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.
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 : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
