[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: