> > >>>#3) All requirements and the "why" of them should be documented for >>>any serious development project. If you can't document why you >>>included the requirement then it's not likely you know. And if you >>>don't know, then don't put it in there. Adding deps just cause it >>>"makes it work" is not software development, it's playing around. >>> > >This is better point though. Stefan, if you have added one more line >"configure requires /usr/bin/mcopidl" in the changelog then this >kind of flamewar may not occur right now. > I could do that, no problem. But: 1/ It'll drain a lot of my time and create long (useless?) changelog entries; 2/ When I modify the BuildRequires the resulting binary package is the same as the previous one. (I'm so suprised people make a big fuss about it);
I'd rather get some clarity about what BuildRequires are and that BuildRequires != Requires, ==> what the core of this flamewar is all about. Stefan >Of course, it doesn't mean one should document why 1+1=2, but for the >less comprehensible things, it's still worthy to write a note about it. > Eventually you could write an entry (in sesamestreet language) about every error you bumped into when fixing a package, it'll be lengthy and useless... I also don't see other packagers do it either, i.e. quite often I don't understand the changelog entries, but then again, I'm not very bright :-) Stefan
