Deb wrote: > Jessie complained that the "markauto" option is deprecated and I should use > apt-mark auto instead. So I did and was informed that the library package > was already marked auto. Oh, that is just me being slightly behind. Things change and I am used to typing in the old way and if the old way still works I keep typing it out of habit. > >If you wish to review the list you can list all of the manually > >installed packages and all of the automatically installed packages. > >They are long lists so I suggest browsing them with the 'less' screen > >pager. > > > > $ apt-mark showmanual | less > > $ apt-mark showauto | less > > Okay, this is bizarre. The first command shows that apt, bash, whiptail and > a whole bunch of other packages that were installed by the netinstaller are > marked manual. In total there are 263 manual packages on my system. I guess I should clarify "manual" in this context. It means by explicit installation. Not necessarily that you yourself as an admin installed it. The list you mention apt, bash and others you really want marked as manual. That way they won't be autoremoved. But I know you as you didn't install them. They came in with the system. Which may feel automatic to you. But from apt's perspective it was explicitly told to install it and therefore it is manual because it was explicitly installed when the system was installed. Hopefully that makes sense. I am not sure I explained it well enough. > There are 1,048 auto packages listed, including nearly all lib* packages. > I'm thinking that Jessie must be configured to mark lib* packages as auto > even if the parent package install is manual. Correct. Not just Jessie but all of them. That is actually exactly how it is supposed to always work. You have it right. For example if one installs feh (image viewer) that will depend upon libexif12 and other things. This makes feh manual but libexif12 auto. Later one removes feh. Or feh is upgraded to Depend upon libexif14 (I just made that up) instead. That would leave libexif12 unused and auto. If it is unused (not depended upon) and auto it will be a candidate for autoremove. But... *If* libexif12 were marked as manual then it would never get removed even if nothing used it and nothing "Depends:" upon it. This concept isn't so much important as it is useful for keeping a system clean. I think most people ignore it and clutter builds up. A much smaller number of people try to keep the system tidy. I happen to be one of those. But don't stress if this seems too complicated. But it is useful to know how things work. > Python 3 and python3.4 are listed under auto, but python 2.7 is listed under > manual even though the OS still depends more heavily on 2.7 than on 3 or > 3.4. I am hoping that by this point in the explanation you see that it doesn't matter how many packages depend upon a package. Packages are auto if they were installed solely due to a dependency. Packages are manual if they were explicitly named for installation. > The only package I've installed through curl and make rather than apt-get, > and the only package that isn't from the Jessie main repository, is > valgrind3.10.1. It is listed under neither manual nor auto, but ir runs > perfectly. That local installation should be installed in /usr/local/bin/valgrind though and isn't a package and isn't managed by the package manager. You compiled it. You installed it with 'make install' and therefore the default installation path should be /usr/local/bin and /usr/local other paths for the support files. It isn't a package. It wasn't installed using "apt-get foopackage" or even "dpkg -i ./foo.deb" and therefore the package system doesn't know about it. The /usr/local directory tree is yours fully from top to bottom. It is yours to maintain as you wish. It is completely independent of the system's package manager. > I'm putting off installing etckeeper until I can find out whether it will > mess with my version of valgrind, which is later than the Jessie main > repository version. It won't mess with your installed copy of valgrind. Nothing installed by the package system will mess with anything in /usr/local. There is a clear separation of duties. The package manager handles /usr/bin, /bin and the rest of the system at those high levels. The local admin handles /usr/local/bin and all of the /usr/local tree. The first installation of etckeeper will check everything in /etc into git version control. After that you can: # cd /etc # git log # git whatchanged After you have made changes (there aren't changes yet when you first install it) then you can view the history of all of your system changes. And all other git commands are available too. But mostly one never needs to *do* anything. It is simply a record keeper. It keeps track of all of the system changes. If at some point in the future you purge a package, deleting the conffiles along with it, and then later go, "Hey! I want that back again." Then at that point you can "git checkout foo.conf" from the version history and get it back. Things are slightly more complicated than this but there is a huge community of git users. Ask a question here about how to get an old /etc conffile back from git and you will get a lot of help and suggestions for the command. Bob
Attachment:
signature.asc
Description: Digital signature