Re: [PATCH 1/3] Introduce gdb::unique_ptr

[Eli Zaretskii <eliz at gnu dot org>]

> Cc: jan.kratochvil@redhat.com, brobecker@adacore.com,
>         markus.t.metzger@intel.com, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Thu, 13 Oct 2016 14:35:58 +0100
> 
> >> The newer compilers available as packages on these old distros
> >> (e.g., DTS on RHEL) do _not_ replace the system compiler.  They're
> >> installed in parallel, in separate directories.  You willfully add them
> >> to the PATH or pass an overridden CXX to configure/make if you want to 
> >> use them.
> > 
> > I don't see the difference, except for the worse: instead of one
> > compiler you now have two, so one could easily select the wrong one
> > when compiling some package.
> 
> You said:
> 
>  "upgrading the system compiler is a serious decision.  Installing a
>  newer compiler could easily break the build of several important
>  packages (...)"
> 
> And I'm telling you that the packages in question don't upgrade
> the system compiler at all.

Of course, they do: you have a newer compiler on your system, which is
about to be used for building some packages.

> There's no risk of "easily break" things.

Of course, there is: the new compiler will do that.

That one can go back to the old one doesn't help at all, because that
was also possible without a parallel installation: just uninstall the
new one and install back the old one.

Organizations rarely do this stuff.  You want to install a compiler
and let users use it without complications.  Most of your users aren't
hackers, they have no idea how to debug a package build problem.  They
will come back to you expecting that you fix the problem for them.

> There's nothing complicated here.

I respectfully disagree.  We most probably have very different
experience here, and very different users to deal with.