Evgeni Golov wrote: > after reading #759590, I think it is time to consider calling maintainer > scripts in a (slightly) cleaned environment. Since I submitted Bug#759590 (however not the apt interaction aspect of it) let me say that I consider the ability of inheriting the environment for PATH and LD_PRELOAD to be a feature. I would find it a tragedy if the bug under discussion caused this feature to be removed. > That wouldn't be too bad (noone runs their production servers with > eatmydata), if the eatmydata LD_PRELOAD would not leak into running > services because they are (re)started from maintainer-scripts which get > the environment from the running apt. There is a long chain of unintended consequences in this problem that created a need for eatmydata. I fear mentioning the chain because it will reopen old wounds. So I won't. But I vote not to continue the chain of unintended consequences by further modifying apt or dpkg. The logical progression would be that dpkg would get an environment file where these settings would be set in order to accomplish the same result. Because there is a need for the capability. If it ends up being prevented one way then it will need to be enabled in another way. In the end nothing would change except that it would be more painful, more rigid, more fragile. I see the bug that is affecting eatmydata plus gnutls28 to be a simple bug like many others that we see. It is not that big of a deal. It happened. It was detected. It has been partially debugged. Anyone affected has a workaround while we continue to pursue the details and finish up. I am confident it will conclude positively before release of Jessie. This only affects people wanting to use eatmydata. Anyone not wanting to use eatmydata is not using it and is not affected. > There is an old, wont-fix bug in dpkg about this: #18567, the > corresponding discussion on -devel [1] agreed, that overriding $PATH is > an useful argument against just cleaning the whole environment and > hardcoding $PATH to something general. Yet I think there are vars I'd > like not to have inside my running services and also not during other > tasks inside of maintainer-scripts. I think systemd already does this, > but I'd love a more generic solution for the "problem". If an admin has made local changes then it only causes a local problem. It isn't a systematic problem that everyone will experience. The majority of simple and default users will never see the problem. That limits the scope of the issue. It doesn't feel like a global general Debian problem. It feels very local and contained. Only those with customized environments will be affected. And of course any of us with customized environments are doing so because that is what we want. We want those customized environments. Trying to keep us from having those customized environments won't prevent us from having them because humans are clever and will find a way to do what we want anyway. It simply makes it more painful for us to have them. Therefore I think if an admin sets up a custom environment that this environment should be used. Or at least not actively prevented from being used. Bob
Attachment:
signature.asc
Description: Digital signature