On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan <ramana.radhakrish...@foss.arm.com> wrote: > > Sorry about the obvious (possibly dumb) question.
> Can't we just import a copy of dejagnu each year and install it as part of > the source tree? TL;DR: No. We could, and indeed, some people do engineering that way. We instead depend upon package managers, software updates and backwards compatibility to manage the issue. This is generally speaking, a better way to do software. In the olden days, back before shared libraries, X11 was the straw that broke the camels back. Without shared libraries, everyone replicated large portions of the X11 system inside each binary causing a massive bloat just in terms of disk space. This cost was also reflected in distribution size. As multiple binaries were run, each program would replicate all the code and read only data of the X11 window system causing larger than optimal usage of ram. The problem was so fundamental and so compelling to fix that dllhell[1] was born. It was the price we paid, for the solution to the original problem. Now, the good news is that dllhell is trivial to avoid and engineer around so that it doesn’t exist. People that can program their way out of a paper bag can do it without even thinking about it. So, where we are today, it is a non-issue as it is a solved problem. Since it is solved, we don’t need to do things like unshare programs, libraries, kernels or executables anymore. Indeed, it is so completely and fundamentally solved that we can now use the desire to unshare as an indicator that someone in the food chain doesn’t have a clue what they are doing. Windows is notorious for instances where people have not yet attained the right skill set yet. In our case, since we can contribute anything we want, to any package we want, because we are open source, we can avoid, fix and do the good engineering required to avoid dllhell. This makes it so that fundamentally, we never have to unshare, by design. This is but one benefit of open source. One day, we will advance and configure && make will automatically fetch and install the required components that we need for a build, using the single command that on every system, resolves dependancies and installs dependent software. We aren’t there yet, but, that is were we need to go. Once we get that, we should depend on it and use it, and never look back, then discussions like this never ever take place again, because the first person that wanted 1.5.3 would just put it in, update the 1.4.4 string to 1.5.3 and Bob’s your uncle. No discussion, no asking, no worries. That’s the path forward. The current problem is that everyone wants to solve the dependency problem with their own tool and that tool is different on every system. The entire software ecosystem would be better off if all these people contributed what they need to the design of a replacement and we all moved to one system. 1 - https://en.wikipedia.org/wiki/DLL_Hell
