Re: Next approach: Documentation Policy
On Fri, 4 Jul 1997, Yann Dirson wrote:
[snip]
> [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 ?]
I think Guy planned to implement something like that. I think there will
be lists in the indices directory, that contain info about which packages
are available in which architecture in which version (which is also
important when packages are updated often).
> 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.
Sorry, I did not want to ignore your initial proposal. However, there were
so many opinions so I had to skip a few very "exotic" :-)
> > > 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.
Ok, but I think it's easier to implement them by adding a "Depends" field
to the .dsc file.
> * 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.
> * 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. And the
texi/info/html/ps thing will be handled with "doc-base" to make it easy.
Of course, if we would have more things like that, I could image some
advantages in your concept.
> * 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? And I expect that some
"sources" would have to be adopted too, to work with _all_ compilers.
> * 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...
> > > 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.
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.
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.
> > I'm not sure what we would gain from it.
>
> I hope this message helps...
Thanks for explaining it again. I got some impression of your ideas.
Thanks,
Chris
-- Christian Schwarz
schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Don't know Perl? schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/
--
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: