W dniu wto, 17.07.2018 o godzinie 23∶11 +0800, użytkownik konsolebox napisał: > On Tue, Jul 17, 2018 at 4:45 AM Michał Górny <mgo...@gentoo.org> wrote: > > > > W dniu pon, 16.07.2018 o godzinie 13∶16 -0700, użytkownik Zac Medico > > napisał: > > > On 07/16/2018 02:26 AM, Michał Górny wrote: > > > > The pump mode of distcc has been causing issues for years now, > > > > and upstream does even attempt to fix it. Disarm the FEATURES so that > > > > people do not have to do that themselves after discovering all the bugs. > > > > --- > > > > bin/phase-functions.sh | 17 ----------------- > > > > man/make.conf.5 | 5 ++++- > > > > pym/_emerge/EbuildPhase.py | 2 +- > > > > 3 files changed, 5 insertions(+), 19 deletions(-) > > > > > > Maybe we should simply support RESTRICT="distcc-pump" so that > > > incompatible ebuilds can disable it? I don't see that many bug reports > > > about it, and a forums search turned up this recent thread which > > > suggests that some people may be using it: > > > > I did. There are only two reasons you don't see them often: > > > > 1. because not that many people use distcc, > > > > 2. because when they do, they quickly learn how broken it is and disable > > it. > > It's been just a month and a half since I rebuilt a Gentoo system with > distcc-pump, and that system ended up running well. > > I don't disable distcc-pump quickly. At least not globally. I only > disable it in packages that don't compile with it. > > > RESTRICT won't be helpful because distcc-pump is also capable of silent > > miscompilations and indirect breakage. If you used it at least once, my > > only advice is to rebuild your entire system. > > I believe giving a general warning whenever distcc-pump is used is > enough. Users should be allowed to decide whether they'll use it or > not. There are users who know when to use it, and are capable of > managing build-time inconsistencies.
Sure, provided that they are warned that any suspicious bug reports will be rejected. Developers have better things to do than try to figure out whether some unmaintained-for-years, half-broken feature may have been the cause of a misbehaving system. > > Saying that distcc-pump is capable of silent miscompilations and > indirect breakage I think is also an aggressive and ungrounded > presumption. It's not a 'presumption', it's experience. Yes, it's possible that the breakages I've seen don't happen at the moment. But given the generic idea that distcc-pump can cause configure checks to misfire without actually causing build-time breakage, it's entirely possible. > Also, if upstream suddenly decides to fix whatever needs to be fixed > on this, it would need another request to put the feature back, which > I find would be very hard to be granted. > > I also agree that making specific packages use RESTRICT is more appropriate. > -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
