David Kalnischkies wrote: > APT for example (that it keeps working is because it treats itself special), > a texteditor or even something as simple as an internet connection…
Does upgrading these without immediately configuring break any of them? If so, that's a (pretty severe) bug. (However, I don't mean to say the idea of immediate configuration is not good for other reasons. On the contrary, I think it's good, especially as modified by the gsoc project you mention if I understand correctly.) [...] > Anyway arguing with the policy is a bit strange as APT isn't violating > the policy by applying a stricter view by default on a problem. > The policy defines the minimum - that is relatively easy to implement. > The problem is through that every small packaging bug can bring you > into a completely broken system state then… I think you misunderstood. Policy documents the meaning of dependency fields, package maintainer scripts, and so on, not as a specification of how dpkg and APT work (though it can sometimes vaguely approximate one), but as documentation for the technical requirements on Debian packages that use those facilities. Let's say a new package manager came along and started ensuring that all dependencies are satisfied at unpack time --- that is, all Depends are promoted to Pre-Depends. Absurd, right? But it would not be hurting what packages can rely on by declaring a Depends relation, so it seems kosher wrt policy, right? And in fact such a package manager would probably be fine, _except_ that relationships that were previously satisfiable (e.g., dependency loops) would no longer be satisfiable. Maybe we don't want to support dependency loops anyway; that could be proposed as a new policy change. Until then, breaking previously working packages without documenting the new requirements would be harmful and I don't think it's unreasonable to call such a change problematic. Of course the immediate-configure bit is both older and less drastic than that. Nevertheless it is a bug either in APT or in policy that this creates a technical requirement on Debian packages that packagers would have no easy way to learn about. Luckily you seem to have said there is a fix in the pipeline, so... :) Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
