On Tue, 10 Jul 2018 at 06:37, David Tardon <dtardon@xxxxxxxxxx> wrote:
[..]
> > My proposition is *not* to add gcc/g++ explicit to BuildReequires and
> > 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.
>
> It might be a surprise for you, but there are other implementations of
> C and C++ standard libraries. If I try to imagine Fedora wanting to
> switch to clang in the future,
It is not but it is quite interesting how you are trying to move
technical discussion to kind of "argumentum ad hominem" field.
> I can very well imagine it wanting to
> switch to libc++ at the same time... So your "improved" proposal is,
> in fact, just as arbitrary and choice-limiting as the one you
> criticize.
So you want to tell that putting explicit gcc/gcc-g++ BRs makes such
switching (which is less important) or test build (which is way more
interesting and valuable options) easier and/or opens some option?
Really?
As I've mention using BR: %{__cc} and BR: %{__cxx} covers in the same
way some needs as BR: {glibc,libstdc++}-devel some necessary logic
which needs to be implemented, however to be fully working it needs
few other things to be added.
Possible modified solution: use something like BR:
{libc,libstl++}-devel may be still better as it hides compilers BRs.
Problem is till that exact libc and standard C++ library + C/C++
compiler BRs should be part of the build env settings (somehow).
How exactly to hide the details of the build env details I'm still not
100% sure ..
Flagging something as proposal does not mean that what was described
is complete and consistent. It is more or less only discussion entry
point.
Whatever would be chosen after few cycles of proposals would require
some minimal tests as well.
No one so far done such minimal tests.
Generally speaking issue is that real discussion started only now when
so far was no real discussion and changes has been done. Even if such
discussion would reach some kind of agreement of possible (few)
alternative solutions some set of test how it would be working would
be required.
Instead have a discussion<>tests iterations we had only kind of "ex
cathedra" announcement and mocking discussion.
Someone who is the owner of the original proposal (in this case Igor)
should be at least collecting possible options and at least time to
time sending partial pros/cons analyses as well. In reality nothing
like this has been conducted.
Instead spending last 4 months on such discussion and tests most of
the people had impression that proposal have been abandoned
(definitely I can say that it was my impression).
Even FESCo verification of whole procedure did not worked as it should
here because no one held/froze this proposal as something without
proper proposal/tests design at least few cycles.
Everything happened when some prev FESCo team cadence finished and
probably new team assumed that procedure has been overlooked by p[rev
team.
Do you see whole context now?
Seems that generally putting explicit gcc BR had some disk space and
build time cause. As so far there is no confirmation that published
number of packages and used disk space numbers where not been
generated with rpm settings have't been generated with proper lang and
exclude doc install options it points that possible technical options
focused on time and disk space metrics not been analysed correctly.
In other words proposed change cause had *nothing to do with any
packages dependencies|*.
No .. goal was to *reduce used disk space and reduce build time*!!!
I'm almost sure that definitely exclude doc option isn't in use
because still at least few @core packages have buggy %post/%postun
scriptlets should be showing some install errors when --excludedocs is
used.
What makes me a bit more angry about not checking those other possible
(without touching even single spec file) options is related again to
Igor person as many months ago he took my still not finished remove
all info pages index updates proposal pushing texinfo file trigger git
PR without finishing such change by remove all info pages indexes
updates from all possible packages with info pages documentation. As
we has proven packager perms he just pushed his own changes without
discussing anything with me and texinfo package maintainer and washing
hands after all that all what was necessary to do has been done :-L
At the bottom I want only flag that people like Igor as they have
proven packager perms are able to make at the end more harm than good.
I don't know him (how experienced developer he really is) as my only
personal contact with him was when on IRC he asked me where my texinfo
PR and bugzilla ticket are.
If some wide changes so badly prepared and conducted will happen again
IMO someone at least should consider withdraw his proven packager
privs.
kloczek
PS. And really I don't care that again above will be taken as kind of
personal attack (which is not my intention).
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/R5A3N5IHIEMOV6WGXAFVW4AMRM7UWYYP/
