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

On compilers, VM's, etc. (Was: Next app.: Doc. Policy)

OK, it's time for me to expose some theory of mine. Note that it has a
mainly theoretical idea, and that the ways I propose to apply it WILL
(eventually) displease some of you. Please just try to get the basic
ideas, and comment...

1. basic ideas

Christian Schwarz writes:
 > No, I talked about the "*.info" files. Someone else said here, some time
 > ago, that the intention of a Linux distribution is to provide the people
 > with "compiled files", not with the source that everyone has to compile.

The basic idea is that I don't see the point of keeping such terms as
"source", "compiled", etc., at least as we use them now.

I would suggest we think in terms of "file formats", "converters" and
"virtual machines". This will provide some unification (IMHO) between
the formerly-discussed necessary future revision of the debian
source-packages handling, and the now-discussed problem of
documentation formats.

2. how these ideas apply to our problems

2.1 source/binary problem

Thus, for the 1st problem, we can leave out the standard source/binary
dichotomy: we have packages in the 'c', 'c++', 'java', etc. formats
(formerly called "source packages" by everyone); 'i386Opcode',
'm68kOpcode', 'javaBytecode', etc. formats (formerly called "binary
packages"). Not quite an advantage for now :)

Compilers are then c-to-i386Opcode-converter's, etc. (or rather
c-to-i386asm-converter's that need a i386asm-vm (virtual machine),
which could be provided by a i386asm-to-i386Opcode-converter a
i386Opcode-vm (aka PC-compatible linux-box), but that's not the main

A domain where this idea becomes a bit more powerful is for example
the one of literate programming systems (see [cf]web*.deb), where
we could speak of cweb-to-c-converter, and use transitivity:

fwebC++-to-c++-converter + c++-to-i386Opcode-converter + i386Opcode-vm
is functionnally equivalent to fwebC++-to-i386Opcode-converter +
i386Opcode-vm. Thus if a user gets a package in the 'fwebC++' format,
it can at his option choose:
 * a fwebC++-to-c++-converter, and a c++-to-i386Opcode-converter, as
   he already has the i386Opcode-vm;
 * a fwebC++-to-javaBytecode-converter, and a javaBytecode-vm (aka JVM);
 * etc.

2.2 documentation handling (at least, we've got there :):

'man' is a man-to-ascii-converter (or so), less is an ascii-vm, the
'texinfo' program is a texi-to-info-converter, a web-browser is an
html-vm, etc.

someone wishing to see all docs as text-format, because he (for any
reason I don't want to discuss here) will not use anything else, knows
he can do so with several file-formats because he has an ascii-vm
there are (or there can be):

 * texi-to-ascii-converter
 * sgmlDocument-to-lout-converter and lout-to-ascii-converter
 * sgmlDocument-to-groff-converter and groff-to-ascii-converter

The same for any other format, with surely variation on existing and
possible converters.

3. more concrete stuff

That is for theory, now let's try to see how we could apply this
concretely. Note that this is purely first ideas, which definitely
need to be reworked, and are as usual here to serve as a basis for
more reflexion.

 > Some people have slow computers, little memory, etc. and they surely don't
 > want to compile these files themselves all the time (whenever a package is
 > installed, upgraded, etc.).

We could:

- use a more homogeneous way of specifying the format of what's inside
a package (obsoleting Architecture: control field), with some
"Contents-format:" field, which could contain values such as "C",
"i386Opcode" ("i386elf" ?), "javaBytecode", "HTML", "texi", etc.
[Note: we'll then need some non-widespread-tool to unpack
"source-package", as some will say. But I don't think it's really an

- use virtual-packages like `c++-to-i386Opcode-converter',
`javaBytecode-vm', etc., with a vm systematically provided by the
system (eg: i386Opcode-vm)

- build transitivity rules in the install-tool (I never said we should
rely on the converters' names to do that; we could add control-fields
to pseudo-packages to handle input-format(s) (there can be several
files in different formats, to be combined, eg. SGML+DTD),
output-format(s), etc.)

- use suggests/recommends-like mechanism to say that a special
converter (eg. latex2html) should not be used on-the-fly on vm's less
powerful than one specified (eg. i986-vm :). Note that this will
require the i986-vm to provide i868-vm, and so on.

- provide packaged programs/doc at most formats. The multiplication of
package-files will be hidden by the install-tool, but the size taken
on the mirrors might be too much :( [Why: see jus below]

Sysadmins (or transparently, the install-tool, from informations
provided by the sysadmin) could choose which formats to install,
according to:

- which doc-formats they wish to provide to users (ie which VMs are
installed; maybe several ones, concurently (eg: we have both info-vm
and HTML-vm; we have both i386Opcode-vm and javaBytecode-vm), or with
system-preferences (eg: if there is info, take it, otherwise take
HTML, otherwise ascii; preferably i386Opcode, then javaBytecode))

- realistic (see suggests/recommends paragraph above) converters to be
used on-the-fly (with or without caching)

OK, now it's time for flames :)

Yann Dirson <dirson@univ-mlv.fr>

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . Trouble? 
e-mail to templin@bucknell.edu .

Reply to: