Re: debian-faq: Patch3 to update outdated information
Holger Wansing wrote:
>> Comments below; meanwhile I should go and have a look at the full FAQ.
>> Yes, its answers badly need revising; but in principle we ought to be
>> doing something much more invasive, replacing Questions that are no
>> longer Frequently Asked.
>
> Removing some of that questions would be good indeed.
Or indeed adding new ones. Newcomers probably have questions these
days about things the FAQ is too old to know anything about, like
systemd, or wifi firmware, or multiarch, or even Ubuntu.
>> I think /dev/dsp is a relic from the days before ALSA; these days it's
>> /dev/snd/*, and the access rights are increasingly handled via ACLs
>> managed by logind.
>
> Yes, /dev/dsp is not existing on my Jessie system.
> So we could use "/dev/sda" instead, as owned by group "disk".
Yes, that example still works, but it would be unusual to add a user
to that group... is "cdrom" still useful, perhaps?
> That should be rephrased then, to document the new behaviour.
> Has someone with the relevant knowledge a small proposal for this?
> (I'm lacking knowledge here, sorry.)
The trouble is, systemd has essentially deprecated all the advice
given in this section. Mind you, I don't really understand why the
FAQ was explaining it, since it's in no way specific to Debian or even
Linux.
>>> +++ ftparchives.sgml (Arbeitskopie)
>>> @@ -426,4 +426,6 @@
>>> Instructions on how to do this are given in the (obsolete) <url name="Debian Repository
>>> HOWTO"
>>> id="http://www.debian.org/doc/manuals/repository-howto/repository-howto";>.
>>> +# Should this link to outdated docu be removed? Or is it better, to keep it,
>>> +# since outdated docu is still better than nothing?
>>
>> It occurs to me that all this advice pre-dates the Debian Wiki.
>> Maybe there should be a pointer in that direction instead.
>
> Perhaps
> https://wiki.debian.org/HowToSetupADebianRepository
> would be a possible target?
A good example of the Debian Wiki working how it ought to!
>>> Index: getting.sgml
[...]
>>> -<sect id="boot-floppies">Where/how can I get the Debian installation disks?
>>> +<sect id="boot-disks">Where/how can I get the Debian installation disks?
>>
>> The problem with "disks" is that we're now using it mostly as a
>> coverterm for optical media (e.g. compact discs) and SSDs (e.g. USB
>> thumbdrives), and neither of those are technically "disks"!
>>
>> We could say "installation media", but then there's a danger of
>> singular agreement problems.
>
> Maybe use "installation images"?
Well, it says you get the *disks* by downloading the appropriate
*files*, so I was imagining that it was making a careful distinction
beteween installation *media* and installation *software* (and that
maybe later it would mention the possibility of getting disks some
other way). But looking at it again I don't think so.
Taking a step back, it no longer really makes any sense for this
section to be separate from the one about installing Debian from
CDs. And why point at "http://www.debian.org/mirror/list";?
The questions seem to me to be, very roughly:
Q) How do I install Debian?
A) Easy: get an appropriate form of Debian-Installer image, put it on
a CD or USB thumbdrive, and boot off that to start the install
process.
Q) What do you mean by "appropriate"?
A) That's where it gets complicated. See https://get.debian.org!
>> [...]
>> (I can personally vouch for the fact that it's still possible to do
>> Jessie installs off 2GB PATA hard disks and even iOmega Zip disks!)
>
> Ok, but I would value this as a corner case, so not mention in the FAQ.
Definitely - I'm not planning to do it again.
>>> Index: pkg_basics.sgml
[...]
>>> <em/purge/ and <em/hold/ in the package status?
>>>
>>> <p>These "want" flags tell what the user wanted to do with a package (as
>>> -indicated either by the user's actions in the "Select" section of
>>> -<tt>dselect</tt>, or by the user's direct invocations of <tt>dpkg</tt>).
>>> +indicated by the user's direct invocations of <tt>dpkg</tt>).
>>
>> Hmm, what "flags" is it thinking of? Should we also mention
>> apt/aptitude, given that marking a package for removal in aptitude's
>> console UI is another way of applying a persistent status?
>
> The corresponding question for this is
> " What is meant by <em/unknown/, <em/install/, <em/remove/, <em/purge/ and
> <em/hold/ in the package status?"
I was imagining it might be talking about flags that used to be
displayed in dselect, but no, I think it just means "dpkg --list".
Except that technically those are the "desired" flags, not the
"status" flags, and the packages it tags as "unknown" can include
things I purged just five seconds ago - it's not "the user hasn't
said", it's "I threw that information away".
>>> @@ -377,8 +376,7 @@
>>>
>>> <sect id="puttingonhold">How do I put a package on hold?
>>>
>>> -<p>There are three ways of holding back packages, with dpkg, aptitude
>>> -or with dselect.
>>> +<p>There are two ways of holding back packages, with dpkg or aptitude.
>>>
>>> <p>With dpkg, you have to export the list of package selections, with:
>>> <example>dpkg --get-selections \* > selections.txt</example>
>>
>> Oh, and you can now also use "apt-mark (un)hold"...
>
> Good point, added.
I hope you remembered to reset it to "three ways".
>>> Index: uptodate.sgml
>>> ===================================================================
>>> --- uptodate.sgml (Revision 11091)
>>> +++ uptodate.sgml (Arbeitskopie)
>>> @@ -68,13 +68,13 @@
>>> <p>For details, see the manual page <manref name="aptitude" section="8">,
>>> and the file <file>/usr/share/aptitude/README</file>.
>>>
>>> -<sect1 id="apt">apt-get, dselect and apt-cdrom
>>> +<sect1 id="apt">apt-get and apt-cdrom
>>>
>>> <p>An alternative to <prgn/aptitude/ is <prgn/apt-get/ which is
>>> APT-based command-line tool (described previously in <ref id="apt-get">).
>>>
>>> -<p>Both <prgn/apt-get/, the APT-based command-line tool for handling packages, and
>>> -<prgn/dselect/, provide a simple, safe way to install and upgrade packages.
>>> +<p><prgn/apt-get/, the APT-based command-line tool for handling packages,
>>> +provides a simple, safe way to install and upgrade packages.
>>
>> This repeats "APT-based command-line tool". Ideally we'd rewrite it
>> to talk about apt as the "primary" interface and things like apt-get
>> and aptitude as alternatives to that.
>
> Starting with Stretch, apt-get and apt-cache calls are changed and
> can also be called directly simply via apt:
/usr/bin/apt is in Jessie (with all the options listed below), and I'm
not aware of any changes to apt-get and apt-cache.
> apt update
> apt upgrade
> apt full-upgrade
> apt remove pkg
> apt install pkg
> apt show pkg
> apt search str
>
> As a result, should we no longer speak of the programs apt-get or
> apt-cache, but always speak of apt instead?
There are still a few "advanced" uses that require the old utilities
(apt-get source, apt-cache madison), but in general, yes. This may
require some rephrasing to keep it clear whether we mean apt the
binary, apt the package, or apt the holy^W infrastructure.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: