Donnie correctly commented that my earlier proposal is not really a solution that can be proposed upstream. It’s true, it isn’t really upstreamable at all. But I don’t think that’s a problem on its own.
The problem here is that most of these issues are most likely to be present in software that is not being actively developed, for which getting to upstream is nearly impossible. Other parts of it are caused by software that simply doesn’t have a build system at all, and just ships the .c files (like the piechart tool I found the other day), which also is probably unfixable since upstream decided not to provide a build system in the first place.
But, even if we were to decide to actually go this route for the packages,it doesn’t stop us from trying to contact upstream and propose them to get their build system fixed by either using autotools for most complex stuff or providing a simple sample Makefile that works by our standard for the small stuff. But patching the Makefile in distribution, it’s likely a waste of time.
Unfortunately, as I wrote recently even the best coder can write a stupid build system, which is unfortunately very true. And some of them, like Ragel author demonstrated lately, refuse to use automake at all, even when they fail to provide the correct basic functionality needed for a distribution to package his software. The reasoning still baffles me by the way.
So yeah I think this is a point that really needs to be faced with open mind, and a knife between your teeth to use against the most clueless of upstreams!
Sounds not bad. One solution to this would be to make a webpage that displayed all ebuilds that inherited this eclass. This would be subject to peer review and likely to be subjected to “hey, upstream is alive send something upstream” etc.