2016-02-29 22:28 GMT+00:00 Christoph Anton Mitterer <[email protected]>: > On Mon, 2016-02-29 at 18:52 +0000, 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 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... I don't know of which auto-removal you're talking about, but in any case "aptitude will monitor them and remove them when they are no longer depended upon by any manually installed package" ([2], again) is pretty explicit about auto-removing things, so I don't know why you keep insisting that this isn't want aptitude is meant to do. [2] http://aptitude.alioth.debian.org/doc/en/ch02s02s06.html The whole point of "auto-installed", which is a concept probably /invented/ by aptitude (in the Debian world), is to mark as auto-installed packages that the user didn't request manually, so they can be *removed* when no other dependency in the system keeps it installed. So why you use it for other purposes beyond me and is immaterial in any case, but removing packages not depended upon anymore is the whole point of the auto-installed feature. Anyway, this is going in circles. EOC from me on this issue. -- Manuel A. Fernandez Montecelo <[email protected]> _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
