Bug#929003: release-notes: Provide specific instructions to remove obsolete packages
On Wed, 15 May 2019 12:59:04 +0100
Justin B Rye <justin.byam.rye@gmail.com> wrote:
> Karl O. Pinc wrote on:
> > The buster release notes should provide more specifics when it comes
> > to removing obsolete packages.
> > 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.
See comments on text below.
> > + <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.
I'm ignorant here and reluctant to make any changes.
> > - 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.)
Yes. See more comment below.
> > +# 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".
I'm an actual aptitude user, and pretty much the only time I've used
the TUI is when the release notes force me into it. I find working
in the TUI awkward and have had difficulty understanding what I'm
looking at and what will happen.
Anyway, I think giving command lines results in shorter and more
clear documentation.
> ("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>
I'm ok with that. In fact I like it. But I do have some comment.
First I don't like having sudo appear in commands, mostly because
it's not installed by default. Sure, it's a clear indicator that
you need to be root, and that's nice. But there are pluses and
minuses to sudo and it is not necessarily for everybody.
More significantly perhaps, it's really nice to be able to cut
and paste commands directly from the documentation. The appearance
of both sudo and a shell prompt character prevents this.
I think, for this case, if I had my choice, I'd prefer:
<screen>
aptitude search '~o' ;# Works when not root
aptitude purge '~o' ;# Requires root
</screen>
I'm not arguing hard here. This is a larger question
that requires consistency throughout the documentation.
I'm putting it forward here so people can think about it
and maybe the issues can be considered and consensus reached
in the future.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Reply to: