On 22/07/2015 15:45, Steve Litt wrote:
http://www.troubleshooters.com/linux/politics_of_dependencies.htm
Yes, I had already read that, and agree with all your statements. But it's not the same thing here, because we're talking about a development tool. Not a dependency, not even a build-time dependency to a library, but a TOOL. Development tools *should* be kept up-to-date, no ifs, ands or buts. If they're not, working on development tools becomes completely irrelevant - if people can only use a tool 5 years after it's out, why even bother adding features at all ? You know I'm all for minimalism. I build some of the smallest production images in the world ever. The skarnet.org server could run with 64 MB of RAM, maybe even 32 MB if I didn't use it for some experiments and for development. I designed the whole freaking userspace on it and built everything by hand, so I know the cost of dependencies. But for package compilation, sorry, but I'm going to allow myself to depend on goddamn MAKE, whatever version I need to get the job done. You think building s6 is too hard ? Go grab a random package on GitHub, a totally random one, and try compiling it - make sure to have aspirin at hand first. Then you can come back and thank me for making it so easy with s6.
IMHO two years is way too stringent a requirement.
For a run-time dependency, or a build-time dependency on an external library that may itself depend on other stuff and make you pull the whole plate of spaghetti, yes, yes it is. But for a simple development tool such as make, which is completely basic, ubiquitous and easy to install and does not depend on anything, I'm standing my ground: it makes no sense not to be able to rely today on make-4.0 features. Distributions have a "security updates" feature, so they ARE able to provide software updates more often than churning out a full release once every three years. There's no reason why they can't use the same mechanism for major updates to widely used software. -- Laurent
