[Aptitude-devel] Bug#787663: aptitude forgets/clears manually set auto-installed-flags in several situations

Tue Mar 1 02:16:35 UTC 2016

2016-02-29 22:28 GMT+00:00 Christoph Anton Mitterer <calestyo at scientia.net>:
> On Mon, 2016-02-29 at 18:52 +0000, Manuel A. Fernandez Montecelo wrote:
>> Because marking a package auto means to tell aptitude "remove it from
>> my system as soon as it's not needed".
>>
>>   http://aptitude.alioth.debian.org/doc/en/ch02s02s06.html
>>
>>   It works like this: when you install a package, aptitude will
>>   automatically install any other packages on which it depends.
>
> I know how it works, but that system alone is a bit limited, as it
> works only for those situations where there is actually a dependency
> expressed between the packages in question,... which in turn is however
> by far not every case where I install a package because of another
> package.
>
> E.g. I install m4-doc, because of m4, yet there is no dependency
> relation between them.

That looks like a thing better solved in the package dependencies, m4
could Suggest m4-doc, and then Auto-installed plus Suggests-Important
would keep would keep it installed.

> So all I can do is either not have m4-doc auto-marked, and I'll
> probably forget it once m4 is deleted (in which case I don't need m4-
> doc anymore)... or I use the current system a bit less narrow-minded
> and set my own manual auto-flag.

The system less narrow-minded is not truthful to the documentation and
what many people expect, and they expressed that repeatedly reporting
many bugs during the years.  Trust me, it was not fun wading through
many dozens of bug reports /related specifically with these issues/
and fixing them.

So I am not for screwing your workflow [1] gratuitously, but if I have
to choose between what most people expect and the way in which you use
it that doesn't match the documentation... well, you know the reply.

  [1] https://xkcd.com/1172/

> It may even go farther to say,... I install gimp and because I export
> my images as jpeg, I also install jpegoptim... these have nothing
> directly to do with each other and there will never be a dependency
> relationship between them.
> Still one may want to mark e.g. jpegoptim auto, in order not to forget
> about it.

I find it hard to sympathise with the idea that keeping m4-doc or
jpegoptim installed in the system for longer than strictly needed,
e.g. if you forget about it for a couple of months, is something Very
Bad.

Other people felt terribly that some packages that were not needed
were removed ASAP, I also find the idea a bit silly, but there were
many many many of them, so they won.

If it is so important for you, well, I already gave you hints about
how to be more proactive about it -- user tags.  Perhaps even creating
a simple script and e-mailing to you the tagged packages every few
weeks, to see if something has slipped through the cracks.

You might even do another proactive thing, try to read the
documentation and see if Delete-Unused does something for you.  But I
wouldn't have high hopes because these options which are not very
useful tend to bitrot with time, and they possibly clash with options
or features added later on.

> It may not be the primary way auto-installation/removal is intended to
> be used, but I see no reason why not to allow that use case.

"Clashing with other people's expectations" and "not being able to
work both ways at the same time" might be one reason.

> Actually the current system is even more "limited",...
> E.g. I may have a package xyz that recommends some python-gibberish...
> and I say, yes I want to use that functionality that python-gibberish
> gives to xyz.
> So it's marked auto-installed.
>
> Now I install abc further package abc, which e.g. suggest, but here I
> don't have any intentions to use that with python-gibberish.
> However, when I remove xyz, pyhton-gibberish, will of course not be
> auto-removed.

Uh-hum.

So you see, there's no way for aptitude to know the intentions of the
user in all cases.

If s/he wants the package in the system but s/he marks the package as
"auto-installed" instead, so aptitude can remove it because nothing
else depends on it, the user gets pissed off.  If other packages
depend on a given package and aptitude doesn't remove it automatically
when the user might not want it installed anymore for some reason,
then aptitude doesn't remove it, just to spite the user!  And the user
gets pissed off.

This perhaps happens because dependencies don't always match 100% what
it right, or what the user expects; and even if the user wants A today
maybe s/he wants B tomorrow, so there is little hope that aptitude can
fulfill 100% the desires of the users all of the time.  AI is not
there yet, and aptitude --prescient was not implemented yet.

It looks to me that the only way to keep the evil aptitude in check is
to closely monitor it, e.g. with simple inspections of what's
installed from time to time and prune unwanted things, use patterns
and user-tags and other features that aptitude provides, and keep
aptitude in check.

>> If human doesn't want the package removed, human should revisit what
>> the machine is asked to do.
> Well AFAIU, the flag means auto-installed, not do-auto-remove... and if
> I have auto-removal turned of I see no reason why one should forbid the
> other use case...

I don't know of which auto-removal you're talking about, but in any
case "aptitude will monitor them and remove them when they are no
longer depended upon by any manually installed package" ([2], again)
is pretty explicit about auto-removing things, so I don't know why you
keep insisting that this isn't want aptitude is meant to do.

  [2] http://aptitude.alioth.debian.org/doc/en/ch02s02s06.html

The whole point of "auto-installed", which is a concept probably
/invented/ by aptitude (in the Debian world), is to mark as
auto-installed packages that the user didn't request manually, so they
can be *removed* when no other dependency in the system keeps it
installed.

So why you use it for other purposes beyond me and is immaterial in
any case, but removing packages not depended upon anymore is the whole
point of the auto-installed feature.

Anyway, this is going in circles.  EOC from me on this issue.

-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>