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 <kobold@debian.org> .''`.
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
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente