Re: Automatic installs
On Wednesday 20 November 2013 01:37:42 Brad Alexander wrote: > Actually, nowadays, I end up having to dist-upgrade to get new > kernels, etc. Which kind of defeats the *dist* part of dist-upgade. Aptitude uses full-upgrade. As opposed to safe-upgrade. Semantically preferable. ;-) Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201311201654.28490.lisi.re...@gmail.com
Re: Automatic installs
On 2013-11-20, Andrei POPESCU wrote: > > For a dist-upgrade you should use whatever is advised in the Release > Notes for that release, regardless of your usual preferences. That would be the apt tool when upgrading from squeeze to wheezy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnl8p1us.2c2.cu...@einstein.electron.org
Re: Automatic installs
Excellent. Thanks, Andrei, On Tue, Nov 19, 2013 at 7:10 PM, Andrei POPESCU wrote: > On Ma, 19 nov 13, 17:28:27, Brad Alexander wrote: > > Sorry. Replied privately instead of to the list... > > And I'll elaborate on my short reply as promised. > > > Way back in the mists of time, around the time of the squeeze release, I > > asked here and it was recommended to use apt rather than aptitude... > > > > I'm guessing the best practice has changed...? > > Each has its strengths and weaknesses and I use both: > > - on my sid laptop I have an aptitude in interactive mode open all the > time, to keep the system updated (almost daily), to look up package > information, to check out new packages, to remove obsolete ones and > other general maintenance of the system > I've tried the interactive mode, but it reminds me too much of dselect. :) I started using Debian around 1999 (slink?), and it was pre- or early-days of apt. I could never get through the install, because I had a mental block against dselect. Try as I might, I can't get past the resemblance of aptitude's interactive mode. > - for a quick search by name or description I use 'apt-cache search', > because it's faster > I use apt-cache and apt-file together on both my workstation and laptop. > - for complex searches (and possibly actions on the set of packages a > search would return) aptitude is better > - for maintenance of stable systems I prefer apt-get (update && upgrade > && dist-upgrade) because it's fast and simple. > Agreed. this is the only way I upgrade. I run a sid desktop and a sid laptop. However, I don't upgrade nearly as often. I run apticron to keep an eye on critical packages, either function or urgency. > - for quickly installing a package I prefer apt-get (faster) except for > my sid system where aptitude is already open > - etc. > > Recently aptitude's dependency resolver also couldn't come up with > reasonable solutions for some transitions in sid, so I used apt-get > instead. > I have seen this too. I'm not a fan of the dependency resolution in aptitude. Generally, it gives me a number of non-optimal solutions. I'm not sure what logic gets used, but I have seen cases where it wants to uninstall major portions of the system because a package needs to be upgraded. > For a dist-upgrade you should use whatever is advised in the Release > Notes for that release, regardless of your usual preferences. > Actually, nowadays, I end up having to dist-upgrade to get new kernels, etc. Which kind of defeats the *dist* part of dist-upgade. Regards, --b
Re: Automatic installs
On Ma, 19 nov 13, 17:28:27, Brad Alexander wrote: > Sorry. Replied privately instead of to the list... And I'll elaborate on my short reply as promised. > Way back in the mists of time, around the time of the squeeze release, I > asked here and it was recommended to use apt rather than aptitude... > > I'm guessing the best practice has changed...? Each has its strengths and weaknesses and I use both: - on my sid laptop I have an aptitude in interactive mode open all the time, to keep the system updated (almost daily), to look up package information, to check out new packages, to remove obsolete ones and other general maintenance of the system - for a quick search by name or description I use 'apt-cache search', because it's faster - for complex searches (and possibly actions on the set of packages a search would return) aptitude is better - for maintenance of stable systems I prefer apt-get (update && upgrade && dist-upgrade) because it's fast and simple. - for quickly installing a package I prefer apt-get (faster) except for my sid system where aptitude is already open - etc. Recently aptitude's dependency resolver also couldn't come up with reasonable solutions for some transitions in sid, so I used apt-get instead. For a dist-upgrade you should use whatever is advised in the Release Notes for that release, regardless of your usual preferences. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Automatic installs
Brad Alexander wrote: > Way back in the mists of time, around the time of the squeeze release, I > asked here and it was recommended to use apt rather than aptitude... > > I'm guessing the best practice has changed...? It has changed back and forth several times. At the present time both are mostly functional and both can be used mostly interchangeably. Feel free to use one for one command and the other one for another command back to back on the command line. However each has their proponents. I like one. Other people like the other. Each are advocating for the reasons they like one tool or the other better. Since the way the features are implemented are quite different user interfaces I don't see these two camps converging any time soon. Because since the interfaces are so very different then if you like using one you almost certainly won't like using the other. And the reverse. Fortunately in the apt versus aptitude issue each of the tools work quite well and without opposing damage. It isn't like some of the other notorious flamewars that have risen where one of the tools was actively damaging other parts of the system. (shudder) Bob signature.asc Description: Digital signature
Re: Automatic installs
Sorry. Replied privately instead of to the list... Way back in the mists of time, around the time of the squeeze release, I asked here and it was recommended to use apt rather than aptitude... I'm guessing the best practice has changed...? On Tue, Nov 19, 2013 at 3:50 AM, Andrei POPESCU wrote: > On Du, 17 nov 13, 16:39:10, Neal Murphy wrote: > > > > Actually, if efficiency was important, the --purge option would accept a > > regex. Or there'd be a --purgex option. > > Behold the power of aptitude > > aptitude purge ~c > aptitude purge ~o > ... > > Kind regards, > Andrei > -- > http://wiki.debian.org/FAQsFromDebianUser > Offtopic discussions among Debian users and developers: > http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic > http://nuvreauspam.ro/gpg-transition.txt >
Re: Automatic installs
On Du, 17 nov 13, 16:39:10, Neal Murphy wrote: > > Actually, if efficiency was important, the --purge option would accept a > regex. Or there'd be a --purgex option. Behold the power of aptitude aptitude purge ~c aptitude purge ~o ... Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Automatic installs
On Sunday, November 17, 2013 04:20:25 PM Bob Proulx wrote:
> 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.
If the command was intended to be run once every second, the latter might be
preferred. But since absolute efficiency isn't required, the former is clearer
and is far more easily understood by non-experts.
Actually, if efficiency was important, the --purge option would accept a
regex. Or there'd be a --purgex option.
Enough pedantry for now. :)
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201311171639.10897.neal.p.mur...@alum.wpi.edu
Re: Automatic installs
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.
signature.asc
Description: Digital signature
Re: Automatic installs
On 2013-11-17, 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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnl8hvkj.1uv.cu...@einstein.electron.org
Re: Automatic installs
I am in a similar situation after upgrading some gnome components to their packages in experimental. the "gnome" (and related) metapackages are still at their sid versions, they have versioned dependencies and I think therefore have been removed. In my case I wait until the metapackages are updated and reinstall them before I look at autoremovals. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131117085319.ga16...@bryant.redmars.org
Re: Automatic installs
Ralf Mardorf wrote: > Bob Proulx wrote: > > Mark a few of the top level ones and then run autoremove, answer 'n'o. > > Then pick another top level package and mark it. Then run autoremove > > again and answer 'n'o again. Repeat until you have marked to keep all > > of the packages that you want to keep. > > As root running a command that could remove packages, just to monitor > something, is bad practice. Soon or later it will result in "Oops, > accidentally removed". Note that the OP had already successfully performed this very command several times already. If root can't perform safe operations like this then perhaps they should take up basket weaving. No reason to continue to put this type of stress upon them. It isn't good for the health. I recommend fresh air and exercise. > "-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 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 the reason I don't use -s there is that the list of packages if they are very long turn into a *very* long list of packages. I find that inconvenient. The word wrapped paragraph listing is more compact. The result is the same for me. YMMV. However if I were going to scrape the output for some automation then including the -s is convenient because the result is more machine readable. Bob signature.asc Description: Digital signature
Re: Automatic installs
On Fri, 2013-11-15 at 16:46 -0700, Bob Proulx wrote: > Mark a few of the top level ones and then run autoremove, answer 'n'o. > Then pick another top level package and mark it. Then run autoremove > again and answer 'n'o again. Repeat until you have marked to keep all > of the packages that you want to keep. As root running a command that could remove packages, just to monitor something, is bad practice. Soon or later it will result in "Oops, accidentally removed". "-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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1384587118.707.12.camel@archlinux
Re: Automatic installs
Brad Alexander wrote: > Hi Bob, > > (every time I see your avatar, it makes me want to go back and finish up my > pilot's license. :) ) If you do that then I have done my good deed for the day! :-) Remember that it is never too late to have a happy childhood. Bob signature.asc Description: Digital signature
Re: Automatic installs
Hi Bob, (every time I see your avatar, it makes me want to go back and finish up my pilot's license. :) ) Thanks for your advice. I think the package manager got confused, but I was able to apt-get install kde-full. It added about half a dozen packages, but it also brought the ones i was having issues with back into the fold. Thanks for pushing me in the right direction. --b On Fri, Nov 15, 2013 at 6:46 PM, Bob Proulx wrote: > Brad Alexander wrote: > > Calculating upgrade... The following packages were automatically > installed > > and are no longer required: > > akonadiconsole akregator amor ark avogadro-data blinken blogilo bomber > > bovo > > cantor cervisia crda cvs cvsservice dnsmasq-base dragonplayer easy-rsa > > gnugo > > ...snip... > > step svgpart sweeper texlive-latex-base texlive-latex-base-doc > > translate-toolkit umbrello usb-modeswitch usb-modeswitch-data valgrind > > valgrind-dbg vpnc wireless-regdb wpasupplicant > > Use 'apt-get autoremove' to remove them. > > Did you install these with KDE and then along the way remove the kde > meta package? > > > I am deathly afraid to apt-get autoremove, because I see a lot of things > in > > there that I use, such as akregator, gwenview, kwalletmanager, > > Then in that case mark them as being something you want to keep > around. The easy way is simply to fire the install command on them. > > apt-get install akregator gwenview kwalletmanager ... > > That will say that they are up to date and then also say that it is > marking them as manually installed. > > There is also the 'apt-mark manual foo' command to mark foo as > manually installed too. Either way is fine. For this apt-get install > is one less thing to remember. > > > So is this for real, and if I apt-get autoremove, it will gut my > > system, or am I missing some detail and it's all good? > > As currently known if you run apt-get autoeremove it will remove those > packages. But if you are using those packages then don't do that. :-) > Instead simply mark them as being manually installed. > > Mark a few of the top level ones and then run autoremove, answer 'n'o. > Then pick another top level package and mark it. Then run autoremove > again and answer 'n'o again. Repeat until you have marked to keep all > of the packages that you want to keep. Almost certainly along the way > you will find some package that you don't want and will decide to let > it go. The automatically installed list is just a helper to help you > maintain your system. But it is a simple thing and doesn't know about > all cases such as the removal of a kde meta package. You are > certainly encouraged to use judgement and drive it the way you want. > > Bob >
Re: Automatic installs
Brad Alexander wrote: > Calculating upgrade... The following packages were automatically installed > and are no longer required: > akonadiconsole akregator amor ark avogadro-data blinken blogilo bomber > bovo > cantor cervisia crda cvs cvsservice dnsmasq-base dragonplayer easy-rsa > gnugo > ...snip... > step svgpart sweeper texlive-latex-base texlive-latex-base-doc > translate-toolkit umbrello usb-modeswitch usb-modeswitch-data valgrind > valgrind-dbg vpnc wireless-regdb wpasupplicant > Use 'apt-get autoremove' to remove them. Did you install these with KDE and then along the way remove the kde meta package? > I am deathly afraid to apt-get autoremove, because I see a lot of things in > there that I use, such as akregator, gwenview, kwalletmanager, Then in that case mark them as being something you want to keep around. The easy way is simply to fire the install command on them. apt-get install akregator gwenview kwalletmanager ... That will say that they are up to date and then also say that it is marking them as manually installed. There is also the 'apt-mark manual foo' command to mark foo as manually installed too. Either way is fine. For this apt-get install is one less thing to remember. > So is this for real, and if I apt-get autoremove, it will gut my > system, or am I missing some detail and it's all good? As currently known if you run apt-get autoeremove it will remove those packages. But if you are using those packages then don't do that. :-) Instead simply mark them as being manually installed. Mark a few of the top level ones and then run autoremove, answer 'n'o. Then pick another top level package and mark it. Then run autoremove again and answer 'n'o again. Repeat until you have marked to keep all of the packages that you want to keep. Almost certainly along the way you will find some package that you don't want and will decide to let it go. The automatically installed list is just a helper to help you maintain your system. But it is a simple thing and doesn't know about all cases such as the removal of a kde meta package. You are certainly encouraged to use judgement and drive it the way you want. Bob signature.asc Description: Digital signature
