Bug#929003: release-notes: Provide specific instructions to remove obsolete packages
Quick Summary: Sounds good to me. Go for it.
On Wed, 15 May 2019 15:39:54 +0100
Justin B Rye <justin.byam.rye@gmail.com> wrote:
> Karl O. Pinc wrote:
> > Justin B Rye wrote:
> For things that the apt commandline can also do, I've never quite
> understood why anyone would bother typing in the extra "itude".
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.
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 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.
> To
> me, the thing that makes aptitude worth having is the TUI: it gives an
> overview of what you've got installed, it makes it easy to find new
> things to install, and most important of all it makes it possible to
> get into arguments with the package management system when the
> dependencies on some trivial utility expect you to want to install a
> whole desktop environment. That's not going to be everybody's cup of
> tea, but in the case of checking for obsolete packages all they need
> to do is open the TUI and see if the category exists.
Well, you need to see if it exists and if it does you need to
look at what's in the category and _do_ something. Even looking
at what's there, iirc expanding the section(s?), involves
cognitive overhead.
The trouble with the TUI is you have to learn how to use it. Not
that hard, but one more thing that's different from every other
interface. And the single letter commands spook me. Once the
cat steps on the keyboard you don't know what happened to your
system. Interpreting what you're looking at is also non-trivial
to the uninitiated. What's hidden, what's not, what sections
you're looking at and what you need to look for, etc.
I recall being vexed by having to expand sub-sections individually
to see what I'm doing. I don't know how to avoid the statefull-ness
of pending actions but they also add stress. How can you
be sure that you didn't leave some pending actions laying
around some time ago that will now break things when you
effectuate your new changes? In the end, the TUI does not impress.
I don't know that it's feasible but I'd be much more comfortable
with a dialog style interface.
I generally don't have the confidence to want to argue with
package dependencies.
> >> 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.
> > 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.
>
> True; it might be better to separate them into two separate
> <screen></screen> blocks. To me, putting them in one block implies
> you could cut&paste them both together.
I agree this is an issue.
But once they are in separate screen blocks you almost have
to put some explanatory text in between the blocks. This lets
you talk about whether root is required but also adds
to visual bloat and consequent intimidation.
Somewhere there's a balance between clarity and brevity and I don't
know where you want to strike it.
>
> > 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>
>
> (No need for the semicolons.)
>
> >
> > 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.
>
> The convention of using a leading shell prompt to distinguish commands
> that do or don't need root privileges does occur elsewhere in the
> release notes, but now I look at them I see there are plenty of cases
> where commands that would work for ordinary users are given a leading
> hash, so we should probably just do the same here, as you originally
> had it.
I have no strong preference.
> In fact I notice that <section id="purge-removed-packages"> in
> upgrading.dbk has another instance of this same problem:
>
> <para>
> If you use <systemitem role="package">aptitude</systemitem>,
> you can also use the following alternative to the commands above:
> </para>
> <screen>
> $ aptitude search '~c'
> $ aptitude purge '~c'
> </screen>
>
> where that second line *shouldn't* start with a "$".
I noticed this once upon a time, probably when upgrading to stretch,
didn't report it, and forget about it. Good catch.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Reply to: