----- Original Message -----
From: "Tomasz Kłoczko" <kloczko.tomasz(a)gmail.com>
To: "Development discussions related to Fedora"
Sent: Monday, July 9, 2018 6:45:28 PM
Subject: Re: [HEADS UP] Removal of GCC from the buildroot
On Mon, 9 Jul 2018 at 16:42, Przemek Klosowski
> >> After which, I'm going to ask rel-eng to finally remove it from
> >> buildroot. This will happen before mass rebuild. Stay tuned.
> > After adding explicite gcc/g++ in BuildRequires it will be extreamly
> > hard to switch use for example to use clang.
> Well, you imply that currently we could just substitute clang for GCC
> and successfully rebuild everything, but that is not the case: there
> will be breakage.
Mistake .. this is not implication but *observation*/conclusion.
Such implication/observation has nothing to do with my person.
Yes it does. You claim something without having any proof to back
it up. Not the first time that this has happened.
After add explicit to BuildRequires gcc in case of even try to use
clang instead gcc all those specs with "BuildRequires: gcc" will needs
to be changed. You can wipe me from this universe and this still will
Explicit is better than implicit. It's up to the packager (and upstream
of course) to decide on the preferred compiler. So of course it will need
to be changed. Are you implying that one day maybe we'll change to clang
universally so we'll have to keep the SPEC's BuildRequires vague for that
We are talking about potentially thousands if not tenths of
packages spec files. That is really shame that someone did not hold
for few seconds to ask themselves "moment!! it it really easiest way?"
No. But I believe objectively it's the best as it doesn't leave room
for guesses. What you see is what it is.
It would be relatively easy to perform such change in the future in
all packages master branches will be used only by rawhide
However as current Fedora practice shows almost all mass changes never
have been done to the bottom because many packages wants to have
"universal" spec files. Only this makes such changes way harder or
Instead using git branches almost all Fedora spec files must support
all not EOLed Fedora versions, many of them EPEL (at least two
versions) and sometimes even CentOS (despite fact that CentOS guys are
not using Fedora specs).
This is only reason why I wrote that it will be "extremely hard" on
any future changes.
No they must not. Your wording here implies that this is some sort of rule
or guideline while actually packagers just want to do because of convenience
in some aspects of packaging. (I would argue that it's not really convenient
but that's just my personal opinion).
(Good that recent request to allow use %ifings for SuSE has been
Issue is that clang is better and better and (IMO) sooner or later
switching to use it could potentially interesting option.
Using clang even not (yet) as the option to produce whole distribution
using clang is very useful to expose more no-so-well-written part of
the code because clang provides now much. IMO it would be good to
split every build request to send to build env where everything would
be possible to build using clang .. only to store build logs which
should show more compile warnings.
It could be, it could be not. Shouting for something that you don't LIKE
doesn't make it more appealing technically and what not. I thought you
would have figured it out by now throughout all the pointless threads
you have opened or comments you've made here but you keep falling
within the same fallacies.
If you have an opinion express it while being aware and respectful of
others. You have failed to do that on multiple occasions and I really
wonder why you keep posting here.
If Fedora deliberately wants to use gcc (because maintaining gcc it
part of the RH core busies and some guys interested testing bleeding
edge gcc code and may be not interested to do the same doe clang) that
is fine and what conclusion which I formed can be ignored.
However if intention would be to provide here some level of
flexibility introducing now gcc/g++ as explicit BuidRequires will
close many doors.
Again how it will close many doors? On some hypothetical future where clang
will be the default? While that could be a reasonable argument on a time and place
where the compilers would fight on equal grounds, and while the status quo's might
from time to time, I don't see gcc being something other than default in the linux
for the foreseeable future.
My proposition is *not* to add gcc/g++ explicit to BuildReequires
use instead glibc-devel and libstdc++-devel modifications and ban use
gcc/gcc-c++ in BuildRequires (in most of the cases all current gcc/g++
BuildRequires could be replaced by glibc-devel and libstdc++-devel).
All because it is not possible to use C compiler without glibc-devel
and C++ compiler without libstdc++-devel.
I love how instead of a compromise you actually propose banning of
that buildrequires. You realize that you arguments are never assertive and it
just makes people even more opposed to your (poorly worded) propositions?
Changes in redhat-rpm-config to be able easy switch between gcc and
clang (to other compilers) could be done later.
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Python Maintenance Team, Red Hat