The reality is that I don't have the resources to track down all of the packages that have these issues and fix them. I thought that I was doing the right thing (tm) for ORBit2, and now I'm happy that this discussion has taken place and that we've decided that this is the way we're going to handle this.
I guess the process will be to rebuild everything ASAP, don't make changes while doing so (unless obvious). Then go back and fix the packages that are causing the issues.
The 2nd part will be time consuming, require quite some expertise and some convincing of a number of people....
So you already know it will be time consuming and require expertise. That's what we lack for now. Testing all functions in those programs to find out which is broken and which is not -- I really don't think it is very feasible, unless some people volunteers to dedicate their spare time to it. Especially when you want to know when, how and why it is broken, write everything down, and wait for others to confirm.
Agreed. Adding the dependencies itself (rebuilding with rpm 4.2-7mdk) won't really hurt. Just that more software will be installed...That's why I'm suggesting a lighter barrier, which would leave all (or almost all) such packages intact for now. Warnings can be issued to maintainers, who fixes them when they have time. After that, we can have more strict barrier without worrying which package is broken.
I would like something like this to be implemented in rpmlint.For now, if it is still decided it's better to break those packages first and search for faults later, I wouldn't insist the opposite, and will help finding bugs. That's up to everybody to decide.
Btw, when the .so problems are fixed, will the scripts warn about that, and tell people to move those .so files back from -devel package to normal package?
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
