Thanks for another thorough reply, I'm a bit rushed to respond to much
of it, but hope this is better than nothing...
On Wed, 06 Sep 2006 16:20:35 +0000
"Thaddeus H. Black" <[EMAIL PROTECTED]> wrote:
> True. Regarding "university library," however, does an alternative
> occur to you? ...
"Public library" -- but no adjective is needed when the word
"books" is nearby to give context.
Here's that first paragraph again:
Debian GNU/Linux provides thousands upon daunting thousands of software
packages. Sorting them into broad classes then dividing and redividing
them into finer, more specific branches, this command ramifies Debian's
packages in much the same manner as a university library ramifies its
books. If you know what you want your computer to do but do not yet
know the package to do it, you can find the package here.
A couple tries at try at revising, or rather reversioning that, with
notes after. Historic approach:
---------
The Debian package format was first devised in 199X(3?) by Ian
Murdock (or somebody else), who ordered packages by topic with the
"Section" header, which divided all packages into about 38(???)
sections:
admin, alien, base, checkinstall, comm, devel, doc, editors,
electronics, embedded, games, gnome, graphics, hamradio, interpreters,
kde, libdevel, libs, mail, math, misc, net, news, non-US, oldlibs,
opera, otherosfs, perl, python, science, shells, sound, tex, text,
unknown, utils, web, and x11.
Over the years more sections were added:
....???...
...bringing the total up to 38(?).
As of 2006, Debian GNU/Linux provides over eighteen thousand packages; a
daunting variety of software, databases, and documents in dozens of
languages. Finding packages by "Section" is difficult, because 38 sections
are not enough for 18,000+ items.
'debram' was created in 200X(???) to remedy this problem.
'debram' has two parts, a database and a search command.
The 'debram' database organizes .deb packages into broad classes, then
divides and redivides those into easy to find branches, in the same
manner as a library catalogues its books.
The 'debram' search command is for when you know what you want your
computer to do but do not yet know the package to do it.
---------
Notes:
Facts that would need checking I've paired with question marks;
e.g. the early 'Section' number , and the list of 38 Sections is from
2006, surely a few Sections were added since 199X, so 38 is too many.
Section modifiers like 'non-free' or 'local' were ommited. To generate
that list, do:
% grep "Section:" /var/lib/dpkg/available | sort -u | grep -iv
contrib\\\|"non-free"\\\|local | while read a b ; do echo -n "$b, " ; done ;
echo
The exposition in the first three or four paragraphs might be reduced
and better illustrated with a table like this:
Year | Number of packages |Number of sections | Average pkgs
per section
199x | ? | 20 | x1
... | ? | ... | x2
2006 | ? | 38 | xn
No 'ramify' verbs. I'd bury the etymology under a NOTES header -- no
slight intended, but most readers will get along without knowing a
word's roots.
OTOH maybe the historic approach should be further down
under a less prominent header, and DESCRIPTION should just be
pure function, i.e.:
---------
The 'debram' command is for when you know what you want your
computer to do but do not yet know the package to do it.
To find packages about cooking, do this:
debram yadda yadda | grep...
---------
...and so on. Put history under a HISTORY header.
Wait, how does one find packages about cooking in 'debram'? I don't
know how to do that, it might make a poor first example.
> ...That's about the whole extent of the scheme; it's a fair bit of
> work but, conceptually, it's not much deeper than that...
Well you're doing a fine job at making those piles/branches.
Please recall that I never suggested 'debram' was (or should be)
modeled after either the Dewey Decimal or LOC system. To the contrary
I wanted to convey how _creating_ 'debram' was dissimilar to the way
most academic librarians _conform_ to a system they never made, and
therefore a university library (most are LOC) was not the best
comparison. Creating a system seems like a much bigger job.
> Regarding the distinction between Debram the data and debram(1) the
> program, you are absolutely correct. Early on, I had thought about
> giving the two different names, but in the end decided that two would
> be overblown. Of course debram(1) does not actually sort any
> packages, but one of the commonest errors in Debian manpages is to
> explain too many technical details too soon to people who just want
> to use the program a little (see the otherwise excellent exim4(8)
> manpage for a fine example of this error).
Good that you mentioned exim4. I just noticed a typo in 'man exim',
a new bug! Yet 'man exim4' isn't so bad... (the 'man find'
DESCRIPTION is worthy of a tipsy patent attorney).
On distinguishing, you could call the whole thing 'debram' but then
add suffixes to the various utils, maybe like 'debram-list',
'debram-find', 'debram-browse', etc. At present 'debram-browse' is
hypothetical, it'd be a web browser interface.
> ...Note: The etch freeze is now in its early stages but is underway,
> which for complex intra-Debian Project reasons limits what you and I
> can now do to debram for etch. Debram is an odd package: it gives
> metadata *on* packages, yet it *is* a package; so purely for practical
> Debian development reasons, debram must be handled with a little extra
> care. You and I can and should discuss and agree on changes now, but
> please don't be disappointed if some or all of the changes actually
> wait for etch+1.
No problem, my system runs 'unstable'. I agree that care is essential,
but haste is not. Besides, as can be seen above, any proposed
revisions are still in the outline stages.
BTW: thanks for the feedback for the outline. What makes man page
revision hard is that a technical topic may (at first) be known only to
a few, and sometimes those few hate working on docs. They might reason
that it all seems obvious to them, so why bother? When the able are
not willing, and the willing are not able, it's a recipe for
inertia. It's always good to hear from developers who don't take
clarity for granted.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
