Re: Release notes
Steve Langasek wrote:
>> Going back to the aptitude non-olfactory mode nonsense, here's a patch
>> for that.
>
>> I'm standardising on "full-console mode", given that nobody has
>> suggested anything better.
>
> The reason no one has suggested anything better is that 'visual mode' is the
> *canonical name* for running aptitude in this mode.
You used the same argument for the Squeeze release-notes, and I gave
way just because your attitude was so straightforwardly unreasonable.
Not this time. I've seen users being misled by this name, and I don't
see why we should propagate it when we don't have to.
(But my reason for starting this argument early was that I'd have a
chance to shrug off its demotivating effects in time for the main
proofreading push.)
> Please don't have a
> proxy battle with the aptitude maintainer via the release notes - if you
> disagree with the name "visual mode", please get the aptitude documentation
> fixed *first*, rather than inventing inconsistent language that will be used
> only in the release notes.
Because apparently when a thing has an official name, that means it's
impossible ever to give it an intelligible *description* - you have to
stick to referring to it by the name, regardless of how baffling it
might be to your readers.
Even if Daniel wholeheartedly agreed with me, it would be too late to
get the fix into the aptitude documentation for Wheezy. So why
shouldn't I start at the end that just had a call for volunteers?
>> If you were about to object that the name isn't appropriate when you're in
>> an X session, bear in mind that we've already advised people not to run a
>> dist-upgrade that way.
>
> That advice should be obsolete with current releases; there's a 'fixme'
> already in the release notes about it, which hasn't been reviewed since
> 2008. Someone should double-check when removing this warning, but I'm
> rather certain that recent display managers don't have this problem.
Oh, that's good news - so even though gdm isn't in Wheezy, you can run
a dist-upgrade from a gdm session and you'll end up in a gdm3 session,
and we won't be recommending doing it from a VT instead? Surprising,
but even if true it doesn't quite add up to an argument against
describing aptitude's text-UI mode as "full-console".
It occurs to me that aptitude's full-whatever mode might also be
appropriately described as its "browser mode". If anybody has any
ideas that aren't "wontfix", I'm interested.
>> This patch also tweaks section 2.1.3:
>
>> The preferred program for interactive package management from a
>> terminal is _aptitude_. For a non-interactive command line interface
>> for package management, it is recommended to use _apt-get_. [...]
>
>> Obviously, if I say "apt-get purge dbus", it won't perform that action
>> "non-interactively", it'll ask "Do you want to continue [Y/n]?" - it's
>> just that it won't use a persistent textual UI. I'm rephrasing it as:
>
>> The preferred program for interacting with the package database from
>> a terminal is _aptitude_. For individual package management actions,
>> it is recommended to use _apt-get_ on the command line. [...]
>
> I don't think this text is an improvement.
It does at least avoid falsely describing apt-get's interface as
"non-interactive". However, it can probably be improved.
> "Individual package management
> actions" does not read to me as covering an 'apt-get dist-upgrade' that
> upgrades every package on the system.
Indeed it doesn't - that's covered in the following sentence
("_apt-get_ is also the preferred tool for upgrades...")! Sorry, I
elided that bit in the quote above because it didn't need fixing.
> Nor do I think "interacting with the
> package database" is a useful description of when one should prefer aptitude
> vs. apt-get - *all* packgae management operations are "interacting with the
> package database".
>
> The only case where aptitude should be preferred over apt-get is where the
> user wishes to fine-tune the package manager's solution.
Are you forgetting or for some reason discounting its other uses? For
instance, aptitude is obviously better when I just want to browse the
software that's installable; especially immediately after a
dist-upgrade when it catalogues the newly available packages.
> "Interactive" vs.
> "non-interactive" maps that as well as anything else I can think of, but
> perhaps you can think of another way to express this.
My idea was that talking about "interacting with" the package manager
would convey the same idea without implying that it's on the level of
"cp --interactive". But I have to acknowledge you've got a point
(because in effect it's the same as my own point!) - "interacting"
doesn't necessarily mean "within a persistent UI". I was vaguely
thinking of "interacting... in a terminal" as getting closer, but it's
not close enough.
This also brings up a further question. Is the "from a terminal" part
intended to be restrictive or descriptive? Is it saying "if you're in
a terminal, the best option for guddling with package management stuff
is aptitude (but if you're not in a terminal, stick to synaptic for
that kind of thing)"? Or is it saying "the best tool for the kind of
package management tasks that require a persistent interface is
aptitude's terminal UI"? Because if it's the latter, it probably
wants to be changed further. (If only to obey the principle that
aptitude's terminal UI must never be referred to via a description,
only via its one true name.)
So maybe it should be:
The preferred program for $ADJECTIVE interactions with the package
management system is _aptitude_ in whatever-we're-calling-it mode.
where $ADJECTIVE is... "sustained"? "Detailed"? "Extensive"?
"Hands-on"?
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: