On Thu 30 Jun 2016 at 19:35:44 (-0400), Gene Heskett wrote: > On Thursday 30 June 2016 19:25:37 Lisi Reisz wrote: > > On Thursday 30 June 2016 21:12:46 Henrique de Moraes Holschuh wrote: > > > On Thu, 30 Jun 2016, Gene Heskett wrote: > > > > Thats not excusable behavior, but whats worse is that debian's > > > > people are denying there is a problem. 'scuse me? I swear, they > > > > couldn't smell coffee with a nose full of it. > > > > > > Well, if either of you two (that suffered the runaway aptitude > > > issue) still have the /etc of the box that caused trouble, kindly do > > > this: > > > > > > grep -r Assume-Yes /etc > > > > > > If it returns any match in the aptitude config files, there you have > > > it. > > > > I have this on my desktop at home: > > > > root@Tux-II:/home/lisi# grep -R Assume-Yes /etc > > grep: /etc/fonts/conf.d/70-no-bitmaps.conf: No such file or directory > > Binary file /etc/alternatives/aptitude matches > > root@Tux-II:/home/lisi > > > > It rather looks as though I should be worried? > > No, thats just grep being grep, it says that of ANY binary file it tries > to read as text. I have spent days pouring over the manpages for grep, > looking for a option to feed it to make grep quit that, simply because > its so verbose that what you are looking for can get lost in its > blathering about that.
I have no idea what that's meant to be the explanation for. Why does Binary file /etc/alternatives/aptitude trigger a match? What you were running was aptitude, obviously. On my laptop: $ which aptitude /usr/bin/aptitude $ ls -l /usr/bin/aptitude lrwxrwxrwx 1 root root 26 Oct 10 2012 /usr/bin/aptitude -> /etc/alternatives/aptitude $ ls -l /etc/alternatives/aptitude lrwxrwxrwx 1 root root 24 Oct 10 2012 /etc/alternatives/aptitude -> /usr/bin/aptitude-curses $ ls -l /usr/bin/aptitude-curses -rwxr-xr-x 1 root root 4340528 Nov 8 2014 /usr/bin/aptitude-curses (The last line might be different if you use some version other than curses.) So the question becomes Why does the binary file /usr/bin/aptitude-curses, that you actually run, match? Well, in order to decide whether you have typed aptitude --assume-yes aptitude needs to contain the string "assume-yes" against which to check your typing. Ditto Aptitude::CmdLine::Assume-Yes for checking against the configuration file. So a match here is no surprise and no worry. However, you should also check for anything in /root/.aptitude/config as that could override the /etc/ stuff. (Probably nothing.) So your problem might boil down to why aptitude thought all those packages should go, ie what happened to the package(s) at the top of the dependency chain(s) whose job was to keep them all installed. Sorry I don't have much experience of aptitude other than the visual interface (ie no action given on the command line). I'm really an apt-get user. In order to remove "unused" packages, I have to type apt-get autoremove which I sometimes do in response to its telling me there are such packages lying around. It's not easy for me to tell from the documentation whether "Installed packages will not be removed unless they are unused (see the section “Managing Automatically Installed Packages” in the aptitude reference manual)¹" means that they'll be removed automatically without any further confirmation. ¹safe-upgrade in man aptitude. Cheers, David.
