Karl O. Pinc wrote:
> Justin B Rye wrote:
>>> +# 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.
For things that the apt commandline can also do, I've never quite
understood why anyone would bother typing in the extra "itude". 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.
> Anyway, I think giving command lines results in shorter and more
> clear documentation.
I can't argue with the "shorter" part.
>> ("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.
(Only in some senses of "by default". Most desktops seem to pull in
things that depend on sudo unless you're actively working towards a
lightweight install - which is another of those things I'd hate to
have to do without the aptitude TUI!)
Nitpicks aside, yes, it's worth avoiding if possible.
> 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.
> 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.
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 "$".
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
