On Tue, Dec 22, 2015 at 12:35:25AM +0000, Robie Basak wrote: > On Mon, Dec 21, 2015 at 03:08:51PM +0100, Julian Andres Klode wrote: > > I'll repeat this one last time for you: If A suggests B, and you > > install B in some way, you may have come to rely on the fact that A is > > extended by B on your system. Automatically removing B could thus > > cause an unexpected loss of functionality. > > I understand your logic here. But doesn't the same logic apply to > Depends? If B depends on A and you install B in some way, then you may > have come to reply on the fact that A is extended by B on your system, > etc. What? A isn't extending B – B needs A to function, that is all. [What you describe is maybe "Enhances", which is a sort-of reverse Suggests (expect that there is no option to install them all by default… I wonder what the point would be to install all iceweasel extensions)]. If you installed B either A was already installed or A was installed by your request for B. Either way A will not be autoremoved (even if it was at some point automatically installed to satisfy a dependency-relation of C on A) as long as B is there (and/or C). A package can only be autoremoved if it is auto-installed and isn't a possible satisfier for a (Pre-)Depends/Recommends/Suggests relation (or-group) of another package which isn't autoremovable. > I had always assumed that this is the risk you take by using autoremove > and thus you need to pay attention to what you autoremove, which is for > example why unattended-upgrades is sensible by not doing it by default. It is not a good idea to perform autoremoves unattended for situations in which you have installed A (gui) depends B (console) depends C (data), but later decide that you don't like A (gui) anymore as you prefer using the console interface (B) directly. apt doesn't know that you ended up using B directly - it still believes it was installing B just for A, so after you removed A it will offer to autoremove B and C. Not the end of the world of course: reinstalling B is easy if it got removed and as long as you don't purge it it will be as it was before. You are in danger of surprising the user through (what the hell happend?!? Where is B?) and it is possible it will occur to the user that B is missing at a very inconvenient time (no internet or simply uninstallable at the moment). Its easy to dismiss this as no real problem, but if you ever experience this first hand your opinion might change. The alternatives might be worse through. > What makes Recommends and Suggests special? They aren't special, that is the point. The only difference between these relations is just if they will be installed by default (Depends, Recommends), if apt allows you to remove it without removing the package which has such a dependency-relation on it (Recommends, Suggests) and if apt is allowed to break such a relation via autoremove (none). There are options to change property one (you can't change it for Depends of course) and three (ditto) and if I remember right e.g. aptitude warns if you do two [something I want do implement for apt some day]. apt tends to be *very* conservative with removes which is a common complain - this thread is an example, the "usual" upgrade-problems if a maintainer decided that a transitional package is probably not needed is another. "Interestingly", if apt eventually decides to remove a package that tends to cause people to complain as well… We are open to ideas to improve apt, but apt is used by many people with very different expectations, so an idea which looks like an obvious no-brainer in your head might not survive contact with reality. After 6 years I think I have enough 'battle' experience to say that even I have still ideas which look good on paper only… and its good that others put a stop to such ideas before those ideas have a chance to hurt me (and I can assure you, I implemented ideas which never should have been and now taunt me by their mere existence). Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature