Curt wrote:
> Bob Proulx wrote:
> >> "-s, --simulate, --just-print, --dry-run, --recon, --no-act
> >> No action. Perform a simulation of events that would occur but do not
> >> actually change the system." - http://linux.die.net/man/8/apt-get=20
> >
> > Isn't needing something like -s too dangerous? What if you forgot to
> > include it on the command line? Wouldn't that be just as scary? :-)
>
> But you do not need to be root to simulate aptly, so the danger to which
> you allude needn't exist.
That is a good point. One that I hadn't considered. Because usually
there is a lockfile needed.
$ apt-get autoremove
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
But you are right that when -s is used the lockfile isn't needed.
$ apt-get autoremove -s
NOTE: This is only a simulation!
apt-get needs root privileges for real execution.
Keep also in mind that locking is deactivated,
so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
It is certainly always safe to run as non-root. Can't create a
problem that way.
BTW... In for a penny, in for a pound. Talking about this I might as
well jump the rest of the way out of the frying pan and into the fire.
I want to avoid creating a lot of lint on my system with files in the
"rc" state.
dpkg -l | grep ^rc
Which means I would normally need to make another pass to purge those.
dpkg --purge libfoo1 libfoo2 ...
Or agressively in mass with:
dpkg -l | grep ^rc | awk '{print$2}' | grep ^lib # review and check then
dpkg --purge $(dpkg -l | grep ^rc | awk '{print$2}' | grep ^lib)
Therefore when I am autoremoving those files I am usually passing in
the --purge option to it. That way those packages get purged and not
removed and therefore never end up in the rc state.
Just today on my Sid system.
# apt-get autoremove --purge
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
libglew1.7*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 593 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 611297 files and directories currently
installed.)
Removing libglew1.7:amd64 ...
Purging configuration files for libglew1.7:amd64 ...
Processing triggers for libc-bin ...
$ dpkg -l | grep ^rc
...no packages listed...
WARNING! Of course when I am purging packages I always look very
carefully at the package list. Because purging will remove locally
modified /etc conffiles associated with the package. But I also
always have a good backup of my system too. With that safety net of a
good backup in place there isn't any risk. If I were to purge
something with a locally modified configuration file in /etc that I
found afterward that I needed then I would simply install that single
package again and then recover the /etc conffile from backup. It
might take all of a couple of minutes to recover. :-) And that is
only in an "if" case. So far I haven't ever needed to do it.
Bob
P.S. Yes I know mixing awk and grep is silly since awk can do it all.
dpkg --purge $(dpkg -l | grep ^rc | awk '{print$2}' | grep ^lib)
I normally would have said this and done it all with awk.
dpkg --purge $(dpkg -l | awk '/^rc/&&$2~/^lib/{print$2}')
But I didn't think that was a clear of intent as the former in an
email. So I went with the more obvious logic even though it mixed
commands in a silly way.
Attachment:
signature.asc
Description: Digital signature