[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian-faq: Patch3 to update outdated information



Holger Wansing wrote:
> now the third patch to address more invasive things:
> 
> - I have updated info on release architectures
> - I removed/changed paragraphs about floppies (still someone using them? :-) )
> - I changed the description of apt (copied from official package-description
>   from packages.debian.org)
> - I added a mention of UTF-8
> 
> - Should we remove docu on dselect? (outdated tool)
>   That would also mean the removal of docu about dpkg-mountable.

dpkg-mountable was a Debian package up until 2.2 "potato", but as far
as I can see this information was stale by 3.0 "woody" in 2002!

> - Should we no longer mention the outdated repository-howto?
> - What about the modconf package/mechanism? Still required? Still existing?

The package ceased to exist in wheezy, but I think it had been largely
redundant for a while before that.

> A patch as a proposal is attached.
> 
> 
> Review and comments are here *really* wanted!

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.

[...]
> +++ customizing.sgml	(Arbeitskopie)
> @@ -17,8 +17,8 @@
>    without compromising security?
>  
>  <p>Many device files in the <tt>/dev</tt> directory belong to some
> -predefined groups. For example, <tt>/dev/fd0</tt> belongs to the
> -<tt>floppy</tt> group, and <tt>/dev/dsp</tt> belongs to the
> +predefined groups. For example, <tt>/dev/sr0</tt> belongs to the
> +<tt>cdrom</tt> group, and <tt>/dev/dsp</tt> belongs to the
>  <tt>audio</tt> group.

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.
  
> +++ 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.
  
> Index: getting.sgml
> ===================================================================
> --- getting.sgml	(Revision 11091)
> +++ getting.sgml	(Arbeitskopie)
> @@ -51,7 +51,7 @@
>  the <url name="Debian Security Manual"
>  id="http://www.debian.org/doc/manuals/securing-debian-howto/";>.
>  
> -<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.

[...]
>  <sect id="alternativebootinstaller">Are there any alternative strategies for booting
>  the system installer?
>  
>  <p>Yes.  Apart from CD or DVD, you can install Debian GNU/Linux by booting from
> -floppy disks, USB memory stick, directly from hard disk, or using TFTP net
> +USB memory stick, directly from hard disk, or using TFTP net
>  booting.  For installing on multiple computers it's possible to do fully
>  automatic installations.  NB: not all methods are supported by all computer
>  architectures.  Once the installer has booted, the rest of the system can be

(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!)

> Index: kernel.sgml
[...]
> +### There is no package "modconf" in stable anymore.
> +### Is there still such mechanism in Debian, or is it no longer needed?
> + 

I don't think I'd used it since the days of ISA network cards; the
idea seems to be that it was made redundant by autodetection, and then
thrown out during the switch from module-init-tools to kmod.

[...]
> Index: pkg_basics.sgml
> ===================================================================
[...]  
> @@ -360,8 +360,7 @@
>    <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?
  
>  <p>Their meanings are:
>  <list>
> @@ -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"...

[...]
>  <sect2 id="dpkg-split">dpkg-split

Is this utility even worth knowing about nowadays?  To be honest, even
in the nineties when I was ferrying "big" (multi-MB) packages about on
floppies I found it easier to use plain "split"...

[...]
> 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.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: