Bug#929003: release-notes: Provide specific instructions to remove obsolete packages
Karl O. Pinc:
> I can only give you my story.
>
> I chose aptitude ages ago for several reasons. At the time
> it had a better dependency resolution than apt-get. I don't
> even recall apt existing, or maybe it did but didn't do much.
/usr/bin/apt is recent enough that we've only just got the
release-notes consistently mentioning it.
> I like that "aptitude remove" also removes dependent packages
> not otherwise required. It also seemed to be more of a
> one-stop-shop, so once I know how to search I can use the
> same search to install/purge/etc. Little need to go messing
> around with apt-cache or other tools because of the search
> capabilities.
>
> (It would be cool if there was a way to also automatically
> remove packages installed because they were "recommended",
> but nothing recommends them any longer.)
I suspect a sufficient suppy of "aptitude search '?for x:'" logic
would work, but you run into all the complications of dependencies via
virtual packages, essential packages, and so on. The most complex I'm
prepared to try is
aptitude search '?for x: ?x:installed ?x:automatic
?x:provides(?virtual ?reverse-depends(?installed))
?not(?x:reverse-depends(?installed(?depends(?=x))))'
(which finds a lot of things held in by tenuous dependency chains),
but if the idea is to ignore "recommends/suggests" then it might be
easier to go via "aptitude -Ro APT::Install-Suggests=0".
> I took a quick look at apt, found the search output way
> too verbose and unable to be quickly scanned, and
> decided it was easier to stick with aptitude.
And if you try to feed its output through grep, it nags at you on
stderr. (In fact that's why the release-notes still mention apt-cache
instead of converting all those references to apt as well.)
[...]
> The trouble with the TUI is you have to learn how to use it.
You have to bear in mind that I was coming to it from dselect.
Okay, so now that I get round to trying to produce a patch I see that
there's already text under "Preparing for the next release" that
covers what you had in your first paragraph:
<para>
Remove newly redundant or obsolete packages as described in
<xref linkend="sufficient-space"/> and <xref linkend="obsolete"/>.
You should review which configuration files they use and consider purging
the packages to remove their configuration files. See also
<xref linkend="purge-removed-packages" />.
</para>
But then the rest modifies material under "Obsolete packages".
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index 30e138ab..a09675ee 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -1266,8 +1266,8 @@ Errors were encountered while processing:
can also use the following alternative to the commands above:
</para>
<screen>
-$ aptitude search '~c'
-$ aptitude purge '~c'
+# aptitude search '~c'
+# aptitude purge '~c'
</screen>
</section>
@@ -1295,11 +1295,16 @@ $ aptitude purge '~c'
case, packages might still be present in the <quote>unstable</quote> distribution.
</para>
<para>
- Detecting which packages in an updated system are <quote>obsolete</quote> is easy since the
- package management front-ends will mark them as such. If you are using
- <command>aptitude</command>, you will see a listing of these packages in the
- <quote>Obsolete and Locally Created Packages</quote> entry.
+ Some package management front-ends provide easy ways of finding installed
+ packages that are no longer available from any known repository. The
+ <command>aptitude</command> text user interface lists them in the category
+ <quote>Obsolete and Locally Created Packages</quote>, and they can be listed
+ and purged from the commandline with:
</para>
+ <screen>
+# aptitude search '~o'
+# aptitude purge '~o'
+ </screen>
<para>
The <ulink url="&url-bts;">Debian Bug Tracking System</ulink>
often provides additional information on why the package was removed. You
Reply to: