Previously Peter Moulder wrote: > Please re-read the above paragraph. No-one has claimed that a circular > dependency is needed.
That's the whole reason for this discussion though.. > They are allowed by dpkg, whereas current policy says that they are not > allowed, hence giving false confidence that no cycles will occur and thus > that one's Depends line will always be honoured wrt ordering of > configuration, which may turn out not to be guaranteed if a cycle exists, > even if no such cycle exists at the time one releases one's package. dpkg specifics and policy will also differ. dpkg is more then just an implementation of parts of Debian policy and at points will support more then policy allows. > There are many examples of pairs (A,B) such that: > - A is a package. > - B is a package. > - In order for A to be usefully be used at time T by users on a given > system S, B must be in an installed & configured state on S. > - It doesn't matter whether A is configured before B, or B is > configured before A. Right. This is the most common case I suspect. Now we could support this in dpkg, but: * that would mean adding yet another package relation type and people already seem to have difficulty enough handling the current set properly * it would only be really useful for a really small set of packages in Debian So the questions becomes: is it really worth it to add this? Wichert. -- _________________________________________________________________ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
