Tomasz Torcz <tomek(a)pipebreaker.pl> writes:
On Tue, Oct 15, 2019 at 01:56:11PM -0400, Robbie Harwood wrote:
> Matthew Miller <mattdm(a)fedoraproject.org> writes:
>
> > On Tue, Oct 15, 2019 at 12:36:15PM +0200, Miro Hrončok wrote:
> >>> As package maintainers we all make technical decisions which have
> >>> significant impact on our users every day - whether that's in the
> >>> choice of defaults, choice of build flags, or whatever. Honestly
> >>> delivering as modules-vs-non-modules is a completely trivial issue
> >>> compared to most of the stuff I spend time on. If "yum install
X"
> >>> still works most people just don't care about the RPM/dnf/repo
> >>> mechanics behind that.
> >>
> >> Except it works only half way. The installation works. Later,
> >> dependencies are broken. Upgrades are broken. "yum remove X" does
not
> >> undo the action completely.
> >>
> >> The main issue is: user just enabled a module without doing it
> >> explicitly. The user needs to know how to handle modules in order to
> >> recover.
> >
> > I never expect "yum remove X" to be the inverse of "yum install
> > X". DNF's magical leaf tracking makes it a bit more so, but not
> > exactly. So, I don't think we should make that a very high priority
> > concern (although if we can improve it, so much the better).
>
> I don't think it's an unreasonable expectation, especially for those
> coming from APT land (Debian, Ubuntu) where `apt install foo` *is* the
> inverse operation of `apt remove foo`.
It isn't, you need to supplement it with `apt autoremove` to get rid
of auto-installed dependencies.
We have `dnf history undo X` to invert installation command.
Ah, you're right. It is the case with aptitude, but not with apt or
apt-get. Sorry for the noise.
Thanks,
--Robbie