On 25 February 2012 11:12, Georgiy Treyvus <georgiytrey...@gmail.com> wrote: > Firstly sorry if it was too long. The relevant parts were: >
Not at all. Please do include more information with bug reports rather than less :-) > > Question: To be clear when if I tweak Aptitude::Purge-Unused to true it > effects only "aptitude purge <package>" and not "aptitude <remove> package" > correct? > No. Purge-Unused will cause unused packages to be purged regardless of whether you use "purge" or "remove" on the command-line. With this option set "aptitude remove foo" will only remove foo, but any unused packages will be purged. The same is true in the curses interface: aptitude will still respect remove or purge for packages you explicitly mark, however, auto-removed packages will be purged with Purge-Unused, or only removed without it. Purge-Unused ("--purge-unused") is *not* equivalent to: # apt-get remove --purge foo but rather: # apt-get autoremove --purge The first command does not act on unused dependencies. > Also while you say that the current behavior is a safeguard and I do agree > partially the current behavior will also confuse new users. At some point in > time much like me they're reading the documentation, they learn to use > remove in case they wish to reinstall the package and keep current > configuration, they learn to use purge if they want it gone period or if > they want a fresh start for whatever reason. > > Say they go "aptitude purge <package>" wanting to then install with a fresh > start. The messed up conf file belonging to some dependency isn't removed. > After purging they install again, it's not how they remembered it to be at > first, confusion ensues... > What about a misconfigured dependency that is kept because other packages depend on it? The user may be just as unaware of this other depending package and be just as confused that configuration is not restored. Generally, if the user chooses to correct configuration files this way then they must become aware of precisely which packages are misconfigured and target them specifically. This problem is not thoroghly resolved by the proposed behaviour for "purge" to autopurge dependencies also. > The way the documentation is worded users will understand the consequences > of purge. They think remove means keep configuration just in case and purge > means clean it I want a fresh start. Yet aptitude behaves differently then > described. Many simply may not figure out what's happening in such a > situation. > IMO the documentation in this area can easily be understood both ways (possibly more). Where exactly have you gotten the impression that "aptitude purge <package>" also applies "purge" to unused dependencies? In the man page, there is only one description of what a purge is: <package>_ Purge <package>: remove it and all its associated configuration and data files. Several descriptions of a "purge" in the user manual are equivalent to this in that they say nothing about what becomes of the unused dependencies. The documentation for Delete-Unused and Purge-Unused does clearly describe the current behaviour when each is set. > With that said while I understand the safety rationale for the current > behavior I still feel it causes more harm then good. Indeed. Given that it is reasonable for a user to expect either extreme, or something in between, then the safest course is most appropriate. A more informed user can get the behaviour they desire with some option setting and a less informed user is not subject to potential data loss. > Speaking of keeping > aptitude safe for new users here is an interesting issue to look into that > has caused many a n00b grief http://tanguy.ortolo.eu/blog/article8/ > I was struck by this same issue myself way-back-when. Picked up on it as the list of to-be-removed packages contained many unexpected items. It is fundamental to the use of meta-packages for that purpose and not particularily specific to aptitude.. though I could be mistaken here ;-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org