On Tue, Feb 02, 2016 at 12:22:27PM +0100, Michael Ströder wrote:
Daniel Morris wrote:
On Tue, Feb 02, 2016 at 08:29:15AM +0100, Axel Braun wrote:
Am Dienstag, 2. Februar 2016, 08:25:20 schrieb Michael Ströder:
Personally two things annoying me: 1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
+1 if someone is really interested in details, reading the changelog upstream should be sufficient.
-1 That requires a user to download the upstream package independently just because the packaging process has intentionally truncated or abridged the information - "updated from upstream" is about as useful as the "fixed some bugs" message popular on some mobile appstores.
It's not a big deal for a package foo to add the upstream changes file in /usr/share/doc/packages/foo
But that only works post-install, and I'm not sure it is safe for multiple versions of foo. Out of curiosity, from 2108 rpm packages installed on this tumbleweed system, 1128 have a directory under /usr/share/docs/packages and 329 of those have a (case insensitive) file named changelog.
Or am I misunderstanding how an end-user is supposed to inspect/query what has changed in a pre-built package using the tools provided by the package manager?
Could you please elaborate on what's an "end-user"?
Great question - in the broadest terms I expect the prospective or actual consumer of a piece of software that has been pre-built and distributed in the RPM Package Manager format :) That might include a user who is happier using a graphical front-end to either inspect software on an existing system or is looking for new/newer great software. As well as those that might want to sanity check what whizo feature $BLING is likely to come, maybe with some potential breakage/interaction ahead of installation from a command line with something like 'rpm -qp --changelog foo-x.y.z+3.rpm'. Right through to the poor sysadmin firefighting in an unconnected inhospitable windowless void wondering why a twenty year convention of passing --changelog into the RPM packaging tools returns "updated from upstream" after $EXsysadmin caused some breakage on a production system that wasn't supposed to be changed. I'm sure there are other types of end-users too. Is there concensus in the LSB & RPM specs for what is the intended and/or expected behaviour? Does the map match the terrain? Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org