On Mon, 9 Jul 2018 at 20:40, Tomasz Torcz <to...@pipebreaker.pl> wrote:
[..]
> > PS. It is second time when Mr. Gnatenko started doing things before
> > finishing the discussion.
> > I can only repeat .. congratulation.
>
> To be fair, his email was sent Date: Sun, 8 Jul 2018 20:46:26 +0200.
> And today is 9th of July, so it is tomorrow.
>
> But yeah, doing the changes in the middle of a discussion… that's not
> excellent.
Technically you are right. Email has been sent at 8 July 8:46 p.m. (US time)
My comment was at 9 July 10:15 a.m. however first changes in git
started about 2h later.
I've spend a bit time to have look on the wiki. It started at 14
February 2018.
I remember some discussion about gcc BR 2-3 years ago but IIRC it was
not final conclusion or proper justification.
After Feb this year few comments have been posted but .. Kevin Kofler
opinion have been ignored.
Jan Kurik proposal going to avoid explicit gcc/g++ dependency by use :
"BuildRequires: %{__cc}
or:
BuildRequires: c-compiler"
was kind other solution to not have static dependency. However I think
that dependencies hooked to {glibc,libstdc++}-devel could be slightly
better because such solution hides completely compiler dependency (but
IMO even something like this was better and would require more
analyse).
Actually %{__cc} and %{__cxx} dependencies may be not so bad ..
however as long as gcc does not require glibc-devel and gcc-g++ does
not require libstdc++-devel still it is kind of hole here and this is
not 1:1 equivalent of the {glibc,libstdc++}-devel gcc/g++ Requires
.added only to those two packages.
At the end hanging all on {glibc,libstdc++}-devel or %{__cc}/${__cxx}
will be only matter of taste.
Both variants are equally good as they are not using straight gcc/gcc-g++ BRs.
https://bugzilla.redhat.com/show_bug.cgi?id=1551327 points to the wiki.
Additional it is ref to https://pagure.io/releng/issue/7317 on which
is as same hard to find anything more.
In any emailed notifications cannot find any deadline (quite possible
that it has been posted somewhere).
Such change has relatively big impact and seems to be following
https://fedoraproject.org/wiki/Changes/Policy
However cannot find anything on
https://pagure.io/packaging-committee/issues?status=Open&search_pattern=gcc
(but maybe it does not show anything because tickets are not indexed
only).
Only post which I found on devel-announce was +4 months ago
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/HBOXJYEOLT4J2B4OFVZAAJLRTBBL4MR4/
and originally was posted with so little details that it was easy to
loose it from radar.
Maybe it is only my impression that decision making process was at
least not enough transparent or at least properly fagged.
Generally recently more and more such changes in Fedora is made
completely not transparently, like start discussion about approve
upgrade community-mysql to 8.x when already such change has been
pushed to git and build systems .. all with ignoring whole impact of
the upgrade and still unresolved issues with 5.7.x -> 8.0.x upgrade
(however no one really cries because I'm betting that number of
community-mysql users is not more than few).
community-mysql case is especially strange as in BTS ticket
https://bugzilla.redhat.com/show_bug.cgi?id=1573642 still hangs as not
closed (looks like using ostrich tactics).
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org/message/UY57YSA2FZPMPPA6Y7E26W7464RG6QHR/
