> % man debram | grep -C 1 -n ramifies > 14- packages. Sorting them into broad classes then dividing and > redividing > 15: them into finer, more specific branches, this command ramifies > Debian's > 16: packages in much the same manner as a university library > ramifies its > 17- books. If you know what you want your computer to do but do > not yet > > ...particularly "this command ramifies...", and "a ... library > ramifies...". > > Correct me if I'm wrong, but the 'debram' command lists selections from > files such as "/usr/share/debram-data/debram.txt.gz", and it's those > data files that comprise a classification system, (or tree, or > ramification), and that system was made by you, not the 'debram' > command. The command displays but does not create data.
Right.
> On "university library" -- the adjective "university" isn't precise,
> because public libraries have catalogs too, and libraries do not ramify
> or classify, librarians do.
True. Regarding "university library," however, does an alternative
occur to you? It used to say "city or university library," which was
more accurate but too heavy. One would like to say simply, "library,"
except that in a Debian context it makes one think of /usr/lib/libc.so,
not of a building with books! "Bibliotheque" would be better, but that
word is too fancy for English. So, "university library" is an imprecise
compromise. It brings more or less the right image to mind without
spending too many words to do it.
If a better expression occurs to you---an expression which is more
accurate but not longer or harder to read---please do give it.
> Obviously it's a figure of speech to refer
> to an institution for an individual, (Greek rhetoric must have word for
> it), but that instance of the figure seems odd somehow -- a librarian
> would never say that, it would deprive their undervalued profession of
> what little respect it receives. They say things like "the library
> will close in 15 minutes", or "the library needs more funds", but not
> "the library has chosen to put 'Peanuts' in the 741s".
>
> Furthermore most academic and many city libraries use the LOC catalog,
> (Library Of Congress), which as I understand it, allows no leeway -- in
> Public Libraries a Dewey Decimal librarian might file a nonfiction book
> under any subject they prefer, and even decide whether a book is put in
> nonfiction, ('Peanuts' could go either way), but the LOC is
> inflexible. A typical Univ. Lib. or librarian does not actually
> ramify, they acquire, record, and shelve, excepting perhaps they're
> currently the officially appointed guardian of some LOC
> subclassification.
Do you know, Enrico Zini tried to tell me something like this once. He
passed me advice from some famous master librarian named Ranganathan.
Unlike you and Enrico, though, I do not understand formal library
science. I admit it. Debram began not because I had library-scientific
aspirations but because Debian was a BIG HEAP of 4000 (now 17000)
packages, and like you, I couldn't ever find anything in the heap. So I
started sorting the packages into piles, then the piles into smaller
piles, and so on until the debram you now have resulted. When new
packages enter Debian testing nowadays, I assign them numbers (sometimes
with help from Anoop Rajendra); and when it seems necessary I open up a
new branch number. 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.
Obviously, the debram numbering system has roughly the same idea as a
Dewey or an LOC, but I had not known about the philosophical difference
between those two competing "bibliotheque" catalog numbering systems.
Debram is not explicitly modeled after either one; it's just a scheme
for numbering the little piles of Debian packages. The top level of the
debram system, in fact, just follows approximately the traditional Unix
man sections---ram 1000 for man section 1, ram 2000 for man section 2,
etc.
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). For the occasional serious user like you who actually
wants to learn how debram works, I *think* that debram is pretty
transparent.
Nevertheless, if a better expression occurs to you---more accurate but
not less accessible---then I should be glad to receive it. If the man
page confuses users to think that debram(1) somehow exercises artificial
intelligence, then this is a "Severity: important" bug which needs
correcting immediately. Of course all the numbers are preassigned by a
human (usually me). The assignment is in /usr/share/debram-data/.
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.
--
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED]
signature.asc
Description: Digital signature
