On Sat, 2012-06-09 at 15:26:06 +0200, Andreas Barth wrote: > * Henrique de Moraes Holschuh (h...@debian.org) [120609 02:31]: > > We'd just have to teach the tool to binNMU all arches when the target > > package would need it due to multiarch. Release team requests a binNMU of a > > package for some arch, the tool notices it has to do them all because of > > multi-arch constraints, and replicates the request for all other arches. > > Just that this won't do it, because the changelogs for the different > arches will be binary different, so no win. > > However, we discussed that during the multi-arch bof last Debconf, and > came to the conclusion that it would be better to not modify the > changelog as we do now, but instead create a new file > changelog.$arch.$version with the binNMU. This is a bit more > complicated because it can't be done as of now just within the source > package.
As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. This has (at least) the following advantages: * no need to concat different files to get the complete changelog. * the version in the changelog would match the package binary version. * the changelog file would *always* get to be referred by the same name regardless of the package being native, binNMUed or otherwise. * changelog extractors (like apt-listchanges) would not need (eventually) to extract the whole .deb data member to get the changelog, it would just need to extract the control member, and get a fixed filename. They would stop needing to hardcode possible paths to the files too. This still leaves the NEWS.Debian file but then maybe that should also be considered metadata... * dpkg can gain new commands to return/show these files reliably w/o needing (eventually) to hardcode the distribution's specific path (which is a matter of fileystem policy dpkg does not really need or has to know). * dpkg eventually could do a way better job at reducing duplicated data, by for example transparently hardlinking them, instead of our ad-hoc doc dir symlinking. * dpkg could reduce space usage by transparently compressing them with something better than gzip. * (minor) it's a common pattern to want to exclude all of /usr/share/doc/pkg but the copyright file, storing it elsewhere would avoid that. To that end, last month I cooked a preliminary patch for dpkg to add two new commands: --show-changelog and --show-copyright, that take a package name and print to stdout (through a pager if on a terminal) either of those files, and fallback to a configurable set of paths on the filesystem if the requested file is not in the database (decompressing them if need be). regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
