Il giorno mer, 26/07/2006 alle 16.48 +0200, Goswin von Brederlow ha scritto: > > Conflicts on virtual packages assure that two real packages providing > > the virtual one can't be installed togheter, so let's say: > > > > A: provides D; conflicts D > > B: provides D; conflicts D > > > > It is not possible to install both pkg A and pkg B because both provide > > pkg D and the other package conflicts with it. If we replace D with A, > > and remove the self-conflicts/self-provides, the situation would be: > > > > A: nothing; > > B: provides A; conflicts A > > > > ... which produces the same result, because you can't install both A and > > B because B conflicts with (the real package) A. > > > > For me, self-conflicts make no sense in every situation. > > Say your "A" package gets renamed to (or is named) "D". "D" then still > has to conflict "D" so "B" can't be installed in > parallel. exim4-config is an example of such a case.
I don't understand if you talk about my first example or about the
second one.
If it is the first, then D doesn't need to conflict on itself: it won't
be installable because "B" already conflicts with it.
I don't see neither why exim4-config is an example of such a case: there
are no packages in the archive which provides exim4-config, and even if
they would exists, they would conflict with exim4-config so they won't
be installable in parallel.
The conflict work also if just one of the two involved packages declares
the conflict, or not?
Cheers,
--
Fabio Tranchitella <[EMAIL PROTECTED]> .''`.
Proud Debian GNU/Linux developer, admin and user. : :' :
`. `'`
http://people.debian.org/~kobold/ `-
_____________________________________________________________________
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
signature.asc
Description: Questa รจ una parte del messaggio firmata digitalmente
