On Tue, May 28, 2013 at 7:01 AM, Sascha Peilicke <speilicke@suse.com> wrote:
5. In rare cases changes of upstream code in case upstream code does not provide a detailed change log.
So you really want people to first download the RPM, unrpm it and then search for a ChangeLog or CHANGES or NEWS file? I think it is better to allow users to use the same process they already know, namely "rpm -q --changelog $foo.rpm" and get something meaningful.
I don't see the real difference. In case of package python-ldap the CHANGES file is installed here: /usr/share/doc/packages/python-ldap/CHANGES
Right, and in another package's case the file may be elsewhere and named differently or even lacking. How am I supposed to know that? Am I supposed to guess "Ah, there's no suitable changes entry, maybe I should go look for CHANGES/NEWS/ChangeLog/changelog or even NEWS.txt"?
Real question one should be asking, is how is a *tool* supposed to know? Because, missing manpower aside, YaST *should* be showing those upfront. So it's a matter of making it machine-findable (efficiently), besides human-readable. OSC *should* be able to point to a changelog relevant to a new build failure. It's non-trivial, but it'd be possible, *iff* the changelog was machine-findable. And machine-findable is as easy as making it standard. NEWS or CHANGES inside the RPM isn't (and IMHO can't reliably be) standard. Only the spec's changelog is. The changelog can point to a file inside the RPM. And that'd be machine-findable enough. And osc is python... um... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org