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

[matthias.hinkfoth2]

Hi Christoph,

> 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.

That is a good point. I am stumbling over it every now and then, too.

> 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...

My understanding of auto-installed is that the package was automatically
installed. If I install a package manually, it is clearly not auto-
installed.
But as I am sometimes really annoyed by non-existing or too heavy
package dependecies, I started to build meta-packages with the
(in my point of view) "correct" dependencies.
Since then, life became much easier. I do not have to work against
the package management any more.

Regards,
Matthias

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

[Manuel A. Fernandez Montecelo]

2016-02-29 22:28 GMT+00:00 Christoph Anton Mitterer :
> On Mon, 2016-02-29 at 18:52 +, 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 

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

[Christoph Anton Mitterer]

On Mon, 2016-02-29 at 18:52 +, 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.
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.

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.

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.


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.




> You can mark packages for removal and exit aptitude without removing
> immediately, but this will not fly long and other tools of the system
> might decide to remove it.
But then it's in the scheduled list when I do anything else...


> aptitude doesn't remove the flag now, but the package altogether,
> which
> is what the human requested (and what aptitude failed to do until
> recently).
> 
> 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...


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

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

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix
Control: close -1


2016-02-29 05:15 Christoph Anton Mitterer:

On Sun, 2016-02-28 at 17:29 +, Manuel A. Fernandez Montecelo wrote:

On the other hand, if I understood correctly, if nothing depends on
krb5-k5tls on your system, you shouldn't have it marked as
automatically
installed.


Why not?


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. These
 packages are marked as having been “automatically installed”; aptitude
 will monitor them and remove them when they are no longer depended
 upon by any manually installed package [10] . They will appear in the
 preview as “packages being removed because they are no longer used.”

 As with any automatic process, there is a potential for things to go
 haywire. For instance, even if a package was automatically installed
 to start with, it might turn out to be useful in its own right. You
 can cancel the “automatic” flag at any time by pressing m; if the
 package is already being removed, you can use Package → Install (+) to
 cancel the removal and clear the “automatic” flag.


aptitude was not doing a very good job at it, and because of that people
filed dozens of bugs over the years (most of which have been fixed in
recent versions) complaining that aptitude was not removing unwanted
garbage from their system, or not doing it quick enough (within the same
session).

I seems that you were relying on some of these wrong behaviours that
have now been fixed.



It's a handy way to flag packages which I have just installed because
of something else (which however lacks a recommends or so)...
e.g. mkvtoolnix-gui used to not be recommended by mkvtoolnix, but I
installed the former only because of the later...
Or it can be used to scheduled packages for removal, but not doing it
right now.


You can mark packages for removal and exit aptitude without removing
immediately, but this will not fly long and other tools of the system
might decide to remove it.

If you want to keep a list of packages to-be-eventually-removed, you can
use user-tags.



In fact, installing krb5-k5tls in my system and marking it as
automatically installed, aptitude attempts to remove it immediately
--
which is the right thing to do.

Sure.. but I don't think it's the right thing to remove the flag if I
manually set it.
Human is smarter than the machine... if he wants it he should get it.


aptitude doesn't remove the flag now, but the package altogether, which
is what the human requested (and what aptitude failed to do until
recently).

If human doesn't want the package removed, human should revisit what the
machine is asked to do.


Cheers.
--
Manuel A. Fernandez Montecelo 

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

[Christoph Anton Mitterer]

On Sun, 2016-02-28 at 17:29 +, Manuel A. Fernandez Montecelo wrote:
> I just tried to reproduce this with upgrading "less" (some packages
> recommend it) and "install-info" (some packages depend on it) in
> curses,
> with A flag set, but after proceeding to install but selecting "n" in
> apt-listchanges and then back to aptitude curses, the packages are
> still
> marked for upgrade and with A flag.
> 
> I tried the same with the command line, and with the same results --
> no
> removal of A flag.
Sure that works...


> On the other hand, if I understood correctly, if nothing depends on
> krb5-k5tls on your system, you shouldn't have it marked as
> automatically
> installed.
Why not?
It's a handy way to flag packages which I have just installed because
of something else (which however lacks a recommends or so)...
e.g. mkvtoolnix-gui used to not be recommended by mkvtoolnix, but I
installed the former only because of the later...
Or it can be used to scheduled packages for removal, but not doing it
right now.

Of course this makes just sense if auto-removal is not enabled, which
is however also perfectly fine to do.



> In fact, installing krb5-k5tls in my system and marking it as
> automatically installed, aptitude attempts to remove it immediately
> --
> which is the right thing to do.
Sure.. but I don't think it's the right thing to remove the flag if I
manually set it.
Human is smarter than the machine... if he wants it he should get it.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

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

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo unreproducible


Hi,

2016-02-25 03:15 Christoph Anton Mitterer:

Control: reopen -1

Hey.

I just tried that with:
# aptitude --version
aptitude 0.7.6
Compiler: g++ 5.3.1 20160220
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.6.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160213
  cwidget version: 0.5.17
  Apt version: 5.0.0

... and it still seems to happen.

I.e. I've upgraded kerberos, of which I've had e.g. krb5-k5tls marked
auto, though nothing depended/recommended/etc. it.

I've aborted at apt-listchanges, and then the auto flag was cleared.


I just tried to reproduce this with upgrading "less" (some packages
recommend it) and "install-info" (some packages depend on it) in curses,
with A flag set, but after proceeding to install but selecting "n" in
apt-listchanges and then back to aptitude curses, the packages are still
marked for upgrade and with A flag.

I tried the same with the command line, and with the same results -- no
removal of A flag.


On the other hand, if I understood correctly, if nothing depends on
krb5-k5tls on your system, you shouldn't have it marked as automatically
installed.  Perhaps aptitude or apt unmark it as autoinstalled if they
think that you want it installed while resolving the installation or
similar, because otherwise it would be removed from the system.

In fact, installing krb5-k5tls in my system and marking it as
automatically installed, aptitude attempts to remove it immediately --
which is the right thing to do.


Cheers.
--
Manuel A. Fernandez Montecelo 

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

[Christoph Anton Mitterer]

Control: reopen -1

Hey.

I just tried that with:
# aptitude --version
aptitude 0.7.6
Compiler: g++ 5.3.1 20160220
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.6.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160213
  cwidget version: 0.5.17
  Apt version: 5.0.0

... and it still seems to happen.

I.e. I've upgraded kerberos, of which I've had e.g. krb5-k5tls marked
auto, though nothing depended/recommended/etc. it.

I've aborted at apt-listchanges, and then the auto flag was cleared.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

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

[Christoph Anton Mitterer]

Package: aptitude
Version: 0.6.11-1+b1
Severity: normal


Hi.

There have been several bugs present over the years in which
aptitude (and perhaps also apt?? I only checked the following for aptitude,
it may easily apply to apt as well) forgot / cleaned manually set
auto-installed-flags on packages.
Some of these have been solved some years ago already, but some quite annoying
still persist.


The scenario is that an admin has set the auto-installed flag on packages,
which are not directly/indirectly depended upon/recommended/suggested by
any other installed package without the auto-installed flag set.

E.g. I have set the auto installed flag on
i A   libefivar0
which in turn is pulled in by:
i A   efibootmgr
which in turn is pulled in by:
i A   grub-efi-amd64-bin
i A   grub-efi-ia32-bin
which are not pulled in (depended/suggested/recommended) by any other
packages I'd have installed.

Having that situation may be non-standard but it may be quite handy,
e.g. to remember packages which I sooner or later want to remove again
(and they would show up when I do the remove unused packages)... or e.g.
to mark packages which in reallity belong/relate to other packages but
aren't recommended/suggest by them (yet).
And example for the later may be several doc-packages like cpio-toc, tar-doc
and so on, which clearly belong to cpio respectively tar (in the sense
it's typically rather useless for me to keep them, when I'd remove their
base packages, i.e. tar/cpio).
So that may be another situation in which people choose to manually mark
a package auto-installed, even though there is nothing else that actually
pulls it in (dependecy-wise).


Now unfortunately, there are several cases in which aptitude (again,
haven't checked apt) clears the auto-installed flag for such[0] packages.
The following is a rather fuzzy description of these situations:

- The manually auto-marked packages must be part of some package operation
  (e.g. and upgrade or downgrade performed on them).
  If then such operation is actually performed on these packages (optionally
  with other packages), then there are two cases (AFAICT):
  - when the operation succeeds
the auto-installed flags are properly kept
  - when the operation fails (meaning that I e.g. abort it when
apt-listchanges and/or apt-listbugs ask me to)
the (some/all?) auto-installed flags are lost
  - and I guess they're also lost, if the abort comes from within a package
e.g. when the maintainer scripts returns failure... but I'm not totally
sure about that case.

- The manually auto-marked packages must be part of some scheduled package
  operation (e.g. and upgrade, downgrade, remove, purge scheduled on them)...
  and then aptitude must be quit.
  When it's then run again later, then often/sometimes/usually, [some/all of]
  these manually auto-marked packages have their auto-installed flag cleared...
  but the scheduled package operation (install/remove/etc.) is still remembered.


Generally, neither aptitude (nor apt) should IMHO ever change the auto-installed
flag except for probably those cases:
- the user manually clears/sets it
  there could still be a command, which instructs it to clear the auto-installed
  flags of all dangling packages (i.e. those which aren't directly/indirectly
  pulled in by some non-auto-installed package)... but that shouldn't happen
  automatically.
- the package is purged (then it should be cleared)... not sure about what's 
best
  in the remove-but-not-purged case, perhaps it should stay?
- the package is actually installed automatically as part of some other package
  installation (in which case the flag is of course to be set automatically).

Maybe there are other cases which I haven't thought of right now,... but at 
least
it should be fixed that the flag isn't cleared in the situations described 
above.


Thanks,
Chris.



[0] Interestingly, it seems (don't remember exactly all cases, that it
doesn't necessarily to this clearing for all the involved packages.
For example, I believe to remember cases, where e.g. both
libefivar0 and efibootmgr were involed in package operations,
but the flag was only cleared on libefivar0.
But as said, I don't remember every single ocurrance of this issue,
so my mind may just play tricks on me.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org