| 1 |
On Wed, Sep 12, 2018 at 8:23 PM Chí-Thanh Christopher Nguyễn |
| 2 |
<chithanh@g.o> wrote: |
| 3 |
> |
| 4 |
> Rich Freeman schrieb: |
| 5 |
> >> Requirements: |
| 6 |
> >> |
| 7 |
> >> * Do not fail to build/install when a warning is encountered |
| 8 |
> > |
| 9 |
> > On a particularly critical package like a filesystem, wouldn't we want |
| 10 |
> > to still fail to install when a warning is encountered? |
| 11 |
> |
| 12 |
> Installation will proceed, but the user will get a big fat warning that the |
| 13 |
> sys-fs/zfs package is potentially broken. |
| 14 |
> |
| 15 |
> > I get that users might quit if packages don't install, but I'm not |
| 16 |
> > sure that a filesystem corruption is going to make them any happier... |
| 17 |
> |
| 18 |
> If the user recognizes this as a critical package, then they can do the |
| 19 |
> research before deciding on whether to use the package as is, attempt to |
| 20 |
> downgrade, or wait until a fix is released. |
| 21 |
|
| 22 |
But, you've ALREADY overwritten the previous version of the package |
| 23 |
that presumably didn't have this problem. What if downgrading doesn't |
| 24 |
cause the problem to go away? What if it is due to some dependency or |
| 25 |
toolchain change? Users would presumably want to roll back to the |
| 26 |
binaries that were working just a few minutes ago, not build new ones |
| 27 |
that might or might not have the same issue. |
| 28 |
|
| 29 |
-- |
| 30 |
Rich |
Archives