Re: Bug#3085: bsdmainutils uses inappropriate `Conflicts bsdutils (<<...)'
David Engel writes ("Re: Bug#3085: bsdmainutils uses inappropriate `Conflicts bsdutils (<<...)'"):
...
> > The best I've come up with so far is a new control file field:
> > Breaks: <package> [(<versionspec>)] [, ...]
> >
> > This would cause dpkg to refuse to install if the package which would
> > be broken is also installed, unless --auto-deconfigure is enabled, in
> > which case it would deconfigure the package to be broken first. (This
> > kind of thing is necessary so that dselect doesn't need to install all
> > the packages in some particular order.)
> >
> > This is much the same effect as if the package being broken had said
> > Depends: <package-being-installed> (<< <version-being-installed>)
> > or `Provides: <foo>' where the old version of the package being
> > installed provided foo but the new version doesn't.
>
> How does this differ from a plain old Conflicts?
A Conflicts would prevent dpkg (and thus dselect) from even allowing
the `conflicting' versions to exist on the same system. This would
mean enforcing an installation order, unnecessarily.
> > How does this sound ? Anyone else have any comments ?
>
> I don't think this accomplishes what I intended. The difference that
> I'm looking for from the current Conflicts (as I understand it) is
> subtle. That difference is that if one package is upgraded or
> installed, then the conflicting packages must be upgraded as well.
> Careful use of Replaces should make it possible to avoid requiring
> packages to be installed/upgraded in a specific order.
Replaces is the wrong thing to use: it has entirely the wrong
semantics - when used together with Conflicts it causes the package
which is the `target' of Replaces to be removed, without requiring the
user to instruct dpkg to do this !
Its effect when usedi without Conflicts is even more irrelevant to the
problem at hand.
> Where I think this difference would have the most useful impact is in
> dselect's conflict resolution screen. Instead of simply informing the
> user that package B conflicts with package A, dselect could say that
> package B must either be upgraded to the required version or it must
> be removed. Perhaps the current meaning of Conflicts (<<version)
> could be extended to handle this, but I'll leave that up to you.
dselect already handles this kind of thing when you say Depends
(>>version) or whatever; adding Breaks semantics wouldn't be that
hard. (Post 1.1 though.)
Ian.
Reply to: