Hi, On Tue, 14 Feb 2012, Guillem Jover wrote: > > * All packages that want to be multiarch: same have to move all generated > > documentation into a separate package unless the maintainer has very > > carefully checked that the generated documentation will be byte-for-byte > > identical even across minor updates of the documentation generation > > tools and when run at different times. > > If packages have to be split anyway to cope with the other cases, then > the number of new packages which might not be needed otherwise will be > even smaller than the predicted amount, at which point it makes even > less sense to support refcnt'ing.
Why are you so opposed to the refcnt'ing? It's not such a big deal to maintain this feature in dpkg. And even if the current implementation is not perfect, it can be improved later when dpkg will store by itself checksums of provided files. To me it looks like you don't like refcnt'ing and you're trying to find some reasons to make it unacceptable. > It also requires maintainers to carefully consider if the (doc, etc) > toolchains will generate predictible ouput. If the maintainer has to install files in non-standard path (because of the need to arch-qualify it), it will also need maintainers to carefully consider how to ensure that this move doesn't break anything. It's not a white/black situation. You're trading one potential problem for another. And the differing files are likely to be much more easy to spot than other behaviour changes that might be implied by the move of some files to arch qualified paths. > Your proposal still requires papering over the other corner-cases. Can you be explicit about which corner cases you're referring to ? > This still does not solve the other issues I listed, namely binNMUs > have to be performed in lock-step Can you explain why? If the binnmu changelog is in a arch-specific file, then we're free to bin-nmu packages separately. dpkg must just ensure that all "M-A: same" packages have the same source version (instead of the binary version as currently). >, more complicated transitions / upgrades. We have no experience on this. It's a bit early to say whether those constraints are going to be problematic or not. > And introduces different solutions for different problems, while my > proposal is generic for all cases. There's nothing like a generic solution. You still have to decide whether you move files to a -common package or if you arch qualify them and keep them in the M-A: same package. And in both cases, you have to evaluate the implications, in terms of package installation ordering in one case, in terms of modifications to do to properly support the arch-qualified files in the other one. While it may sound like "cleaner" from a theoretical point of view, I'm not convinced that it's better than the approach outlined by Russ. Also you completely ignore the fact that what you're proposing is an important change for multi-arch packages that have already been converted both in Debian and in Ubuntu. You're pushing back the work to package maintainers when there's not reason to not deal with this at the build infrastructure level. To reduce some of the downsides associated to compressed files in M-A: same packages, we could/should investigate how to not compress files in such packages instead of duplicating them needlessly. > So this is still pretty much unconvincing, and seems like clinging > into the refcnt'ing “solution” while it makes things overall more > complicated, will introduce inconsistency and incertainty to > maintainers, needs way more global changes to keep it going, etc. This is not a fair characterization of the situation. IMO "Global changes" are better than "lots of maintainers having to do busy-work splitting their packages". You see inconsistency in Russ's proposal but you don't see inconsistency/incertainty when you change the standard location of changelog files. And the "more complicated", it might be true at the dpkg level, but I don't believe that it's true from the maintainers points of view. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120214151318.ga14...@rivendell.home.ouaza.com