On Wed, 30 Mar 2011, Jonathan Nieder wrote: > Well, I want to interpret it as meaning *something* --- though I'm not > filing RC bugs or anything. I had thought that the general rule is > that violating a policy "should" is always a bug (either in your > package or in policy), though not necessarily an important one.
When it's a technical rule true, here it's a matter of process. The reason we request peer review of Pre-Depends is that they have a cost and should not be abused. So when you want to add a Pre-Depends, you come to -devel and you say "I want to add this pre-depends because of X to achieve Y". Maybe someone else will respond "you can achieve Y by doing Z instead" in which case you should generally go for the solution Z because you can avoid the cost of the pre-dependency. But if nobody comes up with another solution to your problem, then by all means go ahead with the Pre-Depends... if it causes upgrade problems, the discussion might come back later but that's part of the way we work. But the maintainer is still the one who gets to decide what's done in his own package. In the precise case of multi-arch, the pre-dependency has already been discussed as being preferrable over any alternative solution. They have a higher cost due to stronger dependencies in all packages with binaries whereas this solution only requires multiarchified libraries to carry the pre-dependency. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
