Karl O. Pinc wrote on: > The buster release notes should provide more specifics when it comes > to removing obsolete packages. > > The following patch makes 2 changes. > > It recommends removing packages that are obsolete in stretch before > beginning the upgrade to buster.
Good idea. > It provides commands, instead of vague TUI recommendations, describing > how to remove obsolete packages. This might be a good idea, but I don't agree with the implementation. The TUI reference currently in the text doesn't look vague to me, and the only reason to get rid of it would be if we wanted to eliminate references to aptitude in favour of apt. > + <para> > + It is a good idea to <link linkend="obsolete">remove obsolete > + packages</link> from your system before upgrading. > + </para> > + > <section id="proposed-updates"> > <title>The proposed-updates section</title> > <para> > @@ -1296,10 +1301,14 @@ $ aptitude purge '~c' > </para> > <para> > Detecting which packages in an updated system are > <quote>obsolete</quote> is easy since the If there's a line that needs changing, it's this one. To the best of my knowledge it's only aptitude and synaptic that provide this information, and synaptic's GUI requires you to go and look for it. > - 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. > + package management front-ends will mark them as such. > + The <systemitem role="package">aptitude</systemitem> commands to list > and > + purge obsolete commands are: > </para> > + <screen> > +# aptitude search '~o' (This one doesn't require root.) > +# 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 For actual aptitude users the easiest and most obvious way of finding the packages in question is to run "aptitude" (though in fact it's likely they would already have it open by this stage) and look to see if the TUI shows a line "Obsolete and Locally Created Packages". If there is, you can purge them all by highlighting the line and hitting "_g" (...and sanity-check what it says it's about to do, then...) "g". ("Obsolete" can be a confusing term; what aptitude means by it is "any installed package which is not available in any version from any [known] archive". So if you grab a single .deb out of experimental, that'll count as "obsolete"; if you create a local repository full of linux-1.0 kernel-packages, those won't. But if you aren't deliberately doing anything funny like that, the things that will naturally end up in this category are the packages you installed in an earlier release that aren't in the current release.) Maybe it should be something like <para> 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' $ sudo aptitude purge '~o' </screen> -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package