On Tue, Feb 16, 2021 at 02:40:33PM -0500, Stefan Monnier wrote: > > Exactly. This is user-y stuff: imagine two X servers running on behalf > > of two users [...] > Not sure in which way this is different from running two different SMTP > servers on two different interfaces. Technically not much, granted. Perhaps I haven't made clear that I perceive that distinction as somewhat artificial. Organisationally, and from the POV of a multi-user system, every user has an own X server at her disposal (be it running on the host itself, be it running on separate hardware), whereas there's just one MTA running on the server for all users. > > The start (@Kevin: still listening?) would be to unpackage a package, > > hack the Conflicts: (& friends) fields, try to install both and watch > > the fireworks. Then fix the issues one by one. > > FWIW, I've done such surgeries occasionally (e.g. to install old Emacs > packages), but it's not fun. Of course not. But it'll be the only way to find out which stumbling blocks lie beyond the package-imposed "conflicts". And then, perhaps, convince the DDs That Be. [...] > No, that option is exactly what I excluded between the square brackets Ah, got that now. > because it only applies during the execution of the command (so you end > up with a system in a broken state and from then on dpkg/apt will just > keep complaining about it until you revert it), whereas what we need is > more like a config file listing conflicts we want to keep ignoring (I've > similarly wanted some way to list package dependencies that dpkg should > currently ignore). agreed. Such a system isn't the one you want to be "living on" for a longer period. [...] > 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. I'm not very much into Debian's dependency resolver; the only I gather (from experience and from reading things, so take with a fist of salt) is that it's less trivial than it seems. I have the hunch that just making the packages co-installable is the more pleasant avenue... Cheers - t
Attachment:
signature.asc
Description: Digital signature