Hi, Jakub Wilk wrote:
> How about: > * Because this the obvious and elegant way of doing things. It makes > multiarchification easy for packagers, and invisible for uses, > including those users who don't care about multi-arch (unless they > rely on paths to the libraries, which they never should do). I suppose that is a matter of opinion. The need to make sure files that are not arch-qualified match at least functionally between architectures is subtle and not very easy. Tying package versions in different architectures, which makes dependency chains more rigid, is not invisible to users. However, in the special case of header files (which are text files that almost never vary between architectures), I agree that it would be nice to be able to preserve the simplicity of the current approach from the packager's perspective. [...] > By allowing co-installation of two different versions of the same > package, you are opening a can of worms, regardless of whether > refcnt is implemented or not. Could you elaborate on this? As long as dependencies are accurate, I don't see how allowing co-installation of the same package for two different architectures at different versions is any more complicated than pinned to the same version. [...] >> * Once implemented, this “feature” cannot be taken out, *ever*. > > This boils down to “I don't like it”. If it's useful, why would one > consider taking it out? After trying out the approach without refcounted files for a while, it would be painless for the project to say "This is too much trouble" and add refcounting. By contrast, it is very painful to move in the other direction. I think that is worth taking into account. [...] >> Proposed solution [...] > This will require changes to the Policy, to which I (and hopefully > other developers) will object. Last time I checked, multiarch is not in policy yet. > Please don't throw into the mud work of individual developers > (including me) who already converted their packages to multi-arch. I agree that the extra work of removing "multi-arch: same" for existing -dev packages that have been converted is a major downside. And on the other hand, the need throughout Debian infrastructure to support the very fragile refcount approach would be a downside to that approach. This is not so one-sided as you seem to be suggesting. Jonathan who wishes he knew of a fifth approach without the downsides of the others proposed so far :) -- 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/20120211005559.GA32671@burratino
