Quick Summary: Sounds good to me. Go for it.
On Wed, 15 May 2019 15:39:54 +0100
Post by Justin B RyeFor 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.
Post by Justin B RyeTo
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.
Post by Justin B RyePost by Karl O. PincPost by Justin B RyeMaybe 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.
Post by Justin B RyePost by Karl O. PincMore 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.
<screen>
aptitude search '~o' ;# Works when not root
aptitude purge '~o' ;# Requires root
</screen>
(No need for the semicolons.)
Post by Karl O. PincI'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.
Post by Justin B RyeIn fact I notice that <section id="purge-removed-packages"> in
<para>
If you use <systemitem role="package">aptitude</systemitem>,
</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 <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein