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

      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:
      $ aptitude search '~o'
      $ sudo aptitude purge '~o'

JBR     with qualifications in linguistics, experience as a Debian
        sysadmin, and probably no clue about this particular package

Reply via email to