1 |
On Tue, Jul 17, 2018 at 4:45 AM Michał Górny <mgorny@g.o> wrote: |
2 |
> |
3 |
> W dniu pon, 16.07.2018 o godzinie 13∶16 -0700, użytkownik Zac Medico |
4 |
> napisał: |
5 |
> > On 07/16/2018 02:26 AM, Michał Górny wrote: |
6 |
> > > The pump mode of distcc has been causing issues for years now, |
7 |
> > > and upstream does even attempt to fix it. Disarm the FEATURES so that |
8 |
> > > people do not have to do that themselves after discovering all the bugs. |
9 |
> > > --- |
10 |
> > > bin/phase-functions.sh | 17 ----------------- |
11 |
> > > man/make.conf.5 | 5 ++++- |
12 |
> > > pym/_emerge/EbuildPhase.py | 2 +- |
13 |
> > > 3 files changed, 5 insertions(+), 19 deletions(-) |
14 |
> > |
15 |
> > Maybe we should simply support RESTRICT="distcc-pump" so that |
16 |
> > incompatible ebuilds can disable it? I don't see that many bug reports |
17 |
> > about it, and a forums search turned up this recent thread which |
18 |
> > suggests that some people may be using it: |
19 |
> |
20 |
> I did. There are only two reasons you don't see them often: |
21 |
> |
22 |
> 1. because not that many people use distcc, |
23 |
> |
24 |
> 2. because when they do, they quickly learn how broken it is and disable |
25 |
> it. |
26 |
|
27 |
It's been just a month and a half since I rebuilt a Gentoo system with |
28 |
distcc-pump, and that system ended up running well. |
29 |
|
30 |
I don't disable distcc-pump quickly. At least not globally. I only |
31 |
disable it in packages that don't compile with it. |
32 |
|
33 |
> RESTRICT won't be helpful because distcc-pump is also capable of silent |
34 |
> miscompilations and indirect breakage. If you used it at least once, my |
35 |
> only advice is to rebuild your entire system. |
36 |
|
37 |
I believe giving a general warning whenever distcc-pump is used is |
38 |
enough. Users should be allowed to decide whether they'll use it or |
39 |
not. There are users who know when to use it, and are capable of |
40 |
managing build-time inconsistencies. |
41 |
|
42 |
Saying that distcc-pump is capable of silent miscompilations and |
43 |
indirect breakage I think is also an aggressive and ungrounded |
44 |
presumption. |
45 |
|
46 |
Also, if upstream suddenly decides to fix whatever needs to be fixed |
47 |
on this, it would need another request to put the feature back, which |
48 |
I find would be very hard to be granted. |
49 |
|
50 |
I also agree that making specific packages use RESTRICT is more appropriate. |
51 |
|
52 |
-- |
53 |
konsolebox |