I don’t mind tearing into bad implementations of an idea or product. If the thing isn’t good, criticism can help focus where it needs to improve. The trouble with this is when the criticism arrives too late, or is rejected out of hand by those who would benefit most.
No, not being self righteous. I am just as critical of our stuff, our products and mis-steps as I am of others.
But the issue at hand is when criticism arrives too late, you have long-lasting echos to deal with, and then you have to work around poorly thought out designs, or poor implementations, … .
I am highly critical of RPM as a packaging system. It, honestly, tried to re-invent the wheel.
If you are going to do something like this, it is far better to invent a better wheel. Not one which is square. Sadly, this is what RPM has become. Look at recent spec files to see what I mean, as the spec file authors have to do backflips in the non-programmatic programming language that is RPM.
If you are going to make it better, then, by all means, make it better. Not worse.
FWIW: I am currently fighting a new/upgraded RPM packaging system that takes an RPM that has built so nicely in the past on RHEL3-RHEL4, SuSE, … and now breaks it. Well, ok, the packaging breaks.
Yeah. It is so helpful. This is a very simple spec file, nothing special. We built RPMs from it before, been building them with this for ~3-4 years. Now we have to find yet another way to work around this. Ok. I will. I’ll fix the package (e.g. make changes) such that it won’t tickle the obvious bugs in the packager. This is helpful … how? Wouldn’t it be great to turn off the strip command? How? Google doesn’t seem to have it. Sadly, it is going to look something like this
or other such magic incantation.
Yes, it is so obvious how to turn this off. The echos of a bad design continue for years.