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.htmlWell, 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=4The 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. :-(