And you're not the first one to complain either. What I wonder: how can make sure the maintainer _knows_ about the changes of upstream? E.g. I updated exiv2 to a new version as I fixed gcc 4.4 compilation. And I did read through the changelog, but still I didn't spot the little "[design] Publish only API objects in the installed header files." - which broke a dozen other packages.
No change here, IMHO. Speaking just for myself: Reading the changelog carefully has nothing in common with producing the food for our RPM changelog - when there is a ton of changes in upstream and they seem to be quite equally important, I just choose some from the beginning and voila, work is done. If I missed some catch during the actual reading, I will not pick it up during writing RPM changelog. So youd did not make sure I know about it anyway. (At least in my case, you did much worse in fact: knowing that I will have to spend lots of time moving the text here and there, I will be actually _less_ careful during reading.) BTW, I think I would be really not to blame. It is upstream responsibility to mark backward incompatible changes so that they can be easily spotted in the changelog. They usually do it. If they do not, it is upstream bug, not my fault. Sure, it will not help us that much when we are going to fix the problems we could avoid. But if we read the diff between two versions carefully instead of a changelog, we could avoid all the problems, not only these that upstream already found ;-) Anicka -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org