Bug#929003: release-notes: Provide specific instructions to remove obsolete packages
On Wed, 15 May 2019 22:17:10 +0100
Justin B Rye <justin.byam.rye@gmail.com> wrote:
> Karl O. Pinc:
> > 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 happy to install suggests, but it'd be nice to have the
suggests go away when I decide to remove the package that
caused them to be suggested.
> > 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.
The aptitude curses interface is clearly dselect compatible. :)
> 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>
Yes. But you do "Preparing for the next release" _after_ upgrade.
My suggestion is to _also_ tell people to get rid of obsolete
packages before they start to upgrade.
Once people upgrade they often don't prepare for the next release;
having gotten something working there's little reason to prepare
for the next release until the next release comes around. But
when there's a new release we don't tell people "go read the section
in your current release's release notes on preparing for the next
release and _then_ go read the release notes for the current release".
People should be able to just read the release notes for the new
release and follow only the instructions involving what it takes
to upgrade to that release. Surely removing leftover crud from
past upgrades should be part of what it takes to upgrade. (And
if people are too lazy to "finish", that's on them.)
Maybe the problem is in the title "Preparing for the next release"
because it's really about cleaning up after the previous release.
Even so, the instructions should allow for people who are untidy
for whatever reason. (And it's theoretically possible that
obsolete packages would disturb the upgrade process, yes?)
It seems worth an extra sentence.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Reply to: