From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020326 Description of problem: RPM version 4.0.4 broke a lot of our software. Our installers, notably the ones on the CDs we printed just awhile ago, no longer work properly for people who have updated to RPM 4.0.4, and we got angry phone calls and emails and bug reports and support incidents. Our developers had to stay up late and release new versions of our software just to support another microversion. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Make changes in the way that RPM interacts with other applications and in the librpm interfaces. Increment version number by 0.0.1 Release. Actual Results: Third party software breaks, customers get angry, ISVs scream, moan, cry, pull all-nighters, and post angry bugs. Expected Results: The application interfaces should remain stable between versions. Care should be taken to preserve backward compatibility. Additional info: I realize that this is a known issue, and that it's not really any of my business, but interface stability is a significant problem for ISVs and I sure wish you'd take better care to preserve backward compatibility.
Patches cheerfully accepted.
Jeff, you're a smart guy, and I know that you accept patches cheerfully and that you communicate well with the development community. But that's not the issue at all. Patches won't fix this problem. There is no upgrade that will solve it once and for all. There is a major issue with your development process and your maintainership, that is negatively affecting large numbers of Red Hat developers and end-users. Smooth upgrades, backward compatibility, and stable interfaces don't come from patches, they come from a sane development process with careful planning that takes your users, your ISVs, and your support teams into account. You seem determined to kick ISVs and support teams in the teeth here. Why?
This isn't a bug per say. It would be convenient to have a stable API, and this might be a good goal for RPM v4.1, but currently the API isn't at a state where it can be stabilized. Another option would be to create a second "wrapper" API, similar to the rpm-python bindings, but for C that was more stable. However, again, this is a longer term goal. I'm marking this a DEFERRED. Aaron, feel free to talk to me if you want to discuss this more.
I flagged this as beta to prevent reopening. Sorry for abusing the bugzilla privilege system. Thanks. Peter pzb