Greetings,
I hope everyone is having a good day. Here in the Fedora ARM project, we're having a great time overall, but we've run up against a familiar foe in our preparation for Fedora 17 and rawhide: superfluous deps in SPEC files. Today's example is a shell-escaped call to Ruby just to determine some gcc flags for an unrelated package build, but that's just today's example. There are many others, so some standard would help.
Why is this a problem? The most obvious issue is the superfluous dependencies, pulling in ruby (and all of its deps), for example. But the bigger problem for the distribution as a whole is that we are becoming less bootstrappable[0] over time, and we are suffering from dependency creep that makes life difficult for secondary architectures (or even for the primary architecture if a bunch of rebuilds were to fail and there were no deps to satisfy a circular path).
Eventually, the issue of dependency creep is going to bite the broader distribution. In the meantime, can we please impose some kind of rule surrounding which superfluous build deps are allowed? I'm not advocating for the removal of Ruby, Lua, and so on and a return to old fashioned shell, but I am suggesting that we cap where we are and try to avoid introducing any more bizzare build dependencies in the future. For example, say a package grew a SPEC file need for a call to an INTERCAL script just to determine gcc flags? It's not really all that different from calling Ruby to expand gcc flags and maybe I happen to like using INTERCAL over Ruby? Or why not have a hardware compiled state machine implement some custom logic to determine gcc flags? Maybe I find that easier than writing some good old fashioned shell, etc.
In all seriousness, can we please have some direction? If this is already implied or codified, could someone remind packagers to refrain from adding build dependencies like this? I'd recommend that, in general, if a one line shell escape can be used, that ought to be the preference over adding a one-line build dep on $random scripting lang.
Thanks!
Jon.
[0] Rebuilding the entire distribution from first principles, using nothing more than a toolchain to begin the process. We did this for Fedora 15 on ARMv7. I eventually would like it that Fedora be able to bootstrap itself on any architecture trivially, and I know Debian (and other distributions) are similarly keen to return to that world.