On Fri, 2005-07-29 at 20:08 +0200, Sven Mueller wrote: > > Ouch! I see. Being a math type person I tried to see > > if there were a proper extension. However I didn't > > go back to consider whether Debian itself was broken. > > > > The assumption here is that Conflicts is a symmetric > > relation: if A conflicts with B, then B conflicts with A. > > It can't be like that, take this example: > When X enters the archive, Y doesn't even exist yet (let alone it being > in the archive). X could be (for a real world example) lvm-common. > Now when Y (udev) enters the archive, it conflicts with lvm-common. > However: Why should a new package of lvm-common be created? It's quite > sufficient that the conflict is defined in one direction _because_ the > relation (in itself) is symmetric. I agree, I think it is just misunderstanding of the wording. The mathematical relationship of 'confliction' is symmetric. 'Mutual exclusion' is probably a better name. This relationship may be *declared* in one package unilaterally. This means where A conflicts with B may not be known just when A is installed, as you point out, B, which contains the 'Conflicts: A' declaration may not even be in the archive. This does not matter luckily. The invariant "Conflicting packages cannot simultaneously be in the state 'installed' on any machine" holds 'in vaccuuo' when B does not exist in the archive. It is only when a B is put in the archive and a client attempts to install it, that the invariant is threatened, and therefore either the install attempt must be refused, or, A must be un-installed to allow the install to proceed. This situation *already* works with the existing package management. Today you cannot install a package which declares a conflict with an already installed package. The problem is that you CAN install a package B which declares a conflict with A, and then install A, which does not declare the conflict. The conflict exists, nevertheless. Again note my assumption that 'confliction' relation is symmetric: it is indeed intended to mean 'mutual exclusion'. It is perfectly possible to have an non-symmetric relation, which simply implies the existing semantics: If you want to install both A and B, you must install B first. This relation is surely useful: for example, suppose BOTH A and B use a shared configuration file, and suppose A will add things to an existing file but not make changes, whereas B just clobbers any existing file and installs its own, then to make both A and B work, you have to install B first. So the relationship which IS currently implemented is useful, but it is NOT a symmetric mutual exclusion relation, and implementing that relation is absolutely essential for any package manager, simply because there really DO exist packages which must not be simultaneously installed. So there is no choice really: if we want Debian to be consider a 'good' package manager it MUST implement mutual exclusion relation somehow. Again note there is a distinction between mutual exclusion (mathematically) and how that relation is declared: clearly, unilateral declaration of exclusion also 'MUST***' be supported, since A can be designed before B: it should NOT be necessary to declare an exclusion in both packages for historical and maintenance reasons. Well, the 'MUST***' above is my opinion only. Clearly, two packages A and B, each of which announces a Conflict with the other, will already provide mutual exclusion: I simply think requiring this is untenable, due to the way software is developed: a maintainer of a package B finding a mutual exclusion with a package A should be able to declare that exclusion unilaterally *without* having to file a bug report against A: there is no bug in A, it simply doesn't know about B. Of course, perhaps they can file that bug report, and if an end user finds a conflict, they might file a bug report against BOTH packages. Still, it would be hard to convince the maintainer of a MAJOR package such as gcc, or the kernel, or some other thing most people have, that it should declare a conflict with a new experimental package: the maintainer of the experimental package should do that. IMHO: Debian will be well served to provide mutual exclusion from a unilateral declaration. Actually this opens the issue: how to ALSO provide sequencing -- which is already implemented and called 'Conflicts'. A bad name IMHO, however we could live with it if another stronger relation could be announced, for example like Package: B Excludes: A This is the same as: Package: A Conflicts: B Package: B Conflicts: A the difference being entirely that it is provided unilaterally. That actually may be a better solution, since it is an extension, not a change (however then the word 'Conflicts' is a bad name, because Package: A Conflicts: B really means "B must be installed before A", rather than what the word suggests to me, namely, mutual exclusion. -- John Skaller <skaller at users dot sourceforge dot net>
Attachment:
signature.asc
Description: This is a digitally signed message part