Hi, On Mon, 13 May 2013, Guillem Jover wrote: > The binNMU issue entails two “sub-problems”. The first is the one > introduced by different entries in binNMUs on multiple architectures. > The other is the unmatched versions for possible out-of-step binNMU > versions. > > Personally I see very clearly what's the best/clean solution for the > first. For the second, I'm happy to declare it a “non-problem”, and > that it's what it is; if a package is M-A:same, then well, all arches > need to have the same version (as my proposal to not require same > version for M-A:same was shot down on the mega-thread in debian-devel); > as I've not seen any solution that does not complicate or uglify things > in very unnecessary ways, by way of revertig us back to having a > sort-of-revision in a different field, or hacking the version comparison > logic to special case binNMU-versions (ugh), etc.
I already suggested that we should compare the Source version instead for the case of M-A: same packages. Do you consider that ugly as well? For the changelog handling, I tend to agree with Guillem that moving it to control.tar.gz makes sense (and copyright/NEWS.Debian probably too). But ansgar's objection about the duplication of the changelog in multiple .deb when it used to be shared via a symlink also makes sense. As does the fact that there's currently no way to not install some control files. He also mentionned that having to fork dpkg to parse all changelog files is really not very good from a design point of view. It would be better if we already had a stable libdpkg that we could use to avoid those forks. It would also be nice to offer some transition periods with compatibility symlinks but that's not something that can be cleanly implemented outside of dpkg (unless duplicating the files is deemeed acceptable). Clearly, if we want to get some broader buy-in for this change, we must try to come up with solutions to those problems. For the compatibility symlinks, we can create a new binary package in the dpkg source that would set them up, keep them up-do-date, and drop them on removal. The other points are more difficult to solve but would be useful in their own to avoid the problem of small packages considered too heavy due to their meta-data. It might be worth to think a bit about it. What about allowing us to define some package like this in debian/control: Package: foo Extends: bar Description: <summary> This new "Extends" field would imply that all meta-data (including other missing control fields) is shared with the bar package and at build-time it transparently gets a supplementary "Depends: bar (= <foo-version>)" but the .deb would not have any changelog/copyright. (To further save meta-data space, we could have a way to factorize the part of the description that describes the source package) Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130514075931.ge10...@x230-buxy.home.ouaza.com
