Re: Next approach: Documentation Policy
Christian Schwarz writes:
> On Fri, 4 Jul 1997, Yann Dirson wrote:
> > > This is surely a _very_ systematic approach! But what are the benefits
> > > from it?
> >
> > * as you said, source-package dependencies.
>
> Ok, but I think it's easier to implement them by adding a "Depends" field
> to the .dsc file.
Yes, maybe, but this would then require more work to allow source and
binary packages to be downloaded with the same interface.
> > * easy access to source packages (see my reply to Raul on Jul 3 for
> > why I consider that very useful).
>
> ? Just download the files pkg*.dsc, pkg*.diff.gz, pkg*.orig.tar.gz and
> that's it! Source packages are easy to access now.
Easy... I prefer selecting in a local list, and have all the dowload
stuff done automagically, than having to search in which section it
is, cd to the right directory, and ask lftp to get it. Sorry, I rarely
use a www browser for FTP, but I'd have anyway to know in which
section to search.
Think to all the people, ignorant of the way the archive is organized,
and who will not want to know that, and who nonetheless will want to
get the sources...
> > * 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.
>
> Ok, I can see your point. But man/catman is really no problem since
> "catman" is only temporary and the compilation is quite fast.
Yes, but some with low HD resources may like to have manpages just in
catman or html format... Few people really nead man sources!
> And the
> texi/info/html/ps thing will be handled with "doc-base" to make it easy.
Easy, but less homogeneous than with what I propose... I think it
would allow user-friendlier interfaces to the whole stuff.
> Of course, if we would have more things like that, I could image some
> advantages in your concept.
There will probably be: we already have to take sgml as a special
case; the near future will bring us XML (which hopefully is close
enough to sgml ot handled similarly); etc...
> > * 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.
>
> But who would write all those converters?
As usual ! Who wrote all this free software ? People who need it,
usually !
Surely all these possible converter won't be available at start, but
this mechanism at least will integrate them as soon as the will. What
about the present mechanism ?
> And I expect that some
> "sources" would have to be adopted too, to work with _all_ compilers.
??? could you reformulate ?
> > * 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.
>
> Why more accurate? The current scheme is working ok for me...
Did you look at the Recommend: field for fweb:
Recommends: gcc | fort77 | g77 | ratfor77
it should read:
Recommend: c-vm | c++-vm | f77-vm | f90-vm | ratfor77-vm | ratfor90-vm
This would allow any combination of converters to be used; this just
states you'll need someone to take advantage of those
formats/languages. The point is better illustrated by Jim, about Java,
JVM's, and such.
> > 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.
>
> There was no general solution since people's opinions differ to much at
> that point. Thus, I prefered letting the user choose at installation time.
No, there's no general solution. Thus Jim's suggestion of an
"intelligent" server handling particularities in a general way seems
fine to me.
> I think this is the most important aspect in your proposal (as it seems
> to me): you try to define very precisely which formats are included in a
> package (source, i386 bin, java, etc.). Then you have lots of "compilers"
> between these formats. This is, of course, a very flexible solution.
Not only file formats: how to convert from one to another, too.
--
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: