On 30.05.20 05:00, David Wright wrote:
On Fri 29 May 2020 at 22:23:23 (+0200), Marco Möller wrote:
On 29.05.20 21:48, David Wright wrote:
On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote:
(...)
"apt has a bug, cannot believe it!"
https://lists.debian.org/debian-user/2020/05/msg00567.html
Well, I must admit, I can sympathize with this person's frustration. He
just got confused among those AutoRemove* advanced options.
I think it's much more than that. The OP appeared to regard the
--no-install-recommends option as a *property* that is applied to each
package installed under that recommendation regime, and that
that property would be preserved for all time. But as the "-install-"
in --no-install-recommends shows, it's just an option for the install
command itself.
(...)
Here the OP of that thread. Exactly this, David.
I would really wish that the "--no-install-recommends" option would
act as a "--no-recommends-wished" option!
(...)
Yes, a bigger work load on apt itself, but I really think it
would be worth it. Just consider how many of us are forced to set up
sophisticated backup strategies, or applying for this file system
snapshot tools to act as a "time machine", while an enhanced apt could
target this need in an easy an elegant fashion for the user (not
speaking about the user's data and about the configuration of the
packages, but speaking about the installation state of software
packages)!
You seem to be suggesting a one-dimensional install/undo facility,
but an installation is a multi-dimensional graph of packages and
dependencies. It's rare that one would want to just backtrack through
a de-installation in the exact reverse order of installation.
I also think it would be difficult to support, as it would give
people unrealistic expectations of what's possible.
In the sense of my wish, any removal or purge of a package would do the
following (illustrating the idea and being aware that for sure some more
in depth thoughts will have to be spent on it):
(0) allow the user to store in some config file a list of time stamps
which then could be respected as an option in the below outlined
algorithm; the config file could look like this and for instance a
leading integer number could later on be used for addressing a certain
time stamp:
1; timestamp; essential OS after the initial installation
2; timestamp; added all my packages for a personalized CLI experience
3; timestamp; my minimum graphical DE is installed
4; timestamp; my full workstation, pristine, nice fall back state
5; timestamp; enhancements, quite good achievements
6; timestamp; testing
7; timestamp; arbitrary user comment
default=4
The first entry "1" could be stored automatically by the Debian
installer after the OS install and first reboot finished successfully;
the default could initially be set to 1; the user could edit this file
(and then of course also change the default value to another integer
value like 4 in the above example; invalid default values are always
treated as if the youngest timestamp would have been defined, value 7 in
my above example);
An enhanced apt-cache database would have to register for each installed
package the installation date and if (not which) recommends and if (not
which) suggests have been wished to install; for the drawn in recommends
and suggest a list of the packages which explicitly wished their
installation has to be maintained in the database by storing this
information in the entry of each installed package;
With this information there would not arise a limitation for at any time
defining time stamps in the config files, because the "wished" tree
besides the "dependency" tree could be reconstructed for any time;
(1a) if 'apt remove' or 'apt purge' are called with a timestamp option
and not specifying a specific package name, for instance 'apt remove
--keeptimestamp 3' then remove or purge all packages installed AFTER the
time stamp (for example, regarding my config file in (0), by the option
value '3' in '--keeptimestap 3', the minimum graphical DE installation
would remain but everything installed afterwards would be removed; the
below mentioned steps (1b), (2) and (3) are not to be executed no more;
(1b) if a specific package name is mentioned, then read for this
specific by 'apt remove' or 'apt purge' targeted package IF recommends
and suggests have been wished by this package; IF NOT, then simply
remove or purge the specific package, considering also the dependencies
as usual, and continue at step (4); IF recommends or suggests have been
wished then continue at step (2);
(2) if NO time stamp option was given then use the default timestamp;
check if any of the recommended and suggested packages have themselves
registered in their database entry in the "wished by" list that they
would be wished by any other installed package, considering all packages
which have been installed before the time stamp to be wished packages,
and if for a package from the recommends and suggests list it now
results that it is not wished any more, then besides removing or purging
only the specified package do additionally also remove or purge the no
more wished recommended and suggested package(s);
(3) iteratively follow the logic of step (2) for the additionally found
packages which meanwhile became marked for removal or purge and work
also on their list of recommends and suggests;
(4) in interactive mode show the list of for removal or purge marked
packages and offer to the user the question, if ALL these found no more
wished packages shall now be processed, or if for each package it should
be asked individually once more;
(5) if in (4) the manual, step wise approval was requested, then ask by
priority first for the packages found in the first iteration, then for
the ones found in the next iteration, and so on.
(6) iterate steps (4) to (6) until a final selection is reached which
should be processed
Any simple 'apt remove package' or 'apt purge package' would no more let
unwished packages remain in the system, and any 'apt remove
--keeptimestamp N' or 'apt purge --keeptimestamp N' would set the
installation of packages back to a pristine state. At least the package
state right after the initial, successful OS installation is always
being defined as a pristine state, and alternative pristine stamps could
any time be defined by the user for any time. Combination of the options
would be possible, like in: 'apt remove --keeptimestamp 3 packagename';
The latter case would protect to remove the package "packagename" if
this would break the state of time stamp 3.
Splendid!
From the view of a user, it does not sound so complicated ;-) . I
guess, and this will be fair, that I am now asked to program it, it's
open source and I should contribute. But unfortunately I can only
contribute ideas, I am not a programmer. :-(
