Newsgroups: gmane.linux.debian.user Date: Thu, 19 Oct 2006 17:15:44 +0100
Newsgroups: gmane.linux.debian.user Date: Thu, 19 Oct 2006 17:15:44 +0100
>I re-read the aptitude reference [1], but I haven't found a way to get >the list of just the package I have installed manually, intentionally. >I have played with command such as these : > >aptitude search '!~M~i'
Strange, because that works just fine for me :-) But I've made sure that my markings in aptitude are correct:
http://therning.org/magnus/archives/132
>which give me the package that are installed (~i) and that were not >automatically installed (!~M) but it gives me all the package that are >installed by default on an etch + the one I want.
Have you been mixing use of apt-get and aptitude? Anything installed outside of aptitude is assumed to be explicitly installed (i.e. not marked auto).
Magnus Therning
> the list of just the package I have installed manually, intentionally.
I use this command to get a list of all the packages that are manually installed:
aptitude -F "%p" search \!~M~i~T
That includes essential packages, and doesn't include versions.
Owen Heisler
> > aptitude -F "%p" search \!~M~i~T > > > > That includes essential packages, and doesn't include versions. > > Did you manually installed the essential packages?
When Debian is first installed, all the installed packages are marked as manually installed in aptitude, so that was already done.
Owen Heisler
> >I've made sure > >that my markings in aptitude are correct: > > > > http://therning.org/magnus/archives/132[] > > # aptitude markauto '~i' > > aptitude wants to remove the majority of the packages: > > After unpacking 427MB will be freed. > > How do you change the marking without uninstalling them?
If you have configured aptitude to automatically install recommended packages then you have to run:
aptitude unmarkauto '~M!~R~i'
This will remove the "auto" mark from all packages that are not listed as a dependency of any other installed package.
If your aptitude only installs dependencies automatically then this has to be:
aptitude unmarkauto '~M!(~R~i|~Rrecommends:~i)'
This will remove the "auto" mark from all packages that are not listed as a dependency or a recommendation of any other installed package.
Your system should be more or less OK after that. However, there might still be a few packages which you have to "unmarkauto" manually.
Florian Kulzer
Newsgroups: gmane.linux.debian.user Date: Thu, 31 Aug 2006 18:23:08 +0200
I used to use debfoster to install/uninstall packages. My recent reading hinted that aptitude can be as smart as debfoster now. So I gave it a try.
But I found that aptitude doesn't even come close to debfoster:
% aptitude install apache2 The following NEW packages will be automatically installed: apache2-common apache2-mpm-worker apache2-utils The following NEW packages will be installed: apache2 apache2-common apache2-mpm-worker apache2-utils 0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded. Need to get 1055kB/1148kB of archives. After unpacking 3981kB will be used.
yes, work as advertised. But apt-get can do that too. Now how about removal?
% aptitude purge apache2
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following packages will be REMOVED:
apache2{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 81.9kB will be freed. Do you
want to continue? [Y/n/?]
Writing extended state information... Done (Reading database ... 134497
files and directories currently installed.) Removing apache2 ...
What? All the apache2-common, apache2-mpm-worker, & apache2-utils that get automatically installed are not touched:
$ dpkg -l | grep apache2 ii apache2-common 2.0.55-4.1 next generation, scalable, extendable ii apache2-mpm-wo 2.0.55-4.1 high speed threaded model for Apache2 ii apache2-utils 2.0.55-4.1 utility programs for webservers
This is unacceptably to me. These packages should be automatically purged as well. Or I'm doing something wrong?
The debfoster, OTOH, has never let me down on this.
Please comment.
T
> This is unacceptably to me. These packages should be automatically > purged as well. Or I'm doing something wrong?
You're probably doing something wrong.
One possibility that comes to mind is that you've _already_ got those packages installed, having using some other program than aptitude to install them — if that's the case, then aptitude won't know that those various libraries are "only dependencies" because it never had a chance to record that information. Aptitude is conservative, and assumes that any package it doesn't _know_ is automatically installed might have been installed intentionally by the user, and so shouldn't be automatically removed.
So basically, the first time you start using aptitude, you have to give aptitude that information, by marking as "automatically installed" all packages that you later want to be automatically deinstalled. After that, as long as you use aptitude to install new stuff, it will do do the appropriate marking for you.
[This step is actually pretty easy because you can use aptitude's powerful search and limiting commands to handle most of the common cases — e.g.: limit to only non-development libraries with the search pattern (^lib)!(-dev$), and mark them all as "autoinstalled" (with one keystroke); limit to all packages with names matching (-base|-common), mark them; etc.]
Miles
> What? All the apache2-common, apache2-mpm-worker, & apache2-utils that > get automatically installed are not touched:
It is weird — works for me. Can you go to aptitude and check these packages which should be removed, whether they have A to the left of the name of the package? Something like this:
i A kdelibs4c2a 4:3.5.4-3 4:3.5.4-3
If they don't, you can fix it "manually" by Shift+M, which should make them ready to be deleted. However, why they are not marked so, I have no idea — it just works for me. Otherwise you can investigate which packages claim to be dependent on them (Reverse dependency — Shift+R).
Somebody else could chime in?
Matej Cepl
> Somebody else could chime in?
Maybe there is a configuration setting that tells aptitude not to remove unused packages automatically. (This is configurable and I am not sure what the default setting is.)
The easiest way to check this is probably to start aptitude in interactive mode, press CTRL + T to activate the menu, go to "Options", "Dependency handling" and verify that the item "Remove unused packages automatically" is selected.
Florian Kulzer
2006-05-17
I have to say I was a little worried when I saw the installation notice during a recent upgrade of debfoster. It had been deprecated, abandoned by its developers, and instead I was being encouraged to use aptitude. So, I was being forced to give up my favourite package tool for a tool that I've started a few times but always found too confusing to invest time in learning.
My first step was the transition from debfoster to aptitude. I tried out the debfoster2aptitude script that was added to the last upgrade of debfoster but quickly realised that it was asking questions on a level that was way too low. I decided to do it manually instead. First I minimised my list of packages in debfoster and saved a copy of it:
# debfoster # debfoster -qmn # debfoster -a > ~/debfoster_keepers
Then I turned to aptitude. First I marked all packages as automatically installed (auto) from the command line:
# aptitude markauto '~i'
Then I marked each of the packages in /root/debfoster_keepers as not auto. I did this using the UI, which was both boring and time consuming. It should be easy to wip up a shell script for it, but I felt I needed to get used to aptitude's UI a bit. After this I went on to see what the damage would be-I hit 'g' to add/remove packages. As expected there were a few packages in there that I had to tell aptitude to keep installed for me. No big deal.
One interesting thing about aptitude is that it doesn't just keep depends of packages, it keeps recommends as well. To see if I could further trim the list of non-auto packages I started looking at the ways to filter the view of packages. I didn't quite succeed on my own, but after a few emails to the Debian User List I had a nice filter expression:
~i!~M(~R~i|~Rrecommends:~i)
It will show any installed packages that aren't auto which are dependencies or recommendations of other packages. In short, packages that aren't marked auto but could (should?) be. Be aware though that circular depends/recommends prevents all packages in that list to be marked auto.
Another cool thing is the "Audit recommendations" view in aptitude. It's a great way of finding related packages and improving the functionality of the system. If you want to also see the suggests of installed packages you can change the filter in that view to:
!~v!~i(~RBrecommends:~i|~RBsuggests:~i)
By now I'm not too sad that debfoster is being removed, aptitude actually doesn't suck
Date: 16-06-2006 Posted in: uk.comp.os.linux
I'm running Debian Sarge on a very modestly-sized partition. I'd like to remove a few packages I don't care about, but aptitude won't remove a package without also removing its dependents. Thus removing something like kolourpaint will remove kdegraphics will remove kde. Yuk.
To get round this, I've been using dpkg to purge the packages I don't want, but the problem here is that the next time I use aptitude, it detects the "missing" packages and reinstalls them.
Is there a way round this, or do I just have to stick with dpkg if I don't want stuff reappearing?
> I'd like to remove a few packages I don't care about, but aptitude > won't remove a package without also removing its dependents. > Thus removing something like kolourpaint will remove kdegraphics > will remove kde. Yuk.
kdegraphics is just a meta-package which depends on kolourpaint, among others. Similarly, kde is a meta-package which depends on kdegraphics. aptitude is behaving reasonably here. Moreover, it doesn't remove any 'real' packages apart from the one you specified, i.e., kolourpaint.
Liam
> Is there a way round this, or do I just have to stick with dpkg > if I don't want stuff reappearing?
There are two situations that typically give rise to a dependency relationship;
A case of actual dependency, where the dependant package will be broken in the absence of the dependency, in which case you really don't want to force the removal.
A meta package; most distro provide metapackages that don't actually contain anything useful themselves, but depend on a set of packages that you would often want to install together. In this case there's no point forcing the system to keep the metapackage since it's not actually doing anything anyway.
In this case 'kde' is almost certainly such a metapackage, removing it won't take off the whole of KDE, it will leave all the bits of KDE that you have installed alone, except the individual bit (kolourpaint) that you're wanting to remove.
To be sure you could list the contents of the kde package by doing:
$ dpkg -L kde
and checking that there's nothing beyond the usual barebones docs in the kde package. This shows that it is indeed a metapackage, and you can let aptitude remove it without breaking anything.
Ewan