Re: Next approach: Documentation Policy
Christian Schwarz writes:
> On Thu, 3 Jul 1997, Yann Dirson wrote:
>
> > Chris, Fernando:
> >
> > Did you have a look at my proposal under "On compilers, VM's, etc." ?
> > I think the ideas I expose in it would allow a quite more general
> > handling of all these document formats, and more.
>
> If I may summarize it: You suggest to "mix" our current source packages
> with binary packages since you consider the terms "source" and "binary"
> inaccurate. Thus, we would gain "source package dependencies"
> automatically, etc., and it would also make all "binary-arch" directories
> obsolete. Every "package" would depend on the necessary "vm's".
That is effectively what I proposed. Note though that I did not
propose to change the "binary-arch" way of handling things (even if it
could be seen as a natural consequence), and I do agree that
suppressing binary-arch dirs would be a bad thing (I do not want to
have all Packages files for all archs downloaded together with my
arch, and I guess most people don't), even if a new framework would
make it possible.
[Digression: just an idea that this last paragraph told me: it would
be great to have an easy way to know which packages do exist as source
(ie. they were made available in some arch.) but not yet on the one I
work on. This would speed-up the availability of packages. Does this
already exist ?]
Note that I agree that the fact this direct consequence is
unapplicable is a flaw in my proposal, and that consequently, it has
to be reworked. I'd only have hoped that I had more such feedback:
only the facts not covered by a model can keep it evolving... and I
alone cannot find them all.
> > It's certainly not ready to be applied right now, as we don't have the
> > necessary tools, but it should be seen as a medium-term proposal.
>
> This is surely a _very_ systematic approach! But what are the benefits
> from it?
* as you said, source-package dependencies.
* easy access to source packages (see my reply to Raul on Jul 3 for
why I consider that very useful).
* About docs, this would allow the sysadmins to choose what format
they will install, depending on their needs; this would solve the
problems about man/catman, texi/info/html/ps, and such.
* choosing the way multi-step conversions are done (eg. sdc used to
(and maybe still does, I don't really know) do sgml->ascii
conversion via lout. People who do not want to waste disk-space with
lout could just use groff as a second converter.
* this would make more accurate dependency control-field, by using the
transitive constructs I describe (about converters and VMs), though
this scheme could probably be applied to current package-scheme, by
extending the virtual-package feature.
> > I agree that it might increase the load of work for the developper,
> > but a great deal of work could be automated by the
> > in-archive-installation procedure.
>
> I'm sure it would bring us _lots_ of new work
Certainly to some extent. By as I already said, much work could be
automated (as package-build of converted stuff); thus the maintainer
would just have to upload sources packages, and once the package has
been validated, it can be converted to all needed formats.
Note that this last proposal is likely to more easily applied to
doc-formats than to binary formats... I guess it's not so easy to do
so with programs.
I'm also aware of the problem that mirrors would be overloaded by all
these different formats; the only alternatives I can think of right
now are:
- server-side on-the-fly conversion (with caching or not), which
requires more that FTP (eg. HTTP+cgi).
- client-side conversion on-install or on-the-fly conversion, both of
which have already been discussed here at length with no general
solution.
> I'm not sure what we would gain from it.
I hope this message helps...
Regards,
--
Yann Dirson <dirson@univ-mlv.fr>
http://monge.univ-mlv.fr/~dirson
--
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: