| 1 |
On Sun, Sep 9, 2018 at 1:50 PM Michael Orlitzky <mjo@g.o> wrote: |
| 2 |
> |
| 3 |
> So if you're using -Werror to prevent a |
| 4 |
> "vulnerable" package from being installed, it doesn't work, and can |
| 5 |
> actually be harmful if it prevents me from using a better compiler. |
| 6 |
> |
| 7 |
|
| 8 |
Whether or not the new compiler is better, it is clearly untested with |
| 9 |
the package-version in question (otherwise these warnings would have |
| 10 |
been addressed). For something critical like a filesystem (zfs) that |
| 11 |
could be useful to know. |
| 12 |
|
| 13 |
I'm not convinced that this rule ought to be absolute. |
| 14 |
|
| 15 |
That said, I do agree with your later comments that this creates a |
| 16 |
messy situation by painting a user into a corner. Other than sticking |
| 17 |
painful ranged version dependencies on the toolchain into the package |
| 18 |
I'm not sure if there is a cleaner solution that guarantees that the |
| 19 |
package won't be built with a version of gcc that is untested with |
| 20 |
that specific package without a user override. |
| 21 |
|
| 22 |
I guess we could just have sensitive ebuilds output that it might eat |
| 23 |
your data if you didn't add -Werror to your CFLAGS and then leave it |
| 24 |
to the users to decide how much they care about build errors vs |
| 25 |
unlikely sorry-I-lost-your-10PiB-array errors. |
| 26 |
|
| 27 |
-- |
| 28 |
Rich |
Archives