On Sun, Jun 29 1997 12:11 +0200 Christian Schwarz writes:
> Packages that contain programs with GNU info manuals, should provide
> the manuals in HTML _and_ in GNU info format. The HTML files should be
Shouldn't this read texinfo? --
> stored in the directory
> /usr/doc//ht
Hi folks!
Here is another proposal for our new "Documentation Policy". This
time, I have added a list of assumptions, on which this proposal is
based on.
Note, that this is not the actual text that will be included in the
Policy Manual, but a list of statements such a text will b
> MB> Why should we ship info files? HTML is better format. The most
> MB> system will use HTML as their help system in the future. KDE for
> MB> example uses HTML.
>
> The Info format is a lot better, tecnically, than HTML. That's what
> I've heard. Maybe the problem is that there is no Info brow
On Tue, 24 Jun 1997, Joey Hess wrote:
> I haven't been following this thread closely (catching up on mail backlog
> after vacation), but the reason I've heard why it's not acceptable to ship
> only info files and convert to html on the fly is because the converter in
> dwww that does this produces
Am 23.06.97 schrieb schwarz # monet.m.isar.de ...
Moin Christian!
CS> Option 3: We ship .texi files and produce HTML and/or info files on
CS> demand (in the postinst script).
Oh no. That's a very bad idea. All converters like latex2html, sgml-tools,
texi2html produce not very per
> Philip Hands writes:
> > There is of course a problem with trying to install all the
> > documentation on a machine, since some conflicting packages
> > provide man pages with overlapping names.
>
> I think that the 'alternative' mechanism could be used there.
I was thinking about the possibili
Hi,
>>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
Philip> I was thinking about the possibility of offereing _all_ Debian
Philip> documentation on a web site --- which lpr(1) man page would
Philip> you want to show? lpr's or lprng's?
Philip> Perhaps man pages should really go in
Philip>
On 25 Jun 1997, Manoj Srivastava wrote:
> >>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
>
> Philip> I was thinking about the possibility of offereing _all_ Debian
> Philip> documentation on a web site --- which lpr(1) man page would
> Philip> you want to show? lpr's or lprng's?
>
> Phi
Marco Budde wrote:
>
> CS> Option 3: We ship .texi files and produce HTML and/or info files on
> CS> demand (in the postinst script).
>
> Oh no. That's a very bad idea. All converters like latex2html, sgml-tools,
> texi2html produce not very perfect HTML code. You've to edit the H
Yann Dirson <[EMAIL PROTECTED]> writes:
[snip - bandwidth, disk space]
> Please support me, someone :)
OK, I *do* like the idea of having the documentation split out of the
package, in different formats. Deity will need to be pretty smart to
handle me wanting to install just the documentation f
> "MB" == Marco Budde <[EMAIL PROTECTED]> writes:
MB> Why should we ship info files? HTML is better format. The most
MB> system will use HTML as their help system in the future. KDE for
MB> example uses HTML.
The Info format is a lot better, tecnically, than HTML. That's what
I've heard. Mayb
Bruce Perens wrote:
> Rather than make any of lynx, dwww, and boa part of the base system,
> I'd mark them "important". The base system has the sole purpose of
Yes.
> editor the user has selected). In the case of a floppy install, the user
> would probably prefer that we not add another three f
Am 25.06.97 schrieb joey # kite.ml.org ...
Moin Joey!
JH> I haven't been following this thread closely (catching up on mail backlog
JH> after vacation), but the reason I've heard why it's not acceptable to ship
JH> only info files and convert to html on the fly is because the converter in
JH> dww
Am 26.06.97 schrieb alegre # saturn.superlink.net ...
Moin Fernando!
a> If we want to have HTML as the default we would have to put some effort
a> into fixing bugs in the converters. A converter fixed means many documents
a> fixed, while a document fixed is just one document fixed. We would have
From: Yann Dirson <[EMAIL PROTECTED]>
> * it will cost bandwidth when you just want to install either
> binary-only or doc-only, using FTP
>
> * further more, it will cost money to users as pay for local calls,
> here in France
>
> * it will cost disk-space on mirror sites, as debian will probabl
> *) The default format should be HTML, but everything necessary to
> view the documents should be provided as part of the base system.
> This includes a default HTML viewer (lynx), which users can override
> by means of the update-alternatives method. It would also include
> a default HTML server,
From: Christian Schwarz <[EMAIL PROTECTED]>
> This quotation is not complete and thus incorrect!
OK - I just wanted to make sure the policy direction wasn't going toward
un-bundling all documentation. Sorry!
Bruce
--
Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502
Finger [EMAIL PROT
Philip Hands writes:
> There is of course a problem with trying to install all the documentation on
> a
> machine, since some conflicting packages provide man pages with overlapping
> names.
I think that the 'alternative' mechanism could be used there.
--
Yann Dirson <[EMAIL PROTECTED]>
h
Bruce Perens writes:
> From: Philip Hands <[EMAIL PROTECTED]>
> > I think we should aim to get all documentation into separate packages.
>
> Please don't do this. Deity will have the capability to exclude installation
> to certain directories (like /usr/doc) based on a system "policy file".
Bruce Perens wrote:
> From: "Scott K. Ellis" <[EMAIL PROTECTED]>
> > I have no problem when HTML is the provided upstream documentation source,
> > and don't want to cripple my ability to read that. However, when the
> > upstream source is something else, such as info/texinfo, I don't want HTML
> "Philippe" == Philippe Troin <[EMAIL PROTECTED]> writes:
Philippe> On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz
Philippe> ([EMAIL PROTECTED]) wrote:
>> Option 3: We ship .texi files and produce HTML and/or info files on
>> demand (in the postinst script).
Philippe> I like t
[Sorry, Alex, I wanted to send this to you _and_ the mailing list in the
first time. So here it's again.]
On Tue, 24 Jun 1997, Christian Schwarz wrote:
Hi folks!
Please let me quote from my last mail, first:
> My prediction is that while a few people will like option 3) very much,
> it will
On Tue, 24 Jun 1997, Bruce Perens wrote:
> On Tue, 24 Jun 1997, Philip Hands wrote:
> > Even if we are, I'm sure it would be easier if every package `foo' had
> > one or more associated `foo-doc' packages.
>
> From: Christian Schwarz <[EMAIL PROTECTED]>
> > We are currently planning such a thing
[EMAIL PROTECTED] (Bruce Perens) writes:
> I-search would take a Java-equpped browser as far as I can tell. It's
> not do-able all in free software today. That will not be the case forever.
Right. Also might be do-able as a hack in something like dwww
(assuming I understand what it's doing) or w
From: Rob Browning <[EMAIL PROTECTED]>
> That was me. I guess the cgi approach would make stuff like recursive
> incremental searches (a la C-s in the info tool) out of the question,
> but I kind of figured that was a losing battle.
I-search would take a Java-equpped browser as far as I can tell.
From: Mark Eichin <[EMAIL PROTECTED]>
> After all, as a *package maintainer*, I want it to be *difficult* for
> a user to accidentally not install documentation; I want them to have
> to deliberately go out of their way if they want to fail to install it.
That's how I feel.
Thanks
James R. Van Zandt:
> Christian Schwarz <[EMAIL PROTECTED]> proposes:
> >
> > The documentation will be distributed via several packages:
> >
> > foo-doc-html for HTML docs
> > foo-doc-info for GNU info docs (where available)
> > foo-doc-xxx for oth
[EMAIL PROTECTED] (Bruce Perens) writes:
> Someone brought up the point of recursive regular-expression
> searching. Of course this should be done with a CGI script rather than
> as a browser facility, so that it would be browser-independent. One
> could build a tiny search engine with zgrep and
That makes sense (using deity support for the exclusion, I mean.)
After all, as a *package maintainer*, I want it to be *difficult* for
a user to accidentally not install documentation; I want them to have
to deliberately go out of their way if they want to fail to install
it. (After all, I want th
Santiago Vila Doncel:
> On Mon, 23 Jun 1997, Christian Schwarz wrote:
> > Option 3: We ship .texi files and produce HTML and/or info files on
> > demand (in the postinst script).
Rather, I'd like us to ship .texi or .info files and produce html on demand
via dwww or some equivialnt.
On Tue, 24 Jun 1997, Philip Hands wrote:
> Even if we are, I'm sure it would be easier if every package `foo' had
> one or more associated `foo-doc' packages.
From: Christian Schwarz <[EMAIL PROTECTED]>
> We are currently planning such a thing for our own manuals. The
> discussion was on debian-do
From: Clint Adams <[EMAIL PROTECTED]>
> What exactly is the rationale behind the HTML mandate?
We wanted to have a single interface to present all Debian documentation.
We looked at the various means of displaying documentation, and it was
clear that we could convert almost any documentation to HT
From: Santiago Vila Doncel <[EMAIL PROTECTED]>
> Well, I think that it would be much cleaner for deity to have the ability
> of "grouping" a set of packages to be installed at once instead of
> doing partial installs of larger packages.
Yes, we did discuss that.
> Moreover, we would not lost our
> Well, you're going to need a script to implement that policy. Probably
> the best way to handle this is to provide a way to tell the package system
> that you have deliberately removed a file, and that this file should not
> be replaced. I wouldn't expect this in version 1.0 .
What exactly is th
-BEGIN PGP SIGNED MESSAGE-
On Tue, 24 Jun 1997, Bruce Perens wrote:
> From: Philip Hands <[EMAIL PROTECTED]>
> > I think we should aim to get all documentation into separate packages.
>
> Please don't do this. Deity will have the capability to exclude installation
> to certain directorie
> For Deity, I suppose we could make pattern-matching work in the policy file.
I think that would be preferable to simple directory exclusion.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
On Jun 24, Santiago Vila Doncel wrote
>
> But I still dislike automatic building. If you just want not having to
> fetch the source package, what about a foo-doc-texi binary package (on a
> "do whatever you want with it" basis), which just ships the .texi source?
Better still (IMO, of course :) w
Mark Eichin writes:
>
> > /usr/info/emacs-info. I suggest to split this off into a new package
> > called "emacs-doc-info". In addition, we should create an "emacs-doc-html"
>
> Interesting. Not really an option, though; as far as emacs is
> concerned, that's part of how it documents itsel
James R. Van Zandt writes:
> There is an alternative I think we should consider. Let each binary
> package include both .info and .html files. Give dpkg two additional
> switches --no-html and --no-info which would be used with -i. These
> would cause dpkg to immediately remove /usr/doc/foo/
From: "Scott K. Ellis" <[EMAIL PROTECTED]>
> I have no problem when HTML is the provided upstream documentation source,
> and don't want to cripple my ability to read that. However, when the
> upstream source is something else, such as info/texinfo, I don't want HTML
> as well.
Well, you're going
-BEGIN PGP SIGNED MESSAGE-
On Tue, 24 Jun 1997, Bruce Perens wrote:
> From: Clint Adams <[EMAIL PROTECTED]>
> > What if one wants to exclude only HTML documentation?
>
> Well, for now
>"find /usr/doc -name '*.html' -o -name '*.html.gz' -exec rm -f \{\} \;
> Should work OK. I typed tha
From: Clint Adams <[EMAIL PROTECTED]>
> What if one wants to exclude only HTML documentation?
Well, for now
"find /usr/doc -name '*.html' -o -name '*.html.gz' -exec rm -f \{\} \;
Should work OK. I typed that from memory, so make sure it's right before
you run it.
For Deity, I suppose we could
> Those who have no space for documentation on their system should use "rm".
> Our next package system will be able to use a policy file to exclude
> installation from certain directories, like /usr/doc, which will make this
> easier for the user who wants to exclude documentation from a system.
W
On Tue, 24 Jun 1997, Philip Hands wrote:
[snip]
> We could also install all the documentation for everything in Debian on a Web
> server. --- Are we already doing this ? Even if we are, I'm sure it would
> be easier if every package `foo' had one or more associated `foo-doc'
> packages.
We
> On Tue, 24 Jun 1997, Philip Hands wrote:
>
> > I think we should aim to get all documentation into separate packages.
> >
> > Would it not be possible to make the package building tools (deb-make,
> > debstd etc.) assume a simplest case of ``single binary, and single
> > docs package'' rather t
Project policy is that HTML is our main form of documentation presentation.
Thus, packages must contain HTML documents or documents that can be
converted into HTML at run-time. Packages that do not contain such
documents or that offload them into separate packages should have bug
reports filed on t
From: Philip Hands <[EMAIL PROTECTED]>
> I think we should aim to get all documentation into separate packages.
Please don't do this. Deity will have the capability to exclude installation
to certain directories (like /usr/doc) based on a system "policy file".
Packages should always contain the do
On Tue, 24 Jun 1997, Philip Hands wrote:
> I think we should aim to get all documentation into separate packages.
>
> Would it not be possible to make the package building tools (deb-make, debstd
> etc.) assume a simplest case of ``single binary, and single docs package''
> rather than the curr
Christian Schwarz <[EMAIL PROTECTED]> wrote:
>
> If the documentation files in all available formats do not require
> more than 100k of disk space _together_, they may be included in the
> "main" package. Otherwise, the will have to be distributed in
> seperate packages, one fo
> On Mon, 23 Jun 1997, Philippe Troin wrote:
>
> > On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz
> > ([EMAIL PROTECTED]) wrote:
> >
> > > Option 3: We ship .texi files and produce HTML and/or info files on
> > > demand (in the postinst script).
> >
> > I like this idea a lot. I *hate* hav
-BEGIN PGP SIGNED MESSAGE-
On Mon, 23 Jun 1997, Philippe Troin wrote:
> On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz
> ([EMAIL PROTECTED]) wrote:
>
> > Option 3: We ship .texi files and produce HTML and/or info files on
> > demand (in the postinst script).
>
> I like this i
-BEGIN PGP SIGNED MESSAGE-
On Mon, 23 Jun 1997, Christian Schwarz wrote:
> Option 3: We ship .texi files and produce HTML and/or info files on
> demand (in the postinst script).
I think this is not a good idea. Where are these html/info files supposed
to be generated? Will
> "MS" == Martin Schulze <[EMAIL PROTECTED]> writes:
MS: Da Platten immer billiger werden ist Diskspace wirklich kein
MS: Argument mehr, solange es um Daten <100MB geht.
Sorry, I've no money to take the 500 MB disk in my notebook, throw it
away and buy new one for many $s. And I thin
On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz
([EMAIL PROTECTED]) wrote:
> Option 3: We ship .texi files and produce HTML and/or info files on
> demand (in the postinst script).
I like this idea a lot. I *hate* having to fetch the source package
to produce a postscript output...
Ph
Christian Schwarz writes:
> Disadvantages:
> (-) Waste of disk space: everyone has to install both formats.
Da Platten immer billiger werden ist Diskspace wirklich kein Argument
mehr, solange es um Daten <100MB geht.
>Option 1:
>disadvantage of too many packages will disappe
> Option 3: We ship .texi files and produce HTML and/or info files on
> demand (in the postinst script).
>
> Advantages:
> - No work for the maintainers.
> - Great flexibility (the sysadmin could even produce PostScript
> files when needed!).
This is extremel
Hi folks!
To summarize this discussion so far: I think everyone here agrees that we
should provide HTML and INFO.
So we currently have three options, both having their advantages and
disadvantages:
(Arguments with `(-)' will become obsolete when deity is available, see
below.)
Option 1:
I like this proposal too.
Yet another reason, why separate docs could be good:
Sometimes I want only to check documentation, read more about
something (e.g. some toolkit and/or programming language) and I don't
want to install 20 MB package when I need only 1 MB documentation
which I want to read
> /usr/info/emacs-info. I suggest to split this off into a new package
> called "emacs-doc-info". In addition, we should create an "emacs-doc-html"
Interesting. Not really an option, though; as far as emacs is
concerned, that's part of how it documents itself. If you come up
with a way that wor
Am 21.06.97 schrieb schwarz # monet.m.isar.de ...
Moin Christian!
CS> 2. The new "deity" (dselect successor) will simplify the handling of
CS> >1000 packages very much. I had another idea: Perhaps we could deity
CS> adopt to have an overall switch about which documentation the
CS>
Am 21.06.97 schrieb schwarz # monet.m.isar.de ...
Moin Christian!
CS> However, HTML is getting more and more popular these days and I think it
CS> would be very unwise not to choose HTML as "preferred document format".
Right. A lot of companies will use HTML for their programms.
CS> To summariz
To make documentation for packages optional by splitting it into
separate packages would not be a good idea at this point. Please wait
for Deity to implement more fine-grained control over installation, or
let the user manually remove /usr/doc or /usr/info .
Thanks
Bruce
--
Bruce
From: Christian Schwarz <[EMAIL PROTECTED]>
> It's pretty clear to me that we'll have to support "info" in the future,
> since we would have to drop the "GNU" from "Debian GNU/Linux" otherwise.
Actually, I don't think FSF is sticky about this issue. Richard acknowledges
the existence of free brows
[EMAIL PROTECTED] (Martin Schulze) writes:
> I don't like the idea of splitting packages that much. It increses
> the confusion for users. For new users it is incredible difficult
> to install Debian because of >1000 packages.
I think keeping the user from having to deal with this complexity
(
Christian Schwarz <[EMAIL PROTECTED]> proposes:
>
> The documentation will be distributed via several packages:
>
> foo-doc-html for HTML docs
> foo-doc-info for GNU info docs (where available)
> foo-doc-xxx for other formats (only where appropria
On Sat, 21 Jun 1997, Martin Schulze wrote:
[snip]
> I don't like the idea of splitting packages that much. It increses
> the confusion for users. For new users it is incredible difficult
> to install Debian because of >1000 packages.
I can understand your argument very good. However:
1. I d
On Sat, 21 Jun 1997, Scott K. Ellis wrote:
>
>
> -BEGIN PGP DECRYPTED MESSAGE-
> On Sat, 21 Jun 1997, Santiago Vila Doncel wrote:
>
> > On Sat, 21 Jun 1997, Christian Schwarz wrote:
> >
> > > The documentation will be distributed via several packages:
> > >
> > >foo-doc
-BEGIN PGP SIGNED MESSAGE-
On Sat, 21 Jun 1997, Santiago Vila Doncel wrote:
> On Sat, 21 Jun 1997, Christian Schwarz wrote:
>
> > The documentation will be distributed via several packages:
> >
> >foo-doc-html for HTML docs
> >foo-doc-info for GNU i
Christian Schwarz writes:
> Hi folks!
re
> So I suggest the following policy. Note, that this is just a summary, not
> the actual text.
>
>
> The unification of Debian documentation is being carried out via
> HTML. However, we'll still provide GNU info documentation, where
> ava
-BEGIN PGP SIGNED MESSAGE-
On Sat, 21 Jun 1997, Christian Schwarz wrote:
> The documentation will be distributed via several packages:
>
>foo-doc-html for HTML docs
>foo-doc-info for GNU info docs (where available)
>foo-doc-xxx for
That is a very reasonable proposal. I like it!
--
[EMAIL PROTECTED] [EMAIL PROTECTED] http://rosebud.sps.queensu.ca/~edd
PGP key fingerprint = B2 49 75 BF 44 2C B7 AA 50 CB 19 7D 80 F7 CB DC
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Hi folks!
The "html vs. info" discussion reminds me of "vi vs. emacs" discussions
:-)
It's pretty clear to me that we'll have to support "info" in the future,
since we would have to drop the "GNU" from "Debian GNU/Linux" otherwise.
However, HTML is getting more and more popular these days and I
72 matches
Mail list logo
