Re: Conflicting alternatives
On Tue 16 Feb 2021 at 19:19:52 (-0500), Stefan Monnier wrote:
> >> I can't see any reason why it should be fundamentally hard to make
> >> dpkg/apt ignore some conflict/require statements. Maybe it would take
> >> a fair bit of changes to the existing code if we want to make it work
> >> seamlessly (or maybe not, I don't know), but if so, it's only because
> >> the code was not written with such a situation in mind.
> >
> > So now we have a system with a broken (IMHO) apt running two
> > programs fighting non-cooperatively over the same resources
> > in order to be able to flip between them and test their
> > performance. It doesn't seem like a sensible evaluation.
>
> The purpose of allowing installation of conflicting packages or allowing
> installation even in the absence of some dependency is so that the DDs
> don't need to care about such corner case usage patterns.
>
> > Who's putting in the work to actually make two MTAs coexist?
>
> The end users who decide to use the "ignore conflict" option.
> And they get to keep the pieces.
>
> > Is this productive use of their time?
>
> It's their (or my, in some cases) choice.
>
> Instead of using such an option, I've had to edit the .deb packages and
> remove the "conflict" statements and do a few other such tweaks.
> I'd been much happier taking the same risks but without having to edit
> the .debs instead telling dpkg things "ignore this dependency" "ignore
> that conflict", "pretend this package has that other name".
> [ In my case, I've been doing that so as to keep many different
> versions of Emacs installed: by and large they don't actually
> conflict (in terms of overwriting the same files, for example).
> Further in the past, I'd done such things to be able to install
> the `gnome` package even tho I wanted to exclude one of the packages
> it depended on because it conflicted with some other package that
> I wanted to have installed. ]
>
> In all those cases, I think Debian's packagers made reasonable choices
> (e.g. I agree that Debian is overall better off with just `emacs`
> instead of `emacsNN`), they just didn't quite match my specific needs.
>
> It'd be work in the DPKG/APT code, yes. But it would require no extra
> work from the people doing the packaging.
But if you're seriously figuring out how to have, say, coexisting MTAs,
and fold that back into the Debian project, then I would have thought
that tweaking the Control fields is part of the deliverable.
In terms of this thread, I would say that emacs is user-y® (and
appears in /etc/alternatives a lot).
Cheers,
David.
Reply to: