| 1 |
On 14-09-2018 16:29:43 -0400, Rich Freeman wrote: |
| 2 |
> On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky <mjo@g.o> wrote: |
| 3 |
> > |
| 4 |
> > On 09/14/2018 03:58 PM, Richard Yao wrote: |
| 5 |
> > >> |
| 6 |
> > >> No one has answered the question: what do you do when a stable package |
| 7 |
> > >> breaks because of a new warning? |
| 8 |
> > >> |
| 9 |
> > >> ...> |
| 10 |
> > > Wouldn’t this be largely covered as part of GCC stabilization? We could reserve the right to kill -Werror in a package where it blocks GCC stabilization if the maintainer does not handle it in a timely manner. |
| 11 |
> > >> |
| 12 |
> > |
| 13 |
> > They would be uncovered during GCC stabilization, but then you're right |
| 14 |
> > back in the original situation: how do you fix the stable package? The |
| 15 |
> > only answer that doesn't violate some other policy is to patch it in a |
| 16 |
> > new revision and wait for it to stabilize again. |
| 17 |
> > |
| 18 |
> > Other questions arise: Do we block stabilization of clang et al.? |
| 19 |
> > |
| 20 |
> |
| 21 |
> Presumably we could make it a blocker, so then portage won't install |
| 22 |
> the new stable toolchain. That buys time and only affects users of |
| 23 |
> that particular package. But, as I pointed out before you can do that |
| 24 |
> without using -Werror - just block installation with an unqualified |
| 25 |
> toolchain. |
| 26 |
> |
| 27 |
> You would only use an approach like this for packages where QA was |
| 28 |
> fairly important, so the inconvenience would be worth it. |
| 29 |
|
| 30 |
Perhaps, if one persists on going this route, only do this for platforms |
| 31 |
that upstream supports, such that arches which will suffer from this |
| 32 |
(typically ppc, sparc, ...) don't have to be blocked by this. |
| 33 |
|
| 34 |
Fabian |
| 35 |
|
| 36 |
-- |
| 37 |
Fabian Groffen |
| 38 |
Gentoo on a different level |
Archives