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

Re: Conflicting alternatives



On Wed 17 Feb 2021 at 10:49:35 (-0500), The Wanderer wrote:
> On 2021-02-17 at 10:25, David Wright wrote:
> > On Wed 17 Feb 2021 at 20:45:02 (+0800), Kevin Shell wrote:
> >> On Tue, Feb 16, 2021 at 07:19:52PM -0500, Stefan Monnier wrote:
> >> > 
> >> [...]
> >> > It'd be work in the DPKG/APT code, yes.  But it would require no extra
> >> > work from the people doing the packaging.
> >> 
> >> I know little technical details about the Debian package manager,
> >> from an end user's perspective, the package manager should give the user
> >> the choise not to uninstall a wanted package,
> > 
> > Call that 1.
> > 
> >> if the user don't give a choise, the package manager can perform the
> >> default action to remove the package. 
> > 
> > Call that 2.
> > 
> >> I think this method is a better default behavior for the package manager 
> >> for some similar packages.
> > 
> > Is that not true now?
> > 
> > $ apt-get -s install busybox-static
> 
> > The following packages will be REMOVED:          ← case 2 ----------
> >   busybox
> > The following NEW packages will be installed:
> >   busybox-static
> 
> > ~# aptitude hold busybox
> > ~# 
> > 
> > $ apt-get -s install busybox-static
> 
> > The following packages have unmet dependencies:
> >  busybox : Conflicts: busybox-static but 1:1.30.1-4 is to be installed
> >  busybox-static : Conflicts: busybox          ← case 1 ----------
> 
> I think what he's wanting is a case which would allow installing
> busybox-static, but not insist on removing busybox. (Or the equivalent
> in his actual use-case, where the files installed by the two packages
> might not actually overlap.)
> 
> Where that runs into trouble is that even if the *files* don't overlap,
> other resources which the package needs to control exclusively quite
> possibly do - the most prominent example, from the discussion at hand
> regarding MTAs, being port 25.

I entirely agree, and that's why I wrote

  Who's putting in the work to actually make two MTAs coexist?
  Is this productive use of their time?

But these discussions often head off into odd territory, which here
seems to be:

. Break apt's conflicts mechanism and that'll fix it (just for me).
  - alternatives/dummy package appear to be able to avoid the necessity.

. Extend the alternatives mechanism and that'll fix it.
  - AIUI alternatives is aimed at a different target.

. Other distributions manage this easily.
  - what mechanism are they actually using? (rather than a
    reference to a package or heap of code).

The only realistic suggestion I've read here is from tomás,
who seems to be expressing some sort of shim dispatcher.
And I await a thought-out solution from the virtualisation crowd.

Maybe enough from the "peanut gallery".

Cheers,
David.


Reply to: